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

I have been encountering the exact same behavior, but not all the time.

My experience has also been that actual voice traffic over the repeater or to and from a connected reflector appears to work flawlessly.

One additional issue not enumerated above is that my hotspots are no longer able to link to the gateway with IcomGateway.? This worked flawlessly with QnetICOMGateway.? This is useful so that I can monitor the repeater at work or while traveling.

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:

1. qngateway is the ircDDB gateway. This has to run even if you don't want to support D-Star routing. If you don't want to route, I believe you can clear both hostnames in the IRC submenu of ./config. qngateway is connected to both the Icom repeater and qnlink. Nearly all voice streams coming from the repeater are sent to qnlink. The exception are voice streams that are callsign, zone, or group routes, or specific functions like echo and voicemail.
2. qnlink handle linking to XRF, DCS, or REF reflectors. qnlink passes reflector traffic to qngateway. qnlink also generates most of the audio prompts
3. qnistack is a relay program positioned between qngateway and the Icom reapeater. It handles repeater initialization, packet acknowledgement (the Icom repeater requires that most every packet be acknowledged). Most importantly, qnistack reformats voice stream packets between the "DSTR" format that Icom uses and the "DSVT" format used by repeaters, reflectors and routing clients. Packets going between qngateway and qnlink use the "DSVT" format.

If you are having problems with an IcomGateway function, I need to see the logs from all three programs during the execution of the function. Please enable Call (QSO) logging before you do this test. You can find this in the debugging sub-menu of ./config. You can view each log with "sudo journalctl -u <program_name> -f" where <program_name> is qngateway, qnlink or qnistack. You can also view the entire system log with "sudo journalctl -f". This will contain the logs from the three programs as well as a lot of other stuff that usually isn't germane to the problem.

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.

I suspected this might be true, so I read the journalctl man page. You can specify just exactly what you want to watch. Try:

sudo journalctl -u qngateway -u qnlink -u qnistack -f

开云体育