What is the frequency and time domain accuracy and resolution of a demodulated stream?

My collaborators Franco K4VZ and Clint KA7OEI have introduced me to your work which I think might be of great value to the Wsprdaemon (WD) software project currently in use at most of the top WSPR spotting stations worldwide.

WD is an open source (https://github.com/rrobinett/wsprdaemon) Linux service which records wav files from one or more KiwiSDRs, decodes them from those files in multiple formats now offered by WSJTx (WSPR-2, FST4W-120,-300,-900,-1800) and posts the found spots to wsprnet.org. In addition, WD posts enhanced versions of those spots to a public WD database which includes background noise level and millihertz resolution frequency values . That additional spot information has led us to new insights into HF radio propagation as is shown in a paper presented by our collaborator Gwyn G3ZIL at last month's HascSCI workshop: http://wsprdaemon.org/ewExternalFiles/Griffiths_FST4W_2023_HamSCI.pdf

The KiwiSDR is a marvellous tool for WSPR recording and serious scientific research, and John Seamons has enhanced the kwirecorder client utility used by WD so much that the Kiwi the only SDR I have seriously supported. But as I'm sure you know the Kiwi is no longer being manufactured, and we are also starting to exceed the limits of its capabilities for example in the number of simultaneous channels. Some of the WD sites are operating 7 of the GPSDO Kiwis in 14 channel mode and are still running short of receive channels. Furthermore I am currently adding support for doppler shift measurements of all 5 WWV signals in addition to the 14 LF/MF/HF WSPR bands, which would require 3 Kiwis running in 8 channel mode.

While ADC + FPGA devices like the RedPitaya offer one path to a Kiwi successor, I prefer that we migrate all possible signal processing out of hardware and into open source software, even at the cost of a more expensive host PC. Your recent presentation in San Diego and your DCC paper form 2021 persuades me that your ka9q-radio service, when fed by a 16 bit (or higher) resolution ADC, could meet our multichannel needs while being easily integrated within WD's software architecture.

However there are a least three scientific requirements of our system which I don't know if a GPSDO-RX-888 + ka8q-radio frontend could meet:

1) Tuning frequency accuracy derived from the accuracy of the GPSDO. On the 10M WSPR band a GPSDO-Kiwi can tune with 0.001 Hz or better accuracy and IQ output slowly drifts at most +-180 degrees over a 10 minute measurement period.
2) The IQ wav files recorded by the kwirecorder utility include a start sample timestamp derived from the GPS clock with a (I think)1 microsecond or better time resolution. 3) A deterministic temporal delay between the RF sample time and the demodulated output samples. That delay need not be the same for each channel, but it needs to be known so it can be incorporated into the signal processing SW

I encourage Franco and Clint to correct, comment and expand on these requirements.

So before Franco and Clint invest development time in the RX888 and your ka6q-radio, it would help us if you can comment if that system could meet those requirements.

Very good questions.

Frequency accuracy should be as good as the reference oscillator driving the tuner downconverter and A/D converter clocks. The main problem here has been the fractional-N synthesizers in the 820T tuners in the various front ends I've used. For the AMSAT UK Funcube dongle and the Airspy R2 and HF+ I shadow the computation of the synthesizer registers so I can get the actual tuner frequency and use that to compute the second LO frequency (the one in software). Checks on a GPSDO reference show this works.

Timing accuracy is more of a problem. My front ends do not timestamp their samples, and the USB subsystem that gets them to the host computer is a black box to me. Because ka9q-radio uses fast convolution, it processes A/D samples in blocks (typically 20 ms) for the FFT. I'm not sure what effect this has on the determinancy (?) of the I/O delay. There's also the OS latency, though I now use the Linux real-time scheduling hooks. All this really needs to be tested experimentally. Maybe feed an attenuated 1pps signal to the antenna input and look for its harmonics at the receiver output.

Do you really need 1 microsecond output tagging? The actual resolution of the output will depend on the output sample rate and filter bandwidth. I know the KiwiSDR isn't that wide.

I spent a frustrating month trying to deterministically tune a GPSDO-driven RTL-SDR to the VHF/UHF WSPR bands. As you know better than I, the RTL_SDR driver's tuning instructions result in actual tuned frequencies which are approximations of the instructed frequency. Worse yet, there was no monotonic change in frequency tuning: instructing the RT driver to tune up 1 Hz might result is a jump of +-400 Hz in the measured tuned frequency. I hope the tuner and driver for the RX888 works better than those for the RTL, in which case the RX888 will add my long wished for support for VHF/UHF WSPR bands to Wsprdaemon and we can use the FST4W modes to study propagation on those bands.

My understanding is Kiwi's TDoA extension is built upon very accurate time stamps from the FPGA which are added to a private wav file header field. The 10 mile localtion accuracy of locations reported by the TDoA extension suggests those timestamps in a 12000 spa audio file can be used for time of flight measurements with accuracies which will be useful in our propagation studies.

I think I've solved your frequency accuracy problem for the RTL-SDR, Amsat UK Funcube dongle and the Airspy R2 and HF+. It helped that they all use the 820T (or similar) tuner. They are programmed differently, though, so I had to get the firmware for each and shadow the calculations. The program that controls the front end (airspyd, etc) multicasts the true front end center frequency over its status channel where 'radiod' picks them up and applies whatever corrections are needed to get the exact requested frequency in each channel.

I first ran into this while looking at WWV with the Funcube dongle and couldn't understand why one HF frequency would be high, another low. And by a lot! I had the same problem with digital TV pilot carriers. I'd seen people using them as poor-man's frequency references (this was before cheap GPSDOs) and began to question how accurate they really are. I discovered huge tuning errors (especially at the high ends) and was surprised that the other users of these SDRs didn't seem to care much. Maybe they're all doing wideband work (e.g., WiFi) where it doesn't matter. (End result: don't use digital TV pilot carriers as frequency references unless you carefully check them first. They can be off by 10s of Hz.)

As far as I can tell, with my tweaks the overall accuracy of these front ends with ka9q-radio is now as good as their frequency references.

On 4/24/23 16:18, rrobinett wrote:

I spent a frustrating month trying to deterministically tune a GPSDO-driven RTL-SDR to the VHF/UHF WSPR bands. As you know better than I, the RTL_SDR driver's tuning instructions result in actual tuned frequencies which are approximations of the instructed frequency. Worse yet, there was no monotonic change in frequency tuning: instructing the RT driver to tune up 1 Hz might result is a jump of +-400 Hz in the measured tuned frequency. I hope the tuner and driver for the RX888 works better than those for the RTL, in which case the RX888 will add my long wished for support for VHF/UHF WSPR bands to Wsprdaemon and we can use the FST4W modes to study propagation on those bands.

My understanding is Kiwi's TDoA extension is built upon very accurate time stamps from the FPGA which are added to a private wav file header field. The 10 mile localtion accuracy of locations reported by the TDoA extension suggests those timestamps in a 12000 spa audio file can be used for time of flight measurements with accuracies which will be useful in our propagation studies.

— Reply to this email directly, view it on GitHub https://github.com/ka9q/ka9q-radio/issues/38#issuecomment-1520943002, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJDI477HP4R2GC6P5DYHULXC4C4JANCNFSM6AAAAAAWWTVR5E. You are receiving this because you commented.Message ID: @.***>

Wsprdemon includes support for RTL-SDR inputs for VHF/UHF bands, and in testing that support I added a calibration function to WD which scanned for local ATSC pilot carriers and tried to use that information to tune to the WSPR bands. Because of the tuning problems with the RTL-SDR drivers I could find a couple of years ago when I was working on this, I could never use that calibration information to accurately tune to the WSPR bands. It is only recently that I learned from Glenn N6GN that in addition, the pilot carriers themselves are not transmitted at accurate frequencies, which you have also confirmed.

So it is very encouraging to learn that ka9q-radio fixes that RTL-SDR tuning problem and I hope that translates to accurate tuning of the RX888 MKII on the VHF/UHF bands. If so, then the RX888 and ka9q-radio will add even more new features to WD.

On Mon, Apr 24, 2023 at 5:53 PM Phil Karn @.***> wrote:

I think I've solved your frequency accuracy problem for the RTL-SDR, Amsat UK Funcube dongle and the Airspy R2 and HF+. It helped that they all use the 820T (or similar) tuner. They are programmed differently, though, so I had to get the firmware for each and shadow the calculations. The program that controls the front end (airspyd, etc) multicasts the true front end center frequency over its status channel where 'radiod' picks them up and applies whatever corrections are needed to get the exact requested frequency in each channel.

I first ran into this while looking at WWV with the Funcube dongle and couldn't understand why one HF frequency would be high, another low. And by a lot! I had the same problem with digital TV pilot carriers. I'd seen people using them as poor-man's frequency references (this was before cheap GPSDOs) and began to question how accurate they really are. I discovered huge tuning errors (especially at the high ends) and was surprised that the other users of these SDRs didn't seem to care much. Maybe they're all doing wideband work (e.g., WiFi) where it doesn't matter. (End result: don't use digital TV pilot carriers as frequency references unless you carefully check them first. They can be off by 10s of Hz.)

As far as I can tell, with my tweaks the overall accuracy of these front ends with ka9q-radio is now as good as their frequency references.

On 4/24/23 16:18, rrobinett wrote:

I spent a frustrating month trying to deterministically tune a GPSDO-driven RTL-SDR to the VHF/UHF WSPR bands. As you know better than I, the RTL_SDR driver's tuning instructions result in actual tuned frequencies which are approximations of the instructed frequency. Worse yet, there was no monotonic change in frequency tuning: instructing the RT driver to tune up 1 Hz might result is a jump of +-400 Hz in the measured tuned frequency. I hope the tuner and driver for the RX888 works better than those for the RTL, in which case the RX888 will add my long wished for support for VHF/UHF WSPR bands to Wsprdaemon and we can use the FST4W modes to study propagation on those bands.

My understanding is Kiwi's TDoA extension is built upon very accurate time stamps from the FPGA which are added to a private wav file header field. The 10 mile localtion accuracy of locations reported by the TDoA extension suggests those timestamps in a 12000 spa audio file can be used for time of flight measurements with accuracies which will be useful in our propagation studies.

— Reply to this email directly, view it on GitHub https://github.com/ka9q/ka9q-radio/issues/38#issuecomment-1520943002, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ADJDI477HP4R2GC6P5DYHULXC4C4JANCNFSM6AAAAAAWWTVR5E . You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ka9q/ka9q-radio/issues/38#issuecomment-1521012240, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIFAQZD7CO4A7SDQE3LOTR3XC4OBXANCNFSM6AAAAAAWWTVR5E . You are receiving this because you authored the thread.Message ID: @.***>

-- Rob Robinett AI6VN @.*** mobile: +1 650 218 8896

My observations here in San Diego are that ATSC pilot carriers are very stable, if not terribly accurate. If one is 4 Hz off, it'll stay 4 Hz off. Some (though by no means all) do seem to be controlled by a GPSDO or Rb/Cs standard but I'd still use them with care.

On 4/25/23 12:58, rrobinett wrote:

Wsprdemon includes support for RTL-SDR inputs for VHF/UHF bands, and in testing that support I added a calibration function to WD which scanned for local ATSC pilot carriers and tried to use that information to tune to the WSPR bands. Because of the tuning problems with the RTL-SDR drivers I could find a couple of years ago when I was working on this, I could never use that calibration information to accurately tune to the WSPR bands. It is only recently that I learned from Glenn N6GN that in addition, the pilot carriers themselves are not transmitted at accurate frequencies, which you have also confirmed.

So it is very encouraging to learn that ka9q-radio fixes that RTL-SDR tuning problem and I hope that translates to accurate tuning of the RX888 MKII on the VHF/UHF bands. If so, then the RX888 and ka9q-radio will add even more new features to WD. Message ID: @.***>

I'm closing this old thread.

ka9q / ka9q-radio

What is the frequency and time domain accuracy and resolution of a demodulated stream? #38