Re: IC-9700, Terminal Mode, QnetGateway
Wow, that's one expensive Terminal Mode device!
First of all, both Jonathan and I support Terminal and Access Point mode via the OPC-2350LU serial-to-USB cable. Of course, I think QnetGateway is a more reliable TAP client.
Reading the 9700 manual, it looks like it supports the data port for TAP modes. If you insist on using the LAN port on the 9700, I would have the same question Jonathan has when you asked him for the same development: Where's the ICOM documentation? The probable answer, ICOM doesn't have it and won't make it available anytime soon, so some reverse engineering is needed.
What now seems like a long time ago, QnetGateway gave up the ability to run different pieces of the package on different computers. All communications between the various modems, the gateway and the link program occur over Unix datagram sockets, not UDP sockets. Unix datagram sockets are file based and so the server and client have to be on the same machine. The one exception is that you should be able to run MMDVMHost on a different machine as QnetGateway, as that communication still via UDP.
Reintroducing IP communication between the gateway and modems is possible. It could be software configurable, but the administration of that begins to look too complicated for both me and QnetGateway users, and it adds code to almost every program in the QnetGateway package that most configurations won't every use. A simpler approach would be to leave QnetGateway alone and develop a simple translator application. This new application would be very much like the CQnetRelay class that would connect to Unix datagram ports at one end and to a UDP (or even better, a TCP) LAN or WAN port at the other end.
|
IC-9700, Terminal Mode, QnetGateway
I just added an IC-9700 to the shack and am getting familiar with it.? I currently have ircddbgateway running on a Raspberry Pi which services both a DVAP (running on the same host) as well as an MMDVM/Pi-Star on a different host.? So there is an A module and a B module.
Adding the IC-9700 Terminal Mode to my network breaks things things becuase both the IC-9700 and ircddbgateway want port 40000 forwarded to themselves.? Bad news.? But what if I could have the IC-9700 also be a client of the single ircddbgateway?? Not today, anyway, because ircddbgateway doesn't talk Icom Terminal Mode.
So enter QnetGateway.? Can the IC-9700 be a client of QnetGateway over the ethernet connection?? If that works, then can QnetGateway also support other DVAP/MMDVM clients via IP at the same time?? The ultimate goal for me would be a gateway that can handle my DVAP, an MMDVM client, and a Terminal Mode Client over ethernet, all at the same time.
So, what capabilities exist today and can you forsee that QnetGateway might eventually get me where I want to go?
Thanks and 73,
Dan Srebnick
K2IE
|
Re: Zumspot with OLED running MMDVM
Thinking you are right because I cant get it work at all, Anyway I did match the MMDVM setting and still no go. Well I gave it the old school try, Maybe you guys can work on it in future releases cause I know that there are a lot of hotspots
that have the 3 or 6 inch OLEDs and as well as nextion displays so will wait for you guys to fix. Not a deal breaker for me since I use the dashboard
?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]>
On Behalf Of Colby Ross W1BSB
Sent: Monday, April 6, 2020 2:28 PM
To: [email protected]
Subject: Re: [QnetGateway] Zumspot with OLED running MMDVM
?
And if I’m not mistaken, I believe there are certain files included that are required to make it work, such as overlay files. Sorry I can’t be much more help, but I don’t use an OLED, nor do I have access to one. It would probably help
to compare the output of MMDVMHost’s log on pistar to your own and see if its loading files you aren’t, and if it is, to copy those files to your QnetGateway system.
?
?
Colby
?
?
?
You are using Qnetgateway w/ MMDVMHost (not the MMDVM Modem built in driver) correct?
?
If so, I suggest copying the working OLED mmdvmhost configuration from pi-star (/etc/mmdvmhost I believe) and comparing it to the one you’re using with Qnetgateway.
?
Colby
?
?
From: [email protected] <[email protected]>
On Behalf Of Elmer Delgado
Sent: Monday, April 6, 2020 15:24
To: [email protected]
Subject: [QnetGateway] Zumspot with OLED running MMDVM
?
OK havent been able to get the OLE working on the zumspot, Running buster with MMDVM and QnetGateway. Works fine but cant seem to get the OLE to work. Has anyone in the group know if there something else I have to turn on the raspberry
Pi-zero? Worked fine under Pi-star any help would be appreciated?
|
Re: Brought back QnetGateway after a long project
Thank you for the information.
On 4/6/2020 11:31 AM, Tom Early wrote:
toggle quoted message
Show quoted text
You can update your gwys.txt file with the 'gw' command in the
main menu. Once in the gateway menu, most will want the 'ip'
version of the gateways.
|
Re: Zumspot with OLED running MMDVM
And if I’m not mistaken, I believe there are certain files included that are required to make it work, such as overlay files. Sorry I can’t be much more help, but I don’t use an OLED, nor do I have access to one. It would probably help to compare the output of MMDVMHost’s log on pistar to your own and see if its loading files you aren’t, and if it is, to copy those files to your QnetGateway system. ? ? Colby ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Colby Ross W1BSB via groups.io Sent: Monday, April 6, 2020 15:25 To: [email protected]Subject: Re: [QnetGateway] Zumspot with OLED running MMDVM ? You are using Qnetgateway w/ MMDVMHost (not the MMDVM Modem built in driver) correct? ? If so, I suggest copying the working OLED mmdvmhost configuration from pi-star (/etc/mmdvmhost I believe) and comparing it to the one you’re using with Qnetgateway. ? Colby ? ? From: [email protected] <[email protected]> On Behalf Of Elmer Delgado
Sent: Monday, April 6, 2020 15:24
To: [email protected]
Subject: [QnetGateway] Zumspot with OLED running MMDVM ? OK havent been able to get the OLE working on the zumspot, Running buster with MMDVM and QnetGateway. Works fine but cant seem to get the OLE to work. Has anyone in the group know if there something else I have to turn on the raspberry Pi-zero? Worked fine under Pi-star any help would be appreciated?
|
Re: Zumspot with OLED running MMDVM
You are using Qnetgateway w/ MMDVMHost (not the MMDVM Modem built in driver) correct? ? If so, I suggest copying the working OLED mmdvmhost configuration from pi-star (/etc/mmdvmhost I believe) and comparing it to the one you’re using with Qnetgateway. ? Colby ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Elmer Delgado
Sent: Monday, April 6, 2020 15:24
To: [email protected]
Subject: [QnetGateway] Zumspot with OLED running MMDVM ? OK havent been able to get the OLE working on the zumspot, Running buster with MMDVM and QnetGateway. Works fine but cant seem to get the OLE to work. Has anyone in the group know if there something else I have to turn on the raspberry Pi-zero? Worked fine under Pi-star any help would be appreciated?
|
Zumspot with OLED running MMDVM
OK havent been able to get the OLE working on the zumspot, Running buster with MMDVM and QnetGateway. Works fine but cant seem to get the OLE to work. Has anyone in the group know if there something else I have to turn on the raspberry Pi-zero? Worked fine under Pi-star any help would be appreciated?
|
Re: new web-based dashboard for QnetGateway
Dan,
I have a uploaded a repo branch for QnetIcomGateway (for ICOM D-Star repeaters only) called "mega" that contains the dashboard along with a lot of other changes. It has all the fixes and enhancements that QnetGateway has except for IPV6 support. Someone needs to try this branch and let me know how it works. A great deal of code has changed, so I will be surprised if there are not at least a few initial problems.
You'll need the Sqlite3 development package: "sudo apt install libsqlite3-dev" for the dashboard support.
To switch to this branch: "git pull", "make clean", "git checkout mega" and then "make". (Don't forget the -j<N> option to make when <N> is the number of hardware threads.) Then uninstall and reinstall "sudo make uninstall" and "sudo make install".
To switch back to master : "make clean", "git checkout master" and "make". Then you can uninstall and reinstall.
By default, the QnetIcomGateway dashboard only enables the module and last heard sections. If you want the dashboard visible to the world, you shouldn't use the php mini server.
Tom N7TAE
|
Re: Brought back QnetGateway after a long project
You can update your gwys.txt file with the 'gw' command in the main menu. Once in the gateway menu, most will want the 'ip' version of the gateways.
|
Brought back QnetGateway after a long project
Hi Colby,
I brought back my Icom repeater using QnetGateway after a long project I completed. I tried to link to our reflector XLXnnn, using XRF or DCS and it would not work. I think I need to update my hostfiles to add XLX. It this corret? Thank you.
N0MIS, 73's
|
Sounds like some great work!? I'm looking forward to getting our non-ICOM DSTAR repeater on the air, and looking forward to the update QnetIcomGateway update with all of these great new things! Thanks for continuing to mature the gateway!
|
On Thu, Apr 2, 2020 at 07:27 AM, Tom Early wrote:
Yes, unfortunately, that will happen occasionally. The "VIA SMARTGP" message that I mentioned earlier is in the "slow data" portion of the voice packets and therefore more vulnerable to noise anytime the packets are transmitted by RF (either wifi or DStar). Both the header packet and the actual AMBE voice data is "protected" by forward error correction (FEC) and so is somewhat immune to noise, but not the slow data. If the "VIA" message arrives damaged, qngateway falls back to what it knows for sure. In this case, your seeing the URCall the Smart group is using, which is a to your hot-spot.
The problem is further complicated by the fact that Jonathan G4KLX got lazy in the way he sends out the "VIA" message and I haven't fixed this yet. As mentioned earlier this "VIA" message is prepended to any voice stream distributed by the routing group. In fact, the packets of the "VIA" message are constructed and sent immediately, without the usual 20-millisecond delay that a normal voice stream would have. (Each DStar voice packet contains 20 milliseconds of audio.) Because each UDP voice packet is independent from all the other voice packets in a voice stream and the magical way the internet works, the 21 voice packets that make up the "VIA" message can take a different route on the internet highway from the smart group server to your hot-spot and so a voice stream can arrive out of order, especially if some of the voice packets leave the Smart Group Server at nearly the same time. If the packets of the "VIA" message arrive out of order, the message will be damaged.
I will fix this eventually and am considering a couple of options. Of course, all the things I can come up with are quite a bit of work, so this will take some time.
My goodness. I just read through your response a little more slowly. That is such a very cool explanation. You clearly have an incredibly good handle on this whole thing. Some people might view what you're doing as a lot of work. Which of course it is. But it sounds like you also really like doing it. Fun work is the best kind.
|
On Thu, Apr 2, 2020 at 07:27 AM, Tom Early wrote:
I will fix this eventually and am considering a couple of options. Of course, all the things I can come up with are quite a bit of work, so this will take some time.
No worries. It's a very minor thing. And I understand you need to weigh the need/benefit against the effort. BTW... in that little text field that broadcasts with my callsign... I put my first name along with "-- QnetGateway". Spreading the word about a great program. Thanks!
|
Yes, unfortunately, that will happen occasionally. The "VIA SMARTGP" message that I mentioned earlier is in the "slow data" portion of the voice packets and therefore more vulnerable to noise anytime the packets are transmitted by RF (either wifi or DStar). Both the header packet and the actual AMBE voice data is "protected" by forward error correction (FEC) and so is somewhat immune to noise, but not the slow data. If the "VIA" message arrives damaged, qngateway falls back to what it knows for sure. In this case, your seeing the URCall the Smart group is using, which is a to your hot-spot.
The problem is further complicated by the fact that Jonathan G4KLX got lazy in the way he sends out the "VIA" message and I haven't fixed this yet. As mentioned earlier this "VIA" message is prepended to any voice stream distributed by the routing group. In fact, the packets of the "VIA" message are constructed and sent immediately, without the usual 20-millisecond delay that a normal voice stream would have. (Each DStar voice packet contains 20 milliseconds of audio.) Because each UDP voice packet is independent from all the other voice packets in a voice stream and the magical way the internet works, the 21 voice packets that make up the "VIA" message can take a different route on the internet highway from the smart group server to your hot-spot and so a voice stream can arrive out of order, especially if some of the voice packets leave the Smart Group Server at nearly the same time. If the packets of the "VIA" message arrive out of order, the message will be damaged.
I will fix this eventually and am considering a couple of options. Of course, all the things I can come up with are quite a bit of work, so this will take some time.
|
Hey Tom... thanks for all the hard work on this. I am really enjoying having the dashboard. I did notice a little inconsistency with the "Via" field. Not sure if it's anything that you have control over. But sometimes the smart group does not show... but rather my module name. (see the attachment) 
|
NICE!!!!!!! (what more can I say)
"Nothing adds excitement like something that is none of your business" Note I am not a doctor, I don't even play one on television John F Davis
On Tuesday, March 31, 2020, 12:10:37 PM EDT, Tom Early <n7tae@...> wrote:
Thanks Al. I just love questions about Routing!
So the old column that showed "Linking" or "Routing" now shows either the Smart Group of the voice stream it's coming from, or the reflector module it's coming from, if you are linked.
_._,_._,_
|
Hi Tom,
Thank you. Can you direct me where to go for? information in
regards to conections from Two GM300 conversion with MMDVMHost
-Pi? star. I appreciate the help Thank you
On 3/31/2020 11:30 AM, Tom Early wrote:
toggle quoted message
Show quoted text
If it works with PiStar (MMDVMHost), it should work with
QnetGateway. All MMDVMHost-compatible modems use the same
interface.
On 3/31/20 10:45 AM, Nomis Bayan Jr.
wrote:
Hi Tom,
Currently, I am using STM32 on a RPI 3 on converted Motorola
GM300 Dstar. Can I use GnetGateway?
On 3/31/2020 9:10 AM, Tom Early
wrote:
Thanks Al. I just love questions about Routing!
I just pushed up another release for QnetGateway that
addresses your request. It took me a while to work it out, but
I remembered that the Smart Groups Server sends a text message
"VIA SMARTGP <smartgroupname>" at the beginning of every
transmission you hear. Your radio occasionally will display
this if you watch carefully, but usually it's overwhelmed by
the senders own text message. With this new release
QnetGateway captures that "VIA" message and uses it in the
Last Heard Section of the dashboard.
So the old column that showed "Linking" or "Routing" now shows
either the Smart Group of the voice stream it's coming from,
or the reflector module it's coming from, if you are linked.
There is also a new column that shows on which configured
module the activity is happening. This is not too important to
those of us with single module systems, but it's a necessity
for those with multi-module systems.
Addressing your final comment, I agree. The Dashboard is of
questionable value to a mobile user. Not installing the
dashboard will prevent the mini-PHP Web server from running.
However, Sqlite3 is still required for QnetGateway as this is
how the gateway knows to which reflector the link module is
linked.
--
___________________________
73
n7tae (at) tearly (dot) net
|
If it works with PiStar (MMDVMHost), it should work with
QnetGateway. All MMDVMHost-compatible modems use the same
interface.
On 3/31/20 10:45 AM, Nomis Bayan Jr.
wrote:
Hi Tom,
Currently, I am using STM32 on a RPI 3 on converted Motorola
GM300 Dstar. Can I use GnetGateway?
On 3/31/2020 9:10 AM, Tom Early
wrote:
Thanks Al. I just love questions about Routing!
I just pushed up another release for QnetGateway that addresses
your request. It took me a while to work it out, but I
remembered that the Smart Groups Server sends a text message
"VIA SMARTGP <smartgroupname>" at the beginning of every
transmission you hear. Your radio occasionally will display this
if you watch carefully, but usually it's overwhelmed by the
senders own text message. With this new release QnetGateway
captures that "VIA" message and uses it in the Last Heard
Section of the dashboard.
So the old column that showed "Linking" or "Routing" now shows
either the Smart Group of the voice stream it's coming from, or
the reflector module it's coming from, if you are linked.
There is also a new column that shows on which configured module
the activity is happening. This is not too important to those of
us with single module systems, but it's a necessity for those
with multi-module systems.
Addressing your final comment, I agree. The Dashboard is of
questionable value to a mobile user. Not installing the
dashboard will prevent the mini-PHP Web server from running.
However, Sqlite3 is still required for QnetGateway as this is
how the gateway knows to which reflector the link module is
linked.
--
___________________________
73
n7tae (at) tearly (dot) net
|
Hi Tom,
Currently, I am using STM32 on a RPI 3 on converted Motorola
GM300 Dstar. Can I use GnetGateway?
On 3/31/2020 9:10 AM, Tom Early wrote:
toggle quoted message
Show quoted text
Thanks Al. I just love questions about Routing!
I just pushed up another release for QnetGateway that addresses
your request. It took me a while to work it out, but I remembered
that the Smart Groups Server sends a text message "VIA SMARTGP
<smartgroupname>" at the beginning of every transmission you
hear. Your radio occasionally will display this if you watch
carefully, but usually it's overwhelmed by the senders own text
message. With this new release QnetGateway captures that "VIA"
message and uses it in the Last Heard Section of the dashboard.
So the old column that showed "Linking" or "Routing" now shows
either the Smart Group of the voice stream it's coming from, or
the reflector module it's coming from, if you are linked.
There is also a new column that shows on which configured module
the activity is happening. This is not too important to those of
us with single module systems, but it's a necessity for those with
multi-module systems.
Addressing your final comment, I agree. The Dashboard is of
questionable value to a mobile user. Not installing the dashboard
will prevent the mini-PHP Web server from running. However,
Sqlite3 is still required for QnetGateway as this is how the
gateway knows to which reflector the link module is linked.
|
I just did an "uninstall", "clean", "git pull", and "install" in the qnadmin application. Worked perfectly, and was fairly quick.
--
??-- AL --
From: "Elmer Delgado" <w5slg@...> To: "QnetGateway" < [email protected]> Sent: Tuesday, March 31, 2020 12:39:48 PM Subject: Re: [QnetGateway] new release!
Is the procedure the same as before running the make && stuff again or just do a refresh git?
On Mar 31, 2020, at 11:35 AM, Al Gordon K7AJG <al@...> wrote:
Actually, yeah, just playing around there, interested in seeing which one (or ones) I would see on the dashboard, or if they would keep changing. A better description is that I was seeing the traffic consistently through DSTAR2, but I was able to connect/disconnect
between DSTAR1 and DSTAR2, and it worked as expected. Anyhow, I can now confirm that I should be using DSTAR2 as my primary, and only connecting to DSTAR1 if I'm having issues with that, unless things change. Makes sense, given geography and expected network
latencies. Anyhow, thanks for the updates, and tips. 73!
--
??-- AL --
From: "Tom Early" <n7tae@...>
To: "QnetGateway" < [email protected]>
Sent: Tuesday, March 31, 2020 12:29:00 PM
Subject: Re: [QnetGateway] new release!
There is no need to subscribe to both DSTAR1 and DSTAR2, they are connected to the exact same channel. You're just seen differences depending on which stream arrives at your hot-spot first.
|
Tom Early
Dan Ozment
Elden AI7HL