Server rework

[jketterl]

Hello fellow OMs, Hello fellow developpers,

I have been working on openwebrx for some time now, my previous work was an attempt to get digital voice modes (DMR, D-Star et al) into it, and while that worked, I also learned that the internal structure is basically one big read loop, that somewhat dictates the way data is delivered to the client.

I have also taken note of one of the biggest requests that seems to have been prevalent over the "Issues" section here, which is the wish to be able to change the center frequency remotely.

With those two main things (and some other feature ideas, see below) in mind, I set out to rewrite the basic core server of openwebrx. This new core uses threads, rather than a read loop, to deliver data to the client. It also uses a somewhat homemade property system as configuration, that allows me to subscribe to config changes and restart / reconfigure components of the system as needed.

I have tried to limit my changes to the dsp section and the frontend to a minimum. I have also not created a new frontend (yet?) that allows complete freedom of frequency switching, even though it is completely possible, as of now, along with changes to gain and sampling rate if you know what command to send over the websocket. What i have created for now is the ability to switch between predefined "profiles", which can be set up by the server administrator. I think it should be easy to understand if you have a look at the example config in the pull request.

The rewrite also allows the new core to use multiple sdr devices at the same time (check the config) which is a pretty neat thing. I currently have an rtl-sdr stick running for VHF/UHF and an SDRPlay for shortwave.

The new core also has a module for feature detection, that is not fully developped yet. I do intend to enable/disable future features, depending on which dependencies are available. I also have a certain idea of a "feature detection report" that will give the user an idea of what potential features are disabled, and how to unlock them.

I have used python 3 for all development, I have not tested it with python 2 yet, but I am expecting it to be broken for now. Depending on how bad it is, it might be simpler to just upgrade to python 3.

Future ideas that i would like to work on, based on this:

• port the digital voice modes over (DMR, D-Star, YSF, NXDN)
• direwolf integration to decode APRS and possibly show a map, maybe also other packet modes
• more HF digital modes (RTTY, Olivia) - I do not have decoding capabilities for those yet.
• some kind of FT8 integration

I do also have a demo version of this running that you are invited to visit: http://sdr2.justjakob.de/

I hope you like this rather bold attempt of a complete rewrite. I have tried to submit my past work to here, but never could get it to "look right", and I always felt like something like this was necessary to round things up, but of course adding a rewrite on top would not have been a good idea. I also never knew if I could actually bring up enough time and motivation, but now that I have, I am more than happy to submit this pull request.

Please let me know what you think. I will gladly work on any comments and improvements :)

Also, please let me know if the contributing guidelines are still up to date. I am more than happy to provide you with an ICLA form.

All the best and 73s Jakob DD5JFK

[ha7ilm]

Dear Jakob,

Thank you for your work on OpenWebRX, and the pull request. I appreciate your contribution very much, however, I won't be able to merge it this time. Your patch is a complete rewrite of the backend, which I wouldn't be able to tackle if something goes wrong. I hope you understand this and won't take it as an offence.

As a note, the original OpenWebRX does not allow you to change receiver settings that affect other users. In this form (at least with these default settings) this would break OpenWebRX for those who want publicly shareable receivers. In addition, I think restarting the rtl_sdr process each time with different parameters will not allow changing the center frequency with the mouse as smoothly as in other SDR software, so I think it's not the best way to go in the longterm either.

VY 73!

András, HA7ILM

[jketterl]

Hello András,

first of all, I do understand that you would like to be "on top of your code" and be able to work with it efficiently instead of spending hours of debugging. I have been in such situations myself, and I guess most people who work on software have been.

I must however also say that this is really discouraging for me: This pull request is the base on which i intend to build a bunch of new features, and this means that many people using openwebrx won't even take notice of them. I will of course make all my work available on my own repository, but I don't expect many people to find it.

As for the config changes: I packed a lot of stuff into the config to show what can be done, please don't take that as a reference. I don't intend to break any public receiver, on the contrary: My intention was to offer new options to whoever is operating one. As long as you configure a single sdr with a single profile, the behaviour should be largely unchanged. With the changes in place however you have the option of adding a second sdr device and have them operate on separate bands simultaneously. Or, if you operate a less-frequented receiver, you have the option to setup multiple profiles, hoping that if you ever have more than one user, they will agree on a band in some way. (If somebody has an intelligent solution for this, I'd be happy to implement it. I hesitate to give priority to any one user, though.)

I have also read up on a few old discussions and indeed understood that offering full frequency control might be a bad idea due to legal reasons. There's a few lines of code that I'd need to remove to lock the receiver down to the configured profiles. I have left them in place because they are useful for debugging purposes.

As for the smoothness... Having used this version for some time myself now, I am very well aware... It's what I could do while sticking with rtl_sdr. I have been pondering the thought of connecting this up to rtl_tcp or SoapyRemote for some time now. I don't know the protocol yet, but it can't be that difficult. I do think that the event structure should handle it, but this would mean even more changes, this time potentially breaking changes, since to my knowledge not every supported hardware offers the necessary interface as a standalone binary.

73s and have a nice weekend Jakob DD5JFK

[Lonecrowe]

This is fantastic great work. Shame he wouldn't use it. At least you are working on it.. I think I may switch. Now just add labels to freqs and I'll be happy :)

[D0han]

I already switched to the forked one