Using the RX888 as a multi channel receiver for WSPR for scientific research

[fventuri]

Hi, this is Franco Venturi K4VZ (you might remember me as the author of the libsddc library).

Together with Clint Turner KA7OEI and Rob Robinett AI6VN (the author of WsprDaemon) we are trying to figure out if the RX888 could be successfully used as a wideband receiver to receive the 14 WSPR/FST4W frequencies on all the LF/MF/HF bands + the 5 WWV signals for scientific and academic research on the ionosphere.

This is one of the main subjects of interest of the HamSCI group (https://www.hamsci.org/); they had a workshop a few weeks ago where Gwyn Griffiths G3ZIL gave a talk about using WSPR and FST4W to study propagation modes in the 20m band (http://wsprdaemon.org/ewExternalFiles/Griffiths_FST4W_2023_HamSCI.pdf).

We are currently using KiwiSDRs with WsprDaemon, however the KiwiSDR hardware is no longer being manufactured so we are looking for other options, including the RX888.

A few days ago Clint came across your master thesis, and we saw that you already have done a significant amount of work in this direction, so we are really interested in discussing about your experience with the RX888, and if you (or your advisor) are still working on this exciting project.

I opened this issue just to introduce us and learn more about your work; we can continue this conversation via direct email if you prefer - just let me know.

Thanks, Franco

[tejeez]

Nice to hear you are interested! I actually thought of mentioning this project in the NextGenSDRs group but I was so busy writing the thesis I forgot.

Receiving WSPR simultaneously on all bands should be possible and I have been planning to try that next. The whole idea was somewhat inspired by a multiband WSPR receiver I hacked together years ago.

I think the RX888 is a cool project. I had been looking for easy ways to get those >60 MHz sample rates directly to a PC for a long time, and RX888 was just what I had been looking for. I felt it was interesting enough I could live with the somewhat unfinished software support.

Indeed, software seemed to have a lot of room for improvement at the time (roughly two years ago). I haven't really been following what's happening with the more "official" driver libraries. I don't really like the way they seem to combine the driver and the DDC algorithm together in a single library. I prefer being able to re-use the same DSP code with different radios and that's one reason I created Spektri.

Right now, I don't have any clear roadmap for the project, as I wanted to have a bit of break from it and do something else for a while. It's my own hobby project from now, so I'll work on it if I feel like it. Seeing someone actually use Spektri for something might encourage me to continue working on it!

There are some things I'd still like to do to make the software easier to use. The repository is a bit messy and would certainly need some cleanup and documentation. I'd also like to write a SoapySDR module to get data from Spektri, as that would allow using a lot of existing applications together with it.

I prefer continuing the conversation here, so anyone who's interested can also follow what's happening.

[fventuri]

Tatu, thanks for your reply!

I agree with you about mixing together the low level driver and the DSP work. I don't think much has changed in the ExtIO_sddc in the last couple of years. The good news is that the FX3 firmware is open source, and it is in the ExtIO_sddc repository, so it shouldn't be too hard to remove all the unnecessary parts (for instance we don't need/care about the VHF tuner, since our goal is just HF and perhaps low VHF directly from the ADC).

Since we need to have very accurate timing in order to correlate different receivers in different places, we were thinking about a GSPDO (like Leo Bodnar mini-GPSDO) to drive the oscillator; not sure if you have thought about that (or have direct experience with it).

Another thing we'd like to do in the FX3 firmware is to add some sort of 'timestamp' derived directly from the GPSDO; I am not sure if it is possible, but perhaps the output stream could contain every so often a special 'packet' containing the sample number from the ADC/FDX3 - this way with a GPSDO it would be possible to have some sort of relative timestamp.

We haven't thought yet to a good way of relating these timestamps before and after the fast convolution filter bank; if you have any ideas or suggestions, please let me know.

Thanks, Franco

[tejeez]

I'm not familiar with the FX3 so I have no idea how difficult it would be to implement timestamps using additional packets. One idea I've had is that if the ADC had less than 16 bits (say, 14 bits), a PPS line from GPSDO could be connected to the least significant bit of the 16-bit bus. That would need no additions to the firmware. Driver or signal processing code could then calculate timestamps by checking the LSb of each sample. That won't work with RX888's 16-bit ADC though.

I have thought about timestamping support a bit. Spektri already takes a "wall clock" time from the computer when samples arrive, carries that through the signal processing chain and sends it together with filter bank output in ZeroMQ messages. It is possible to add more metadata fields such as an "SDR timestamp" in the same place.

Maybe that "SDR timestamp" could be a free-running sample counter that starts from 0 when the SDR starts and whose value is not adjusted by GPS or anything. Then there could be a separate way to ask for the current difference between GPS time and SDR time. Adding these values would then give actual GPS-referred timestamps for samples. I think that's how some SDRs with GPS timestamping support do it.

The fast convolution filter bank itself, like any filter, adds some constant delay to a signal. That can be calculated and compensated for in output timestamp values.

[tejeez]

Btw, regarding software architecture around timestamping, I'd avoid adding anything too RX888-specific in Spektri itself. My preferred approach would be adding support for sample input by SoapySDR and then implementing a SoapySDR driver module to get raw samples from the RX888. The SoapySDR API already supports such "sample counter" SDR timestamps and several SDR drivers implement those.

The way to obtain relationship to GPS time could be also modeled after other SDR drivers. For example, with USRPs, you can call getHardwareTime("PPS") which tells you what the SDR timestamp was at the time of the latest PPS pulse. Maybe a similar mechanism could be used here. Maybe an USRP could even be used to prototype timestamp support in signal processing software before it's fully implemented for something RX888-like.