Support for HPSDR radios (specifically, the Hermes-Lite 2) #188
Conversation
|
Please don't take this as an offence, but technically this is not a connector. The connectors provide IQ data on a TCP socket, with an additional control connection to allow changes to the SDRs parameter at runtime. They may need to take on more tasks in the future. This is a regular SDR source that provides IQ samples on STDOUT, which are then multiplied on a TCP socket by nmux, and requiring a restart on every parameter change. While this works, I am not going to guarantee that this method will continue to work in the future. And while it works, I'd really appreciate if this could be renamed to avoid confustion. |
|
additionally, there is already code to support HPSDR devices via SoapySDR, please check out https://github.com/g0orx/linhpsdr and https://github.com/g0orx/pihpsdr. I will always prefer the use of SoapySDR since it provides a standardized API for SDR devices. |
|
Hi. Thanks for taking a look at this so quickly! My plan was always to support the socket connection method (see https://github.com/jancona/hpsdrconnector/blob/master/server.go#L46). I'll take a look at that soon. If it looks too difficult for some reason, I'll rename the project. Are you okay with leaving this PR open until I do that, or should I close it and re-open once I make a decision? My understanding is that there is no HPSDR driver for SoapySDR available. I went looking for one before writing mine, and this is all I found: pothosware/SoapySDR#260 LinHPSDR and PiHPSDR are both desktop SDR transceivers that support a variety of hardware. Much like OpenWebRX, they use SoapySDR to support some hardware. But their HPSDR implementations don't use it and indeed work fine with SoapySDR support disabled in the code. |
|
Oh, I see, you're already moving towards a fully-equipped connector, I guess we can leave this open for now then. Just to warn you, there will very likely be some additions to the connector protocol in the near future (and maybe even some documentation). I'll try to make as much of it optional, but I will at least need to establish some way to negotiate capabilities to be able to detect the new features. I did google for HPSDR SoapySDR support and it looked as if those two projects should support it. I guess they do, but obviously the other way round. Never mind then 🙂 |
|
Sounds reasonable. Is there any documentation for the connector protocol other than the code in https://github.com/jketterl/owrx_connector? |
|
Unfortunately not at the moment. The connectors grew with OpenWebRX so far. I hope I can improve stuff in the future, maybe I can even offer some basic connector framework where you'd only need to implement some callbacks. I will need to work on my C skills though, right now I cannot do it yet. |
|
I updated my code to support the connector protocol. It seems to work pretty well. Let me know what you think. |
owrx/source/hpsdr.py
Outdated
| "samp_rate": Option("--samplerate"), | ||
| "remote": Option("--radio"), | ||
| "rf_gain": Option("--gain"), | ||
| "debug": Flag("--debug"), |
There was a problem hiding this comment.
I don't think that this should work as expected; There's no debug config option that would trigger this. While this may work under certain circumstances, I don't think it's very useful because this option is neither in the documentation, nor on the other connectors.
|
Alright, this looks like it should work in general, just the minor detail about the |
|
I'll remove the debug line and I'll create the wiki page once the code is merged. Should I also add a note in config_webrx.py, similar to what's there for Perseus? |
|
You can add it to the list of supported types, but I'll probably need to remove the more detailed instructions (both rtlsdr and perseus). The full list of instructions for all SDRs is too long for the config, so the wiki is the right place for detailed instructions. |
|
OK, I removed the debug option and just added hpsdr to the list of supported receivers in config_webrx.py. I will add a wiki page once you merge this PR. Thanks! |
|
Thanks for merging this! Should use the 🛠️ symbol in the last three columns on this wiki page: https://github.com/jketterl/openwebrx/wiki/Supported-Hardware ? |
|
For now, the 🛠️ symbol would fit the first two columns. Docker would get an ❌ because I don't exactly think it's reasonable to go into a docker image and install software. It shouldn't be that hard to include this in both docker and RPi images, though. We could even attempt to set up a Debian package build. |
|
I've gone ahead and added a line for HPSDR because that table is pretty much impossible to work with on the web-based editor, I'm typically maintaining it using my IDE. |
|
Thanks! I am going to work on using Github actions to build and release |
|
just tried to set up the hpsdr connector in lastest openwebrx dev build. go and hpsdrconnector is available for any user but /features lists hpsdr as NO. Any hint what to look for? |
|
The feature test tries to run |
|
pi@openwebrx:/usr/sbin $ sudo runuser -u openwebrx hpsdrconnector looks good, but still to no avail. perhaps go-related, as i had to manually install golang (raspi repo version is too old). My testing environment is a RasPi4B using the current OpenWebRX RasPI image and switched to dev repo. Jim, did you already build the static hpsdrconnector binary for armv6? I'd like to drop that one in and try again. |
|
OK after rebooting and multiple refreshes on the status page, it's there....i will go on testing now. My goal is to integrate Red PItaya (14-bit and 16-bit versions) via hpsdr mode in OpenWebRX
|
|
Would be more reasonable to work out the already existing "red_pitaya" type... |
|
is there any progress on the red_pitaya type? you mentioned some time ago that this does not work? |
|
I don't think so. As far as I understand, though, the problem is within the SoapySDR module, not OpenWebRX. I cannot work on any of that though since I don't have a red pitaya device. |
|
O.K. then Jim's approach seems valid for the red pitayas. Hpsdr mode is their standard mode of operation as ham sdr so this should be fine. |
|
great. but I don't want to have multiple implementations of the same SDR in OpenWebRX. |
|
That's reasonable. If the new connector runs stable on redpi, I propose you drop the red_pitaya type until there's substantial progress in the soapy redpi support. |
|
Glad you solved the detection problem, Stefan. I don't have a Red Pitaya, so I'll be interested in whether it works for you. I found https://pavel-demin.github.io/red-pitaya-notes/sdr-transceiver-hpsdr/. Is that the HPSDR implementation you use? Which desktop client software works well? |
|
yes that's exactly what I'm using....first results are promising :-) thanks for your efforts Jim! |
|
Great! I added a Tested Hardware section on the wiki page. Once you're satisfied that it's working well, either let me know and I'll add it or you can edit the page yourself. |
|
It was running for 2 hours now without problems. I can edit the page. So now how about multiple streams? At the moment, the hermes device stays on the band that was selected by the first user and can be accessed by multiple users. Additional streams are not available. Red Pitaya in HPSDR mode supports up to 8 parallel streams (14-bit RedPi) or 16 streams (more expensive 16-bit RedPi), 192Khz each. With HL2 this should be similar. Must additional streams be defined as separate devices in the OpenWebRX config or is this not possible up to now? My idea is to run 8 streams/bands in parallel, using background decoding for FT8, FT4, JT9 and JS8 on 8 bands (or even more on 16-bit RedPi) when no user is connected. |
|
Thanks for editing the wiki. Yes, multiple receivers is the next thing for me to work on. I need to understand how it would be supported on the OpenWebRX side as well as extend my HPSDR code to support multiple receivers, so it may be a while. Do you know of a currently OpenWebRX-supported device that can do something similar? It might help me understand how to approach it. |
|
Looking at the list of supported hardware, i think that only the last series of SDRplay devices support multiple receiving slots, but here i don't know if Jakob implemented this. He might have an answer to this. Up to now, i only worked with single-stream devices (rtlsdr, airspy, PlutoSDR) in OpenWebRX, so this will also be a new topic for me :-) i have also worked with a kiwiSDR, but that really is not comparable, since here the full HF band is processed by the fpga. |
|
Multiple receivers are currently not supported. I've been brooding over this for some time, but there's many use cases involved that make it hard to come up with a reasonable protocol, I'm currently attempting to get the duplications out of the connectors. This is not a topic for here, though. |
|
@jketterl What's the preferred place to discuss this sort of thing? The mailing list? |
|
We tried to establish a discord server (https://discord.gg/gnE9hPz) for discussion, but it hasn't seen much use. There hasn't been much discussion so far either, mostly just support stuff (which the mailing list is for). |
This uses a connector I wrote: https://github.com/jancona/hpsdrconnector
See the README in that repo for installation instructions and current limitations.