|
Re: New pi dvap install can't link with radio
Ah, okay. Those "DIRECT" on rpt1 and rpt2 on your 2820 means you using "Local CQ" in your To field. You should be using the Repeater->Use Repeater CQCQCQ on your 2820. And you need to make sure that your From hot-spot setup is using either DUP+ or DUP- with a zero offset, otherwise your 2820 will revert back to DIRECT. I've never used a 2820, so I'm not sure of the specifics for that radio.
On newer Icom radios there is a "Call Sign" menu item in the main menu that will show you UR, R1, R2, and My so you can see what will be in your header packet. qngateway is suppose to automatically fix DIRECT repeater entries in the header packet, but I see there is a bug in it, so it's not working for you. I pushed up a new qndvap version that should fix this, but you should properly configure your 2820 to use your dvap properly. |
|
Re: IcomGateway Quirks
¿ªÔÆÌåÓýThanks, Tom.? I plan to try your
suggestions out in the next few days.? I'll let you know what I
find...
73
Keith/KI5US
On 3/2/22 14:42, Tom Early wrote:
I suspected this might be true, so I read the journalctl man page. You can specify just exactly what you want to watch. Try:
|
|
Re: IcomGateway Quirks
Hi Keith (and Ryan),
If your link fails and the module's auto_link is on (the default value for auto_link is on), it will try to re-establish the link about every 50 seconds. If it fails, it will let you know with the "module is unlinked" prompt. You can send a "?????? U" to unlink and that should stop the relink attempts. How you can help debug your problems: There are three main process in IcomGateway:
When you submit your problem report, please include your qn.cfg file as well as a short description of what you did to generate the problem. Also, I don't want to drive everyone in this groups.io over the edge with a lot of emails with boring logs, so please send your report directly to me at n7tae (at) tearly (dot) net. |
|
IcomGateway Quirks
Tom
Thanks very much for your efforts to provide a viable alternative to G3.? I'm new to managing a D-Star gateway, so I'm bound to ask some dumb questions, but here goes... We've installed your latest gateway software on a Raspberry Pi3 to run our B & C module W1SCC repeaters.? It works - sometimes - and I wanted to provide you with some "operational" feedback. Perhaps we've done something wrong or the Pi3 is underpowered for the task(?)...I plan to substitute the Pi with an Intel-based laptop running Mint 20.3 later this week to check that theory. Quirks we're seeing are: - log shows a reflector link being established but the voice announcement doesn't always occur (maybe 50% of the time). - Radio-initiated commands don't always seem to work.? I find myself having to repeat the commands to finally link or unlink a reflector.? Signal level isn't an issue since I've been doing this very close to the repeaters.? Both B & C modules show the same behavior. - Unlink shows in the log but also (sometimes) fails to announce.? Issuing a new link command (sometimes) causes the unlink voice, followed by linked voice announcement. - linking to reflector XLX658 (our local reflector) doesn't seem to work...it is in the gwys.txt file. - linking to other gateways....am I correct in assuming that I need to add the gateways to the gwys.txt file? - keeps repeating "module is unlinked"...how do I make it stop this behavior (currently, I link it to something). - log shows /usr/local/etc/linked.dat being sent but (sometimes) can't be heard. Suggestions? Thanks & 73! Keith/KI5US Sun City Center, FL |
|
Re: New Icom Repeater Gateway
¿ªÔÆÌåÓýThanks Dan! Not a dumb question at all. The reflector and gateway suffixes are reversed on an Icom repeater depending on whether the stream is going into the repeater or out of the repeater. I "think" this is because Icom considers rpt1 the source of the stream and rpt2 the destination of the stream. This is actually how M17 works. As a programming hacker, I just try things 'till they work! /var/local should be owned by root. qngateway, qnlink and
qnistack all run with root privileges. On 2/24/22 14:51, Dan Ozment wrote:
-- ___________________________ 73 n7tae (at) tearly (dot) net |
|
Re: New Icom Repeater Gateway
I thought I posted a dumb question about the position of the "B" and "G" in Ryan's logs.? If it ever shows up, it wasn't me!? Some dummy wrote it! ? I pulled the latest code and did a successful echo test..
? Tom, probably another dumb question by that same guy, but are permissions right on /var/local?? Is root writing to the folder? dozment@raspberrypi:/var/local$ ls -la
?
? |
|
Re: New Icom Repeater Gateway
Sorry this is taking so long, Ryan. I have pushed up a new version. Some weird things I don't understand. See the comments below:
On 2/22/22 17:06, Ryan Matthew Headley wrote: Feb 22 18:57:59 QNIG qngateway[6055]: Finding Routes for...These b values are the problem. I don't understand why I didn't catch this in Dan W4DTO's debugging session. These voice messages originate from qnlink so the new version of qnlink is 20223. Dan can you test the new version and make sure I didn't break something for you? Feb 22 18:58:03 QNIG qngateway[6055]: id=cec8 ENDI don't understand this failure to open the echotest file. There are very few reasons why a root-process couldn't open file in /var/local. This new version now includes the specific reason why the open() call failed. The new qngateway version is now 20223. Ryan, if this new version is still having problems opening the file, then the new error message may be sufficient for you to figure out how to fix the problem. If not, post your logs and we'll figure it out together. ___________________________ 73 n7tae (at) tearly (dot) net |
|
New Icom Repeater Gateway
Thanks to a couple of hams from 4-land, there is a new IRC gateway especially for Icom repeaters. Ryan W4EAE helped me start the debugging process and Dan W4DTO helped me finish it. Dan provided key tcpdump files that were critical in helping me identify the final few catastrophic bugs in this new project. The original repo at has been archived and is now a public, read-only repo.
The new code is at . This new version is now very close to the QnetGateway code-base and includes the latest features of QnetGateway, like IPv6 routing/linking and sql-based state memory, required by the new dashboard. |
|
Re: gwys.txt
Thanks for letting me know. I should probably remove that option if he's not keeping it up.
Legacy REF reflectors are suppose to be automatically downloaded from the auth.dstargateway.org round-robin server. The last time I checked, this system didn't work very well. Depending on which of the round-robin servers you connected to, you might get 2 reflector definitions or you might get 500. Remember that you have to turn on the legacy authorization (it's off by default). So even if you have it turned on, you may or may not get data for 037 or 046 or anything else, for that matter. However, there is a solution to this problem, but you have to supply the connection info to your favorite reflector and repeaters... As explained in the CONFIG+INSTALL file, you can create your own entries to be added to gwys.txt. In your build directory, create a My_Hosts.txt file containing your favorite connections. There is an example shown in that file explaining how it works. Your definitions will override any previous defines found by other sources, except for one condition: If you configure your system with "DPlus priority" turned on, it will load gwys.txt first and then authorize against auth.dstargateway.org. If DPlus Priority is off, it will load auth.dstargateway.org data first, and then gwys.txt. |
|
gwys.txt
I see the full reflector list is downloaded from va3uv.com. It appears to be several years old and there are new reflectors and some IP addresses have changed. I tried to find a contact email for va3uv without success. Is there a better source for finding a current comprehensive list of reflectors? (REF037 IP is wrong, REF046 is not there).
|
Tom Early
Keith/KI5US
Dan Ozment
Doug