Re: Icom Terminal and Access Point Mode support
Once any of the processes (qngateway, qnlink and qnitap) dies, systemd will attempt to restart them, but this won't go on forever. It will eventually give up and you'll see messages about this in the different logs. At that point, you can stop/start or reboot. If you've installed the bash_alises script, you can do a "stop itap" followed by a "start itap", otherwise, use qnadmin.
I don't recommend that you turn off your radio and let the processes run. Either stop QnetGateway, shut down the sbc or turn down the radio volume and let it run. If you just power cycle your radio, qnitap might be able to restart successfully. You'll have to watch the log to see if it worked.
When qnitap starts (or is trying to reconnect), it sends a series of 0xff bytes to reset the radio, then it sends a ping every second and expects a pong in return. If nothing is received from the radio for 10 seconds, qnitap will give up and quit. Then systemd takes over.
Systemd will also restart qngateway if it stops. Likewise, it will not do this forever. The qngateway log will let you know what's happening.
Legacy DPlus(REF) reflectors are updated by the Legacy authorization when qnlink boots up, if you've turned it on. The data returned is controlled by your dplus configuration and it contains whatever the authorization server choose to send. It is possible that the returned data may not contain your favorite reflector or repeater if that system is having some even short lived problems. If you get a "gateway not found", you can try to authorize again (see below). Interestingly and also unfortunately, data returned by authorization "hand-shaking" is also returned for any callsign, even one that's not properly registered in the legacy system. So, qnlink can't tell you if you will be able to successfully link to a legacy REF reflector or legacy repeater. The only way the authorization routine will fail is if qnlink can't connect to any of the authorization servers (there are usually three running and the last time I looked at these carefully they can return different lists).
Non-legacy reflectors and repeaters are strictly sourced from gwys.txt. There is no auto update function within my software. A cron script would be required, or you can used qnadmin. Be sure to place the new gwys.txt file in /usr/local/etc. A URCALL = " _ _ _ _ _ _ _ F" will reload all values from gways.txt. This radio command will also reauthorize you callsign to the legacy DPLUS system.
I only support the out of production V1 DVRPTR. MMDVM-compatible modems can be directly supported via qnmodem or qnrelay+MMDVMHost. The latter would be they only way to use QnetGateway in a multimode hotspot.
|
Re: Icom Terminal and Access Point Mode support
Hi Tom,
Thank you very much for your feedback. The day after I send my post,
I upgraded the firmware of my ID-4100 to the one which was also
mentioned in your reply. And you are right, now it works without any
glitches or EOT errors.
Usually, I run the QnetGateway 24/7 and only switch of my radio. It
still happens, that my radio doesn't get a reply from the gateway,
even if I wait for 5 minutes or even longer. In this cases, I need
to restart the gateway.
- Is your software polling the configured radio frequently and
will reconnect it automatically after I power it on?
- And is there any kind of watchdog which can restart the
gateway in case of malfunction?
My target here is to run the OrangePi Zero headless without
touching it any more. Next time I see this behaviour I will also
check the status of the gateway and all dependent processes and
try to provide more information.
I also want to know, if there is an auto update of the configured
gatewaylist? Or do I have to configure a cron-job by myself?
Finally but also off-topic is about the DVRPTR v1 support: This
does not include the additional AMBE-board, right (same as G4KLX
DStarRepeater)?
vy 73 from Singapore de Stephan 9V1LH/DG1BGS
Am 09/02/2020 um 22:37 schrieb Tom
Early:
toggle quoted message
Show quoted text
I don't know anything about using a MAX232 in place of the Icom
USB to serial converter cable. I'm afraid you are on your own with
that. All I can tell you is the Icom cable requires a baud rate of
38400.
Make sure your radios have the most up to date firmware (currently
2020/01/31).
The qnitap log would be useful (turn on qso logging).
|
Re: Icom Terminal and Access Point Mode support
I don't know anything about using a MAX232 in place of the Icom USB to serial converter cable. I'm afraid you are on your own with that. All I can tell you is the Icom cable requires a baud rate of 38400.
Make sure your radios have the most up to date firmware (currently 2020/01/31).
The qnitap log would be useful (turn on qso logging).
|
Re: Icom Terminal and Access Point Mode support
Hi Tom,
I still have performance issues, no matter what I tried. I use the Terminal mode and tried it with the ID-4100 and ID-31Plus. As an SBC I use the OrangePi Zero but have also tried it with a Raspberry Pi 3B+.
What I found out so far is, that a MAX232 wired directly to the UART works much better compared to a USB-to-RS232 converter. But I still get dropouts. I also found, that sometimes when stations key to fast, I can't hear them at all. Sometimes the datastream just cuts out and I have to reboot my system.
I wonder what data rate is being used for the communication between the SBC and the radio. My TTL-to-RS232 can maximum do 120 kbps.
Any ideas of what else I could try? Or are there any other users here that run a similar configuration successfully.
vy 73 de Stephan 9V1LH/DG1BGS
|
|
|
Fantastic news, Tom!? Thanks.? Is that change in the QNetIcomGateway build?
|
I finally got around to adding automatic re-linking to qnlink and pushed up to the master branch. Please see the explanation on how it works in the linking section of the OPERATING file.
|
An Open Letter to Hams using Icom TAP modes
I'm confident I have TAP modes working as good as is possible given the lack of documentation from Icom. It is very reliable now and I believe it works better than the current release of DStarRepeater, which can be used by PiStar, but only if you turn off MMDVMHost. Icom developed the serial port communications that enabled TAP modes on several of their DStar radios. This is a significant feature that is not available from Kenwood. They also have their free RM-MS3 Windows and Android software that limits the benefit of the serial capability by working only with the legacy DStar system. I have to admit that the Android device would be good, but only if that eliminates the need to tether the device to a smart phone or a wifi connection for internet access, but I'm not sure if that's the case. In any event, I would argue that setting up TAP modes with the RM-MS3 software is much more complicated than using any open-source solution and is especially true if you are already using an open-source solution.
Terminal mode is an ideal choice for a mobile installation for those times when the user is traveling beyond the reach of land-based repeaters, but only if the gateway part of the setup is realized in a small form computer, like a Raspberry Pi. QnetGateway is especially well suited to this application because of its voice prompts, especially when routing, allowing the ham to keep his eye on the road instead of the radio. Access Point mode is fantastic for being able to quickly install a simplex, high powered hot-spot. But why shank this capability by requiring a Windows computer or Android device and only giving you access to part of the digital voice universe?
Since it's common that both TAP modes (especially Terminal mode) would be used in situations where internet access would be provided by a smart phone, Routing to a Smart Group is the way to go, because of the Smart Group Server's ability to work through fire-walled internet access.
I have been carrying on an email conversation about TAP documentation with an Icom rep for well over a year now, and I don't think they get it yet: Supporting open source programmers like me (and those other guys) will only produce more sales for them. We're not asking for a lot. Just a little bit of documentation that probably already exists.
At every Hamfest, every Ham interested in digital voice should go to the Icom booth and ask, "How come Icom doesn't better support the open-source Ham radio community?" A "white paper" on serial port communications would be good start!
|
Re: Terminal and Access Point Mode update
Thanks Tom! I will fire this up when I get home tonight. Excellent work. :)
|
Re: Terminal and Access Point Mode update
I will try the new code this evenibg?
Cheers
Carty
On Wed, Jan 8, 2020, 12:17 PM Tom Early < n7tae@...> wrote: I think I finally got to the bottom of the problem with TAP modes. I'm suppose to wait until I get an "all clear, ready for the next packet" message before I send the next packet. From what I can tell, there is a limited buffer in the Icom radios that will hold a few (maybe a dozen?) packets. Of course packets in its queue will be emptied at the rate of one every 20 milliseconds, but I won't get the all clear message until the radio has space available for another packet. Of course UDP D-Star packets are send individually and may not arrive in perfect timing (or even the correct order)*.? The problem is, there is a bug in the radio firmware where I never receive the all clear message. Sometimes this happens right away, sometimes it can take hours to happen.
New code in the master branch will now detect this condition and reset the serial port in order to clear the firmware lockup in the radio. It only takes about 60 milliseconds to detect the problem and about 2 seconds to reset the serial port. During this time any incoming packets from the gateway are queued and will be played once the serial port is reopened. In the qnitap log, you'll set a message that the radio is connected when it resets the serial port. Keep in mind that immediately after the reset, you will be hearing audio that actually was received about two seconds earlier, at least until there is a two second gap in activity where the qnitap queue can clear itself by playing out the queued packets.
As I indicated in an earlier message, I expect Icom to release new firmware soon that will hopefully fix the problem.
*That is one reason why digital communications is always delayed and is the main reason you should always wait a few seconds after someone keys off before keying up your radio. (Don't tailgate!)
|
Terminal and Access Point Mode update
I think I finally got to the bottom of the problem with TAP modes. I'm suppose to wait until I get an "all clear, ready for the next packet" message before I send the next packet. From what I can tell, there is a limited buffer in the Icom radios that will hold a few (maybe a dozen?) packets. Of course packets in its queue will be emptied at the rate of one every 20 milliseconds, but I won't get the all clear message until the radio has space available for another packet. Of course UDP D-Star packets are send individually and may not arrive in perfect timing (or even the correct order)*.? The problem is, there is a bug in the radio firmware where I never receive the all clear message. Sometimes this happens right away, sometimes it can take hours to happen.
New code in the master branch will now detect this condition and reset the serial port in order to clear the firmware lockup in the radio. It only takes about 60 milliseconds to detect the problem and about 2 seconds to reset the serial port. During this time any incoming packets from the gateway are queued and will be played once the serial port is reopened. In the qnitap log, you'll set a message that the radio is connected when it resets the serial port. Keep in mind that immediately after the reset, you will be hearing audio that actually was received about two seconds earlier, at least until there is a two second gap in activity where the qnitap queue can clear itself by playing out the queued packets.
As I indicated in an earlier message, I expect Icom to release new firmware soon that will hopefully fix the problem.
*That is one reason why digital communications is always delayed and is the main reason you should always wait a few seconds after someone keys off before keying up your radio. (Don't tailgate!)
|
Re: QnetGateway with DV gateway access point mode
The solution is to place the .dat file in the 4100 folder on the microSD card. ? Carty ? Sent from for Windows 10 ?
toggle quoted message
Show quoted text
From: Carty Ellis via Groups.IoSent: Monday, January 6, 2020 4:39 PM To: [email protected]Subject: Re: [QnetGateway] QnetGateway with DV gateway access point mode ? Still nothing.? 4100 says “ –no file –”? Windows sees the file. ? This what I tried first.? The zipped file gave same result. ? I give. ? Carty ? Sent from for Windows 10 ? ? Carty ? Unzip the file first, and put the file that is the result of the unzip process on the SD card. ? Colby ? ? ? Thanks for the tip on the possible update. ?I still have not been able to get the radio see the update file. ?I can see it - format SD card in radio, put .zip file on card and when I go to the radio and do firmware update it says no data found. ???? ?There is other stuff on the card but I would think the format would clear it. Carty ? On Jan 6, 2020, at 12:02 PM, Tom Early <n7tae@...> wrote: ? Well, about an hour after posting the previous message, I suffered the dreaded "mute bug" where things look just fine in the log, but no audio is heard. This bug usually takes a long time to show itself, so I have some work ahead of me. I'm pretty sure it has to do with the hand-shaking (each packet must be acknowledged) on the serial port, but I haven't yet got to the kernel of the problem and therefore don't have a solution, yet. This is hard work without a serial communication design spec from Icom.
I have been talking with them and I have it on good authority that there are still some bugs in the Icom radio firmware and new firmware version is expected in the near future.
?
|
Re: QnetGateway with DV gateway access point mode
Still nothing.? 4100 says “ –no file –”? Windows sees the file. ? This what I tried first.? The zipped file gave same result. ? I give. ? Carty ? Sent from for Windows 10 ?
toggle quoted message
Show quoted text
From: Colby Ross W1BSBSent: Monday, January 6, 2020 3:50 PM To: [email protected]Subject: Re: [QnetGateway] QnetGateway with DV gateway access point mode ? Carty ? Unzip the file first, and put the file that is the result of the unzip process on the SD card. ? Colby ? ? ? Thanks for the tip on the possible update. ?I still have not been able to get the radio see the update file. ?I can see it - format SD card in radio, put .zip file on card and when I go to the radio and do firmware update it says no data found. ???? ?There is other stuff on the card but I would think the format would clear it. Carty ? On Jan 6, 2020, at 12:02 PM, Tom Early <n7tae@...> wrote: ? Well, about an hour after posting the previous message, I suffered the dreaded "mute bug" where things look just fine in the log, but no audio is heard. This bug usually takes a long time to show itself, so I have some work ahead of me. I'm pretty sure it has to do with the hand-shaking (each packet must be acknowledged) on the serial port, but I haven't yet got to the kernel of the problem and therefore don't have a solution, yet. This is hard work without a serial communication design spec from Icom.
I have been talking with them and I have it on good authority that there are still some bugs in the Icom radio firmware and new firmware version is expected in the near future.
?
|
Re: QnetGateway with DV gateway access point mode
Carty ? Unzip the file first, and put the file that is the result of the unzip process on the SD card. ? Colby ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Carty Ellis Sent: Monday, January 6, 2020 15:41 To: [email protected]Subject: Re: [QnetGateway] QnetGateway with DV gateway access point mode ? Thanks for the tip on the possible update. ?I still have not been able to get the radio see the update file. ?I can see it - format SD card in radio, put .zip file on card and when I go to the radio and do firmware update it says no data found. ???? ?There is other stuff on the card but I would think the format would clear it. Carty
On Jan 6, 2020, at 12:02 PM, Tom Early <n7tae@...> wrote: ? Well, about an hour after posting the previous message, I suffered the dreaded "mute bug" where things look just fine in the log, but no audio is heard. This bug usually takes a long time to show itself, so I have some work ahead of me. I'm pretty sure it has to do with the hand-shaking (each packet must be acknowledged) on the serial port, but I haven't yet got to the kernel of the problem and therefore don't have a solution, yet. This is hard work without a serial communication design spec from Icom.
I have been talking with them and I have it on good authority that there are still some bugs in the Icom radio firmware and new firmware version is expected in the near future.
?
|
Re: QnetGateway with DV gateway access point mode
Carty, have you tried clearing the card using diskpart in
windows? After step 6 put the sd card back in the radio and let
the radio format the card.
Step 1:?Type?cmd?in the search box in Windows
10 and then you'll get the best match?Command Prompt. Right-click on it
and choose "Run as administrator".
Step 2:?In the command prompt, type?diskpart?and press
"Enter".
Step 3:?Type?list disk?to list
all the available drives and press "Enter".
Step 4:?Type?select disk + disk number?(
for example, select disk 0) to select the SD card you want to
format and press Enter.
Step 5:?Type?clean?to clean the
SD card you have selected and press "Enter".
Step 6:?Type?create partition primary?to
create a partition on the cleaned SD card and press "Enter":
On 2020-01-06 1:41 p.m., Carty Ellis
wrote:
toggle quoted message
Show quoted text
Thanks for the tip on the possible update. ?I still have not been
able to get the radio see the update file. ?I can see it - format
SD card in radio, put .zip file on card and when I go to the radio
and do firmware update it says no data found. ???? ?There is other
stuff on the card but I would think the format would clear it.
Carty
On Jan 6, 2020, at 12:02 PM, Tom Early < n7tae@...> wrote:
Well, about an hour after posting the previous
message, I suffered the dreaded "mute bug" where things
look just fine in the log, but no audio is heard. This bug
usually takes a long time to show itself, so I have some
work ahead of me. I'm pretty sure it has to do with the
hand-shaking (each packet must be acknowledged) on the
serial port, but I haven't yet got to the kernel of the
problem and therefore don't have a solution, yet. This is
hard work without a serial communication design spec from
Icom.
I have been talking with them and I have it on good
authority that there are still some bugs in the Icom radio
firmware and new firmware version is expected in the near
future.
|
Re: QnetGateway with DV gateway access point mode
Thanks for the tip on the possible update. ?I still have not been able to get the radio see the update file. ?I can see it - format SD card in radio, put .zip file on card and when I go to the radio and do firmware update it says no data found. ???? ?There is other stuff on the card but I would think the format would clear it.
toggle quoted message
Show quoted text
On Jan 6, 2020, at 12:02 PM, Tom Early < n7tae@...> wrote:
Well, about an hour after posting the previous message, I suffered the dreaded "mute bug" where things look just fine in the log, but no audio is heard. This bug usually takes a long time to show itself, so I have some work ahead of me. I'm pretty sure it has to do with the hand-shaking (each packet must be acknowledged) on the serial port, but I haven't yet got to the kernel of the problem and therefore don't have a solution, yet. This is hard work without a serial communication design spec from Icom.
I have been talking with them and I have it on good authority that there are still some bugs in the Icom radio firmware and new firmware version is expected in the near future.
|
Re: QnetGateway with DV gateway access point mode
Well, about an hour after posting the previous message, I suffered the dreaded "mute bug" where things look just fine in the log, but no audio is heard. This bug usually takes a long time to show itself, so I have some work ahead of me. I'm pretty sure it has to do with the hand-shaking (each packet must be acknowledged) on the serial port, but I haven't yet got to the kernel of the problem and therefore don't have a solution, yet. This is hard work without a serial communication design spec from Icom.
I have been talking with them and I have it on good authority that there are still some bugs in the Icom radio firmware and new firmware version is expected in the near future.
|
Re: QnetGateway with DV gateway access point mode
What about putting a thermal switch in series with the fan? As
the temperature rises to a specified level the fan would turn on.
Otherwise it would remain off and silent.
On 2020-01-04 9:46 p.m., Tom Early
wrote:
toggle quoted message
Show quoted text
I decided on the lowest current that could drive the 4100 to
full output, in case I want to to AP Mode. An MJF-4115 was $79.
It's pretty small, but the fan noise is a bit more than I would
like. The fan is always on, even when I am in Terminal Mode.
On 1/4/20 9:27 AM, Will wrote:
Good job Tom,
What power supply did you pick to use for the 4100 and do you
think you would set it up to run the it in access mode?
Will
On 1/4/2020 10:07 AM, Tom Early
wrote:
I finally got my 4100 installed in my radio room. I updated
the 4100 firmware to the 12/13/2019 version. I'm running on a
raspberry pi 3 using fully upgraded buster (10.2) and it seems
very solid in Terminal Mode. Had it linked to XRF735A last
night for the entire Trains Net, including the pre-check-in.
This morning, I've been connected to REF030C for three hours
now with no problems.
--
___________________________
73
n7tae (at) tearly (dot) net
|
Re: QnetGateway with DV gateway access point mode
I decided on the lowest current that could drive the 4100 to full
output, in case I want to to AP Mode. An MJF-4115 was $79. It's
pretty small, but the fan noise is a bit more than I would like.
The fan is always on, even when I am in Terminal Mode.
On 1/4/20 9:27 AM, Will wrote:
Good job Tom,
What power supply did you pick to use for the 4100 and do you
think you would set it up to run the it in access mode?
Will
On 1/4/2020 10:07 AM, Tom Early
wrote:
I finally got my 4100 installed in my radio room. I updated the
4100 firmware to the 12/13/2019 version. I'm running on a
raspberry pi 3 using fully upgraded buster (10.2) and it seems
very solid in Terminal Mode. Had it linked to XRF735A last night
for the entire Trains Net, including the pre-check-in. This
morning, I've been connected to REF030C for three hours now with
no problems.
--
___________________________
73
n7tae (at) tearly (dot) net
|
Re: QnetGateway with DV gateway access point mode
Good job Tom,
What power supply did you pick to use for the 4100 and do you
think you would set it up to run the it in access mode?
Will
On 1/4/2020 10:07 AM, Tom Early wrote:
toggle quoted message
Show quoted text
I finally got my 4100 installed in my radio room. I updated the
4100 firmware to the 12/13/2019 version. I'm running on a
raspberry pi 3 using fully upgraded buster (10.2) and it seems
very solid in Terminal Mode. Had it linked to XRF735A last night
for the entire Trains Net, including the pre-check-in. This
morning, I've been connected to REF030C for three hours now with
no problems.
|
Tom Early
Dan Ozment
Elden AI7HL
Carty Ellis KA2Y
