External clock frequency compensation not fully applied
Following the update in v1.557 that fixed the GPS frequency aiding problem when only using kiwirecorder.py we have been able to document what looks like incomplete compensation for the user-set frequency for an external clock in the Config panel.
Entering the external clock value in the box does set the correct RF frequency, i.e. using IQ display at 10.000000 MHz there is only jitter receiving a 10 MHz external standard. This happens correctly even if, say, the external clock and entry in Config screen is at 66.600000 MHz.
However, but there appears to be a second, baseband clock correction that does not get done. Why baseband? Because the offset we see is constant irrespective of RF frequency. It appears as if baseband processing assumes the clock frequency is 66.666600 MHz irrespective of what's in the Config box. With 66.600000 MHz input frequency and Config example, the external clock is 0.1 percent lower than 66.666600 MHz, that is, 1.5 Hz in 1500 Hz. 1.5 Hz is the offset that we see at 1500 Hz baseband frequency, i.e. dial frequency of 9998.5 kHz and USB mode for a 10 MHz input.
Setting the external clock to 66.666600 gives a match to within 0.1 Hz of expected.
regards
Gwyn G3ZIL
Comments
Yeah I think I see what's wrong. More old code that should have been removed. Does the wrong thing for the case of external ADC clock selected and Kiwi GPS clock correction disabled.
Fix in the next release (maybe later today).
John
Thanks for trying to fix, unfortunately it has not rectified the problem.
I have updated to v1.558
Config: v1.558, 8 SDR channels, 12 GPS channels | Uptime: 0:11:13 | UTC: 14:56 | Local: 15:56 Europe/London (BST)
These are the mean frequencies for 54 near-field WSPR-2 transmissions:
mean b'band frequency (Hz) 1408.848 with Bodnar set to 66.600000
mean b'band frequency (Hz) 1407.433 standard aiding Kiwi 4919
mean b'band frequency (Hz) 1407.426 standard aiding Kiwi 3734
There is still a 1.4 Hz difference.
It is the same whether I GPS Corrections of ADC Clock to disabled or continuous.
regards
Gwyn G3ZIL
I guess I don't understand the issue then. Let me try and read your message again.
I presume you're using 66.6 MHz from the Bodnar because its frac-N synth produces a cleaner output at that frequency than something stranger like 66.666600 that the Kiwi XO uses?
Yes, the is exactly the reason, seeking as clean a clock signal as possible to minimize specctral spreading for use with FST4W reception.
I assume Rob is still using kiwirecorder in wsprdaemon. Is he using the
--resampleoption to convert the sample rate of the Kiwi audio output to exactly 12 kHz (or perhaps 375 Hz) for WSJT-X?And if so, does wsprdaemon enforce the installation of libsamplerate for Python so kiwirecorder produces high-quality resampling? (if this isn't done then kiwirecorder falls back to using the python built-in low quality linear interpolator for resampling which you don't want).
Without the sample rate of the audio files being exactly (12k/375) you're going to see the offsets you describe (i.e. you won't get the precise 1500 Hz BFO value WSJT is expecting).
The Kiwi audio DDC decimation is fixed at 5555 (505*11) for 4 and 8 channel modes. So for a "nominal" ADC XO, 66666600 MHz / 5555 = 12001.181(bar) Hz. This is high from 12 kHz by about 0.01% (100 ppm). At 1500 Hz 100 ppm is 0.15 Hz. About the 0.1 Hz you see. With a 66600000 ADC clock / 5555 = 11989.1989(bar) or about 0.09% (900 ppm) low. At 1500 Hz 900 ppm is 1.35 Hz. About the 1.4 Hz you're seeing.
So I think the audio sample rate issue explains what you're experiencing. This should have been true prior to the v1.557 changes for the case when browser connections were active.
66.66 would give 12 kHz exactly. Which brings up an interesting question: How clean is the Bodnar using a 66.66 MHz output vs the 66.6 you're using now? You could avoid the resampling issue this way.
A careful assessment of the spectral purity from the Bodnar mini and original GPSDOs while tuning in the 66.66 MHz region would require quite a lot of effort. High resolution frequency generally means larger integers and the risk of boundary spurs but in actuality, compred to typical signal SNRs I suspect there will little notieceable difference between 66, 66.6, 66.66 and even 66.666 MHz settings . Close-in spurious at offsets that matter for FST4W decodes probably are taken care of pretty well by the [15 Hz] PLL bandwidth, microwave dividers reducing them and the uBlox GPS rx that provides the reference.
I originally suggested 66.6 MHz to possibly improve purity, per Silicon Labs original recommendations, but traded against the frequency error when deviating from 66.66 MHz I'd go with the latter if that brings the error to zero. I doubt anyone is going to notice any spectral purity improvement and having .1 Hz Kiwi accuracy becomes really interesting as we start to use it to examine what the HF ionosphere is doing - a subect of recent interest. I'd much rather have that ability than better spectral purity, if it's even an issue.
Already the "shaking" of the path length and associated Doppler shift that we are able to measure with FST4W and KiwiSDRs during the recent/present storming is fascinating and perhaps not yet well explored to the degree that amateurs may be able to provide.
I'd suggest that a 66.66 MHz setting of Bodnar or other GPSDO and a matching Kiwi external clock entry is likely a good work-around.
I will leave it to Rob to comment on the use of kiwirecorder.py in wsprdaemon.
I do think you have found the source of the problem, the fixed DDC decimation at 5555 (505*11).
Thank you, John, for the calculation to suggest 66.66 MHz, and thank you, Glenn, for stressing that these seemingly small changes can lead to even more fascinating studies with the KiwiSDR and that 66.66 MHz should be fine. I'll repeat the tests this morning and report back.
Gwyn
A short test spanning 19 local WSPR spots shows that 66.66 MHz does indeed provide the absolute baseband frequency accuracy that is valuable to us. The differences between the Bodnar KiwiSDR at 66.66 MHz and two KiwiSDRs with their own GPS aiding was 0.13 Hz and 0.03 Hz.
This resolves the issue for us. Thank you.
Gwyn
Jim WA2ZKD just pointed me to this discussion.
I was not aware of --resample and will add it and install libresample in the next WD build
Christoph added
--resamplerelatively recently I believe. I'm not completely sure how good it is for this application (very small sample rate changes). So be sure to do some characterizations.But it seems now there are several potential methods to solve this issue. Does anyone have access to a decent phase noise test set to characterize the Bodnar synth?
I have used kiwirecorder --resample successfully to grab wav files for standalone wprd testing.
an example...
2022-09-09 07:56:54,191 pid 26783 resampling from 12001.1 to 12000 Hz (ratio=0.999904)