So some 10 hours, but mostly 5 hours before auto unsubscribe, or, a business day or half a business day (plus a bit).

Useful time outs for daily subscriptions as most people don't constantly monitor a repeater.

I agree with Jeff. Having the ability to set default smart-groups when powering on a hotspot would be helpful for smart-group users. The operator would just need to remember to set their radio to the correct smart group before keying up.

开云体育

Good point Colby.

How long before an unused default auto-unsubscribes?

开云体育

Your radio can only have 1 smart group in the UR field at any one time, so you can't subscribe to multiple groups. The routing is to your callsign. Subscribing is a matter of putting the callsign of the smart group into the UR field and kerchunking. Wait to hear the notification that you're subscribed, wait a little to see if there is a conversation already in flight, and then key up to talk.
You leave the callsign of the smart group in the UR field so long as you want to continue to use the smart group. Only need to enter the disconnect callsign when you want to unsubscribe from that smart group.

No default necessary on a hotspot as it's all controlled from the radio. :)

Not tying to hijack the thread but if Jeff’s request is possible, how about being able to join multiple default smart groups at startup or through a command (preferably via the UR method rather than DTMF). If via a command there could be another command to log out of all the currently subscribed Smart Groups in one hit?
Andy M0VVA

I just had a thought. Many of the D-STAR software packages for hotspots such as Pi-STAR has an option to setup a default reflector. Would it be possible in a future release to setup a default Smart Group that would automatically be logged in on boot of QnetGateway? The thought would be to have the software automatically login to the specified Smart Group and also have a keep alive timer so a user wouldn’t need to login again after the 5 hours of inactivity. This keep alive activity could be behind the scenes so it would talk with the SGS without keying up the Smart Group. If the hotspot were to go offline, the timer would log them out of the smart group as it does now. The timer could be set for 4 hours, 55 minutes to keep the overhead low on the SGS.

?

Not sure if this is even possible but I thought I would mention it just in case you wanted to consider doing something of this nature for a future release.

?

Jeff VE6DV

开云体育

Thanks Andy,

Sorry, I thought I had committed changes to allow at least some functionality for Kenwood, but apparently not. I'll try to revisit this soon... Now where did I put your original emails?

Great work, Tom.

I've just updated which went very smoothly and appears to be behaving as per previous versions. ?Qnadmin makes a big difference to the maintenance and I like that you can start stop process/monitor log files through the admin screen.

I'm still having no luck with the decode of APRS generated by the Kenwood TH-D74, I guess this is a low priority or not on the roadmap?

regards
Andy M0VVA

-- 
___________________________
73
n7tae (at) tearly (dot) net

Great work, Tom.

I've just updated which went very smoothly and appears to be behaving as per previous versions. ?Qnadmin makes a big difference to the maintenance and I like that you can start stop process/monitor log files through the admin screen.

I'm still having no luck with the decode of APRS generated by the Kenwood TH-D74, I guess this is a low priority or not on the roadmap?

regards
Andy M0VVA

开云体育

I offer no support for hybrid systems like that. I'm not sure even the pre-Unix socket version would work. My Icom stack support started out as a separate sources (as originally designed by KI4LKF), then I merged them (as in the "lastudp" branch). Because I have a strong bias against using pre-processor directives in my code, incorporating Unix sockets for gateway-to-modem communications means the source trees will split once again. I'll still be able to use Unix sockets for qngateway-qnlink communications in the QnetICOMGateway version on the design board now. At least that's what I'm thinking at the present time.

How will you support mixed stacks? E.g. an Icom controller and Homebrew on the same gateway

-- 
___________________________
73
n7tae (at) tearly (dot) net

Nice job Tom, will get it thrown onto one of my Raspberry Pi hotspots and put it through its paces.

Stefan (MI0PYN)

开云体育

开云体育

Once I get started, it shouldn't take too long, but I have several things competing for my time right now.

Hopefully I can get it done in 4 weeks or less.

I've never been so busy since I have retired!

Morning Tom,

?

Congratulations - sounds like a beneficial update to the QnetGateway code base.

?

Are you in a position of being able to give an estimate of the sort of timeline you have in mind for a production release of “QnetICOMGateway”?

?

?

Cheers

David ZL2DRM

-- 
___________________________
73
n7tae (at) tearly (dot) net

Morning Tom,

?

Congratulations - sounds like a beneficial update to the QnetGateway code base.

?

Are you in a position of being able to give an estimate of the sort of timeline you have in mind for a production release of “QnetICOMGateway”?

?

?

Cheers

David ZL2DRM

I have uploaded a major new release for QnetGateway with many significant changes in how QnetGateway works, and how it is maintained.

First I need to tell you that the older software is in a branch called "lastudp". Currently this is the only branch that supports the ICOM repeater stack. The "master" branch no longer supports the ICOM repeater stack. I will eventually build a new, separate git repository called "QnetICOMGateway".

The very big, very significant internal change in this new release is that all inter-process communication now takes place with Unix DGRAM sockets and no long uses UDP/IP sockets. Unix sockets have significant advantages over UDP/IP sockets. Unlike UDP/IP sockets, packets send over Unix sockets are guaranteed to arrive and they are guaranteed to arrive in the order in which they were sent! Unix sockets have significantly lower overhead and are significantly faster than UDP/IP sockets. QnetGateway uses DGRAM Unix sockets which are one-way devices. A server socket receives data and a client socket sends data. These Unix DGRAM sockets are so efficient that a client's socket is usually closed. It only opens the socket when it needs to write a packet to the server. This means that in a 3-minute D-Star transmission, the Unix DGRAM client socket will be opened and closed over 9000 times! You could never do this with a UDP/IP socket and expect to maintain a D-Star voice stream. The benefit of having a client's socket mostly closed is that several clients can send data to the same server at the same time. This makes the design and maintenance of the QnetGateway-family of programs significantly easier. The down-side of Unix sockets is that it is now no longer possible to run qngateway on one computer, qnlink on another and an rf-module on another. Unix sockets are only for communicating between processes running on the same system.

The next big innovation in all about making life easier for you, the user. Configuring, building, installing, updating and maintaining QnetGateway has been significantly improved. The format of the qn.cfg configuration file and been completely changed. Your old configuration file will no longer work! Two bash scripts are now provided, called "qnconfig" and "qnadmin".

• qnconfig (started with "./qnconfig") is a menu-driven system that will allow you to easily build or modify your configuration file, qn.cfg. Default values for every parameter are clearly listed and you just change what you need to change. At a minimum, you need to specify you callsign for logging into your ircDDB network, and you need to specify what kind of module(s) are attached to your gateway. (Depending on the module, you may need to set some additional parameters, e.g., if you are using a DVAP, you need to specify the operational frequency). If you want to use the legacy, closed-source D-Plus system, you need to enable it. It is turned off by default. When you are happy with your configuration, write out your qn.cfg file. Because the default values are clearly shown and know by all QnetGateway programs, most qn.cfg files are just a few lines. Started normally, qnconfig will only show you parameters that most users are interested in. Many of the more obscure parameters are hidden. However, you can start it with "./qnconfig expert" and you will see ALL parameters, but be careful, changing many of these more obscure parameters can break functionality!
• qnadmin (started with "./qnadmin") is also a menu-driven system that installs and uninstalls QnetGateway services based on you configuration file. It is also your "one stop shopping" place for other administrative tasks. It has a gateway file sub-menu to manage your gwys.txt file. It has a DTMF sub-menu to mange you qndtmf file. It has a maintenance menu to manage the QnetGateway services, and it has a log sub-menu to follow any service log in real-time.

DTMF has been improved with a new capability to execute QnetGateway scripts. For example, to reboot your system, send the DTMF command "##08". (By the way, new HX, RX and GX scripts now include voice messages to let you know that you are about to shutdown, reboot or restart the gateway, respectively!

Finally, while it was always there, but very difficult to use, QnetGateway and the qnadmin script support Gateway-repeater systems with more than one RF module. For example, you could set up a dual band 70cm/2m gateway based on a 70cm and a 2m DVAP dongle. A silly idea but a cute one nonetheless. A dual or tri-module repeater will support cross-banding between modules. We think it would even be possible to set up a multimodal, multiband gateway repeater system using multiple instances of MMDVMHost supported modems. If you are interested in this, let me know. I'll be glad to iron out any problems that might pop up.

Now, if you are going to upgrade to this release, be sure to completely uninstall your present system (you don't need to uninstall MMDVMHost, if you are using that).

1. This means do a "sudo make uninstall" if you are using an MMDVMHost-based modem, or "sudo make uninstalldvap" or "sudo make uninstallitap" or "sudo make uninstalldvrptr" if you are using one of the other devices.
2. Uninstall DTMF if it is running, "sudo make uninstalldtmf". and move your old qndtmf file out of the way, "mv qndtmf qndtmf.old".
3. Then move your old configuration file out of the way: "mv qn.cfg qn.cfg.old".
4. Then do a "make clean".
5. Then do a "git pull".
6. Then you should be ready to build your new qn.cfg file with "./qnconfig" and install and maintain your system with "./qnadmin".

Good Luck and Thanks for using QnetGateway!

Tom N7TAE

Thanks for help folks.?
Running both ircddb and quadnet is a not a requirement. however I do think a dashboard is essential, users want to know who or what is connected to the gateway.
Colby is assisting me in diagnosing the ircddb issues. Thanks Colby :)
73's
Simon ZL2BRG

开云体育

Hi Simon,

I appreciate your comments. As stated elsewhere, I don't support simultaneous irc networks.

I haven't spent much time thinking about a dashboard. There is a branch that has a VERY minimal control dashboard, but nothing much has happened with it since it was first pulled.

If a full dashboard is important, I suggest you look at PiStar. You'll need to switch from MMDVM to DStarRepeater. From there you should be able to configure your Icom Stack.

I'm not sure how recently Andy Taylor has updated ircDDBGateway, but if it's relatively recent, you might also be able to connect to multiple irc networks as Jonathan's newest ircDDBGateway supports this.

Tom,Joe

Thanks for the replying. Think I setup ircddb correctly. I copied the data from the old config.?

Joe, the G2 PC died. The QnetGateway is on the same local network IP as the original G2 PC, so all the existing port forwarding I have setup should still be ok.

Tom: is there a way to run both openquadnet and ircddb at the same time ?.?

The other issue I can see users complaining about is the lack of a dashboard.

Thanks for your help

73's

Simon
ZL2BRG

-- 
___________________________
73
n7tae (at) tearly (dot) net

Yes.