开云体育

Another new release has been merged into the master branch. This contains the DPlus authorization that I've been talking about the last few posts, and a bug fix for DPRS. Based on some information from the field (thanks Carty!), QnetGateway will attempt to connect to auth.dstargateway.org three times before it gives up. You can always update your gateway list by sending an " F" to QnetGateway. This command will clear you current gateways list, and then reauthorize DPlus (if enabled) and reread your gwys.txt file. Sometimes, I'm my own worst enemy. I have been working on many internal changes to make the code more understandable and supportable. During this process, I accidentally introduced a bug in APRS causing most updates to the aprs.net website to fail. This has been fixed and if you have aprs enabled in QnetGateway (it's on by default) and you've enable the GPS in your radio, you should see your position frequently updated in the aprs.fi website. (Thanks Colby!). Of course this release contains the two new voice prompts. When you are first connected to rr.openquad.net, you system will tell you with a "connected to QuadNet" message. Also, if you try and route to a target for which QnetGateway doesn't yet have an IP address, then you will receive a "not in cache, please try again" message. By the time you receive this voice message, QnetGateway will have ask QuadNet how to route your traffic, and you should be good to go on the next key-up.

I put together this matrix to address questions about functionality - it is simplified and open to updates. Gateway Feature Matrix Feature G2 G3 G3 + ircddb G2 + ircddb ircddbgateway Qnetgateway US Trust Registration Page for Users Y Y Y Y N N BPLUS Reflectors Y - Add-on Y - Add-on Y - Add-on Y - Add-on Y - Built-in Y - Built-in DPRS (AE5PL Code) Y - Add-on Y - Add-on Y - Add-on Y - Add-on Y - Add-on N DPRS Reporting (Non-AE5PL) N N N N Y - Built-in Y - Built-in Icom Terminal and Access Point Mode N Y Y N Y Y Call Sign Routing Icom to Icom Gateway Y Y Y Y N N Call Sign Routing Icom and ircddb N N Y Y Y Y Calls Sign Routing to/from Hotspots N N N N Y Y STARnet Digital Talk Groups/Smart Groups N N Y Y Y Y XRF / DCS / XLX Reflectors N N N N Y Y D-RATS Port on Gateway N N N N Y N Smart Groups and Callsign Routing to Hotspots on ircddbgateway require reporting into quadnet. Current ircddbgateway can support more than one ircddb server. By policy, the ircddb.net server is meant for repeaters only, but could support hotspots, however better support for hotspots is found on https://openquad.net/ Users can register for US Trust (only necessary for G2/G3 callsign routing and DPLUS reflector commands) at a G2/G3 gateway or https://regist.dstargateway.org -- John D. Hays Edmonds, WA K7VE

For those of you that are interested, I could use some help... I have a branch of the QnetGateway github repository called "dplus" that contains what I believe to be the proper way to authorize on the closed-source DPlus system. It's not working for me, but I think there is a problem with my callsign registration. Another user tried it, and it seemed to work for him. If you are interested, please try this branch and respond back to this thread with you findings. To use this branch, go to your build directory, uninstall your working version, do a "git pull" and a "make clean" and then a "git checkout dplus". Then you should be able to make and install this new branch. To switch back to the master branch, first, uninstall your dplus version, do a "make clean" and then do a "git checkout master" and then do a make and install to reinstall the release version. If you "alpha testers" report that it is working, I will add some new configure variables so that you can more finely control how the authorization is done and merge that into the master branch. Thanks for your help.

When you receive a new groups.io message in your inbox and you reply to it, your reply will be posted to that message thread. Please don't "derail" a thread by posting an unrelated comment or question to that thread. It makes it more difficult for others to find useful information. Either find a more appropriate thread to post your comment or question, or create a new thread! It does take an extra step to do this: you have to log into groups.io first! Thanks!

I merged a new version of QnetGateway into the master branch of the QnetGateway repository. This has a cool new feature especially designed for mobile users who like to route, but will benefit others as well. As part of this new feature release, I have completely rebuilt all the voice message mechanisms in QnetGateway. They use a totally different format and voicemail, echo data and the various voice prompt files are significantly smaller. Originally stored as DVTOOL file format, the new format only contains the raw AMBE data. When needed by QnetGateway or QnetLink, they will dynamically build an appropriate header and package the raw AMBE data into properly formed AMBE voice packets. Two new messages have been added to help a user do routing. First, you will hear a "Connected to QuadNet" message after you boot up when QnetGateway has fully logged into rr.openquad.net. Any attempt to try to route before you hear this message will be ignored by QnetGateway, so having this voice announcement will be very helpful to mobile users. The way routing works is that while QnetGateway is running, it maintains a database (a cache) of all other users that are using the QuadNet network. Whenever anyone keys up, all users on the network are sent a message containing the callsign of the user and the repeater channel, gateway and IP address of the repeater they used. When you first start QnetGateway, you cache is empty. If you try to route before your QnetGateway knows about your intended target, it will ask the QuadNet server how to complete your call. This request talks less than a second to complete with a typical internet connection. The second new message, "Not in cache, please try again" will be played if you attempt to route but your gateway doesn't yet know the IP address and the last used repeater of your target. By the time you hear the "Not in cache, please try again" message, your gateway will ask the QuadNet server the data of your target and you can key up again to complete your Smart Group subscription or place you Callsign Route to your friend. This will be a huge benefit to mobile users, and anyone who like to route. If you hear the "Not in cache, please try again" message a second time, either the QuadNet server has no data for your target, or you are having internet problems with your client. (It's also possible that the QuadNet network is down, but this is extremely rare.) FInally, the systemd startup scripts will try to make sure that QnetGateway will only start after the network has been established by you node. However, when your node is tethered to a smart-phone, QuadNetGateway may not initialize properly on the first attempt. If that happen and you never hear the "Connected to QuadNet" message, or your repeatedly hear the "Not in cache, please try again" message while attempting to route, you can restart your QnetGateway program by putting " GX" in your radio's YOURCALL and keying up. This new command will execute a script that will cause systemd to restart QnetGateway. This is useful because you won't have to reboot Linux, you'll just be restarting your gateway. Please refer to the WIKI for information about how to upgrade you software.

At the Digital Communications Conference in Albuquerque last month, John Hays, K7VE, told me that the G2/G3 Trust system has changed how gateways/users are authenticated. I got the technical details on Sept. 22. I will fix this in QnetGateway, but it will take some time. I would really like to thank John for keeping me "in the loop" on this! In the meantime, you should probably not attempt to link to G2/G3 reflectors or repeaters using QnetGateway as that activity might get you banned on the Trust system. I know that some of you have very recently connected to these systems successfully, but that could change at any time. I will post another message when a new version with proper authentication is available. Please note that REF linking to XRF and XLX reflectors is NOT affected.

Colby W1BSB and I have been very busy! We have been working on an intermittent problem with the "follow me" feature of Routing. We think we have finally locked it down. Some changes have been made to the QuadNet servers and as part of that effort, we have also been working on the qngateway program. Many internal changes have been done to qngateway and some problems I accidentally introduced in the previous release have now been corrected. If you need help in upgrading, see the Wiki, or post your questions here. Tom N7TAE

Unfortunately when I incorporated new code to support the Icom Stack repeater, I inadvertently introduced a bug that prevented you from properly receiving a one-to-one Callsign Route. You could still complete the call, but you had to manually enter your return path into the YourCall field of your radio. This has been fixed and QnetGateway, QnetRelay and QnetDVAP have been update to fix this problem. Thanks to Carty, KA2Y for bringing this to my attention. Don't forget there is an "Updating QnetGateway" Wiki page on this site if you need help in updating your software.

Hi Colby, I have no problem linking to another reflector, like REFxxx, but I tried linking to the Papa System repeater and repeater on the dstar list on my radio but was not able to link. Please advice.

Any way to change YOUR CALL with a DTMF script command? Tom, you have taken this past where I ever dreamed QnetGateway could ever go, so why not ask for the Moon?

I'm attempting to use a D-Star radio on Terminal mode with the Raspberry Pi and data cable. I'm down to step 5/6 of the MMDVM.README and when I start MMDVM ./MMDVMHost MMDVM.qn I get this: Cannot open device - \\.\COM3 I'm not sure what i need set the port to?

Hi Colby, Others from the group want to try to link their hotpot to the repeater. I provided the instruction to them to add the repeater call sign and update the DPlus host file , just like what I did. Do I need to configure any on the QnetGateway for them to link their hotspot to the repeater? Thanks.

Hello, I was able to set up the IP address for the 2nd NIC, as shown below "enp4s0". Ping Gateway 172.16.0.20 and controller 172.16.0.1 all okay. But failed qngateway.service shown below. Anyone could provide guidance. Thanks. root@nolyn78dell:/home/nolyn1978/QnetGateway# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 18:0f:76:cc:18:fa brd ff:ff:ff:ff:ff:ff inet 172.16.0.20/24 brd 172.16.0.255 scope global enp4s0 valid_lft forever preferred_lft forever inet6 fe80::2007:6e18:1a5f:56c9/64 scope link valid_lft forever preferred_lft forever 3: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 14:fe:b5:df:c6:c2 brd ff:ff:ff:ff:ff:ff inet 192.168.1.170/24 brd 192.168.1.255 scope global dynamic enp0s25 valid_lft 86186sec preferred_lft 86186sec inet6 fe80::16fe:b5ff:fedf:c6c2/64 scope link valid_lft forever preferred_lft forever root@nolyn78dell:/home/nolyn1978/QnetGateway# systemctl status qngateway ● qngateway.service - QnetGateway Loaded: loaded (/lib/systemd/system/qngateway.service; enabled; vendor preset: enabled) Active: failed (Result: signal) since Sat 2018-09-08 21:33:44 PDT; 6min ago Process: 1409 ExecStart=/usr/local/bin/qngateway /usr/local/etc/qn.cfg (code=killed, signal=SEGV) Main PID: 1409 (code=killed, signal=SEGV) Sep 08 21:33:44 nolyn78dell systemd[1]: qngateway.service: Main process exited, code=killed, status=11/SEGV Sep 08 21:33:44 nolyn78dell systemd[1]: qngateway.service: Unit entered failed state. Sep 08 21:33:44 nolyn78dell systemd[1]: qngateway.service: Failed with result 'signal'. Sep 08 21:33:44 nolyn78dell systemd[1]: qngateway.service: Service hold-off time over, scheduling restart. Sep 08 21:33:44 nolyn78dell systemd[1]: Stopped QnetGateway. Sep 08 21:33:44 nolyn78dell systemd[1]: qngateway.service: Start request repeated too quickly. Sep 08 21:33:44 nolyn78dell systemd[1]: Failed to start QnetGateway. Sep 08 21:33:44 nolyn78dell systemd[1]: qngateway.service: Unit entered failed state. Sep 08 21:33:44 nolyn78dell systemd[1]: qngateway.service: Failed with result 'signal'.

I have been trying DTMF control with QnetGateway in Itap mode in a mobile environment today. It appears that I can not stay linked for more than a few minutes. REF001C, REF030C, XRF757A, DCS307D. I would send the logs for qnetgateway, qnlink and qnitap but I can not seem to locate them. On a side issue, I was trying to have the RPi 3B+ hooked to the ID-4100a and expected to switch back and forth on the ID-4100 between Normal mode and Terminal Mode. It "appeared" that I needed to reboot the RPi when going from Normal mode to the Terminal Mode on the ID-4100. Is my perception based in any reality?

Functionally, I thought I had a good idea. Now I think I am looking at the impossible. Bash scripts do not control the radio - they issue Unix commands. Are the commands from the radio to QuadNet digitized - as in passed through the Vocoder? Or are they character data strings that could be passed to QuadNet?

Can I use the Raspberry Pi 3 for the gateway on Dstar ID-RP2C Controller. It seems that I needed two NICs cards, PI star has only one. N0MIS

I have done a major overhaul of QnetLink. I managed to find and fix a couple of small bugs along the way. I've been using it for several days without any problems and have merged it into the master branch.