|
Re: ircddb repeater status = red
开云体育Just to make it clear, this is for configuring Jonathan Naylor's ircDDBGateway, not QnetGateway. It was made clear to me in my discussions with the admins at
ircddb.net that they don't want clients simultaneously logged into
both ircddb.net and QuadNet. I'm not going to defend their
position, but I am going to respect it. Therefore both QnetGateway
and the SmartGroupServer does not support simultaneous logins. On 12/12/18 5:48 PM,
david.murray@... wrote:
-- ___________________________ 73 n7tae (at) tearly (dot) net |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: ircddb repeater status = red
开云体育Hi Simon, Your the first to connect an Icom stack to ircddb.net using QnetGateway, so I'm not sure what the problem is with the two modules. Are the frequencies and other data for the modules okay? I would be happy to provide a fix, if I knew what to do. Someone from ircddb.net needs to help and let us know how to get things green. I suspect I'm malforming or missing an IRC message to the IRC server. You can, of course, switch to rr.openquad.net. I think we more completely support routing, especially group routing. Of course if you have users that are callsign routing or repeater (zone) routing to nodes on ircddb.net, they won't be able to do this if you move to rr.openquad.net. Tom On 12/12/18 3:30 PM, Simon Eatough
wrote:
Hi? -- ___________________________ 73 n7tae (at) tearly (dot) net |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: new release!
I pushed up another new release today. This fixes several problems with APRS (position tracking), the most important was that your position was only occasionally being updated. If you don't disable APRS in QnetGateway (it's enabled by default), and you enable GPS on your radio, you position can be tracked at sites like aprs.fi. With an Icom radio, if you use D-PRS mode (found under the "GPS TX Mode" in the GPS menu), you can set the position icon that is displayed on the website using the menu system on your radio. If you use a Kenwood radio or if you use NMEA GPS on an Icom radio, you position will be tracked with a blue dot.
If you specify your hot-spot/repeater location, along with a description, in the "module" section of the config file, your module(s) will also be shown as a black "D" diamond. Obviously, since this hot-spot position is hard-coded in your config file, you don't want to specify it for a hot-spot whose location is variable, like a mobile rig. Even if you don't track the hot-spot, QnetGateway can still pass user positions to the aprs network. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [DStar-Gateway] Re: G3 Installation new
开云体育Hi John, If I decided to select the ircddbgateway, then where can I
download and install the software. How about support?? Will I be
able to get support if I have some issue with the installation?
Thank you so much for providing the comparison. On 10/25/2018 11:44 AM, John D Hays -
K7VE wrote:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [DStar-Gateway] Re: G3 Installation new
I put together this matrix to address questions about functionality - it is simplified and open to updates.
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 server is meant for repeaters only, but could support hotspots, however better support for hotspots is found on Users can register for US Trust (only necessary for G2/G3 callsign routing and DPLUS reflector commands) at a G2/G3 gateway or On Wed, Oct 24, 2018 at 9:07 PM John D. Hays <john@...> wrote:
--
John D. Hays Edmonds, WA K7VE  ? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: new release!
Sorry about this if you've been trying to keep up with the releases, but I pushed up another release this morning! With this new release, when you link or if you try to link and your already linked, QnetLink will enunciate the link with a voice message, like "the module is linked to X R F seven five seven alpha", or "the module is already linked to X R F seven five seven charlie".
This release is for you "linkers", but I hope you will give routing a try. Most hams who try it, like it! In case you are wondering, I use fromtexttospeech.com to generate original voice files in mp3 format. Then I use mpg123 to convert the mp3 file to a wav file. Then I use my own custom "OOT" module for gnuradio-companion and it uses a Northwest Digital ThumbDV to convert the wav file to AMBE data. It's a simple 3-step process that takes a few minutes to generate a new AMBE file. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: new release!
I just pushed up another version that contains some additional tweaks to QnetLink for DPlus authorization. Thanks to Carty, we found out that using systemd to wait on the network is not enough, so I've added some code that will wait as long as necessary to make the connection. In Carty's case, it looks like his wifi RasPi was taking about 15 seconds to get fully connected after systemd said the network was ready!
In a related development, I've added another voice message in this release: If you try to link to a reflector or repeater that is not in the QnetLink gateways list, you'll get a voice message. If you were trying to link to a DPlus reflector/repeater and got this messge, it probably means that your target wasn't downloaded during the authorization. If you were trying to link to a non-DPlus system, the callsign wasn't defined in your gwys.txt file. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
new release!
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: DPlus authorization
It seems DPlus authorization is working properly (thanks Colby and Carty!) and has been incorporated into the master branch. To enable it, put:
dplus = { ????? authorize = true } into your qn.cfg file. If you have been on another branch, first uninstall your software, then do a "make clean", a "git checkout master", a "git pull" and then you can rebuild and re-install your system. See the various example .cfg files for ways to fine-tune what is done with data returned from the the authorization server. Also, the gwys.txt file is read AFTER DPlus authorization, so entries in your gwys.txt file will over-write any data returned from the DPlus authorization server, so you may want to edit gwys.txt. Jonathan Naylor's ircDDBGateway will re-authorize DPlus every 6 hours. With QnetGateway, you manually re-authorize by trasmitting "?????? F" into your system. The data returned from the DPlus authorization server changes from hour to hour as systems go up and down. Much credit goes to Jonathan for authorization code used in QnetLink. His copyrights are still attached to code in the QnetGateway repository that are derived from his work. PLEASE NOTE: Currently, there is no way for QnetLink to confirm that your callsign has actually been accepted by the DPlus authorization server. If you are unlinked after you try to transmit into a DPlus reflector or repeater, it means that your authorization failed. Either something failed in the authorization exchange, or you have been blocked from use ("black listed") on the DPlus system. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Please help keep the message threads relevant.
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! |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
DPlus authorization
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
new QnetGateway version with a new feature
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 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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: ITAP seems to have stopped working after update
Hi Russell,
I'm not quite sure what went wrong originally, but I'm happy your up a running again. The extra commands were to just make sure you didn't somehow end up on an unstable development branch. "ps aux | grep qn" is a great way to make sure you don't have an unwanted QnetGateway app running. It's easy to get into this state if, for example, you have a Raspberry Pi that is used for both ITAP mode and MMDVMHost mode. Being ever vigilant, ps aux will also report that you are also running a grep command looking for "qn". To sharpen your Linux skills, if you don't want to see the grep line, you can do "ps aux | grep qn | head --lines=-1"! Tom N7TAE |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: ITAP seems to have stopped working after update
Tom,? Thanks, that got me going again! Here is some output when I was going through your attached steps: Already up-to-date. Already on 'master' pi? ? ? ?28030? 0.0? 0.0? ?4376? ?580 pts/0? ? S+? ?21:25? ?0:00 grep --color=auto qn Originally, I tried doing the "quick" update then when it wasn't working i did the longer steps but this but what you just sent is what fixed it. Still not sure if I did something wrong during the update?? Thanks for the excellent support as always!! 73, Russell On Fri, Oct 5, 2018 at 7:28 PM Tom Early <n7tae@...> wrote: Hi Russel, |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: ITAP seems to have stopped working after update
Hi Russell,
Sorry your having trouble. Your R1 and R2 are backwards in qnlink. I don't know why that's happening. Please go to your build directory and do: sudo make uninstallitap make clean git pull git checkout master make itap Don't forget to add -j4 to the end of the make command if you are compiling on a regular Raspberry Pi. Then before you reinstall, check to make sure no other QnetGateway process are running: ps aux | grep qn Then you can get more log output by adding: log = { ???????? qso = true } to the end of your qn.cfg file. Then you can reinstall: sudo make installitap Then you should see a lot of log entries every time you key up or something comes in. (You can remove the log stuff after you get things working again, if you want.) qnlink should have your configured repeater module in R1 and your gateway channel in R2. |
Tom Early
John Hays - K7VE / WRJT-215
Russell, KV4S