开云体育

My setup: Running ID-51a+2 in terminal mode, RPi 3B, QnetGateway software.
The situation: The HT is connected directly to the Pi via USB. Sometimes when I turn off the HT then turn it back on at a later date (or later in the day for that matter) I have to issue a "systemctl restart" to qnitap, qngateway and qnlink so that the software responds to the HT. The exception was today, where I was able to simply turn on the HT and wait briefly for the software to recognize it was turned back on. There were no indications in daemon.log or syslog of a crash. My only indication of needing to restart was not hearing the talkback from the software, such as "Qnet gateway" and not seeing anything in the logs that usually pop up when I key up.

I have things set up so the USB device is always mapped to the same device name if I happen to disconnect and reconnect the cable. A trick I learned from "Linux in the Hamshack." All I know is that today was the first time I did not have to restart anything or reboot altogether. I will be happy to post logs if I can remember when I last had the problem and what to look for.

This is a more general issue related to 'Terminal / Access Point Mode.'?

My experience is with Icom's software, Pi-Star, and QnetGateway; and the ID-51A+2, the ID-4100, and the IC-9700.

Using any of the three software I mentioned with any of the three radios I mentioned produces the exact same result:? If Terminal mode is up and running and you either power down the radio or switch it out of Terminal Mode, your connection does not re-establish after you power the radio back on or re-enter Terminal mode without either a full restart of the software or a system reboot.

I have been playing with this a little for QnetGateway.? After turning the radio off, the module for which it is set gives warning messages in qnmodem about lost connection.? After a period of time(? need to measure), that module shuts down on its own. (I have QnetGateway running two modules).? If I switch the radio back to Terminal mode before the module has shutdown, it does not work.? If I wait until the module has shutdown, set the radio to Terminal mode, and the start the module with qnadmin, it works--most of the time.

All in all, the software simply cannot tolerate the radio being disconnected for any length of time.? I am not really sure if there is a workaround for this, but I have been examining the code and turning ideas over in my head.? If I come up with something, I will post it.

The real problem is that ICOM has refused to release the details of protocol used for data communication over the digital cable used when the radio is in Terminal or Access Point Mode. Open source programmers are left to their own to figure out how things work. I will NEVER understand why they won't release technical information that will only help them sell more radios.

But at least I have learned a little more and have come up with a work-around, but I'm not sure if it will help you or not. What I have found is that you have to unplug and replug the digital cable to get qnitap to start up properly if you are going to be shutting Terminal or Access Point Mode off and on. Please note that the discussion below is only appropriate with regard to changing the "DV Gateway" menu while qnitap is running.

If you look in the qnitap log, it will tell you when it has properly initialized communication on the digital port with a "ICOM radio is connected" message. If you disconnect the digital cable (and wait 10 seconds for the connection to time out) and then reconnect the digital cable, qnitap will successfully reconnect to the radio most of the time, but not all of the time. I think the reason it doesn't happen all of the time is because the radio may not properly receive the initialization packets, depending on when you happen to plug the cable back in. Remember that as long as the connection is not established, qnitap will quit after 10 seconds of no communication and then systemd will then try to restart it.

I have just pushed up a new version of qnitap, V#2.1.2, that will also send a voice message saying "Radio is connected". This way, you don't have to be watching the log to be able to know if the communications was properly initialized. So...

Ten seconds after you switch back to normal mode from either Terminal or Access Point Mode, qnitap will quit, and then the system will continuously try to restart qnitap approximately every 10 seconds. Unplug the digital cable while you are in normal mode. Then, when you are ready to go back to Terminal or Access Point Mode, just plug in the digital cable after you have entered the T/AP Mode. You should fairly quickly hear the "Radio is connected" message. If not unplug the digital cable, wait at least 10 seconds and then plug it back in.

Just one more thing. You may not hear the "Radio is connected" message on a cold boot. There is a lot going on with qngateway, qnlink and qnitap when starting cold. But, as long as qngateway and qnlink are both already running, you should hear the message when the communication is properly initialized.

Finally finally, I still think the safest way to handle this is to shut down RPi if you aren't using T/AP, then restart when you are ready to resume T/AP.

Are there any specific logs I can watch with a "tail -f"? I typically connect via Putty, although I do occasionally go the direct route and switch my monitor over to the Pi. I love troubleshooting, but I can't code to save my life.

There are a couple of options:

1. You can use the log sub-menu within ./qnadmin.
2. "sudo journalctl -u qnitap -f" (or qnlink or qngateway).
3. Install some helpers. From the build directory, do "cp bash_aliases ~/.bash_alises. From then on, anytime you start a new shell, type "watch itap" (or link or gateway).

Checkout the Debugging sub-menu in ./qnconfig for ways to control what's logged. Remember to restart your system if you change anything in the configuration. QSO logging will show the header fields of every voice stream that comes across you system. IRC logging will show the updates coming from QuadNet (every time someone on the network keys up). DTMF logging is useful if you are trying to add a new command to DTMF. Debugging logging will show interesting things about every voice frame. Turn all these on and you won't be able to keep up with the output. Turn off all these things and only see messages of particular importance.

Thanks. I'll try that.