Finally I decided to build a proper case for my SDR-WSPR installation in my garage, receiving WSPR messages as DL2ZZ. This occasion I took as an opportunity to automatically measure the PPM deviation of the 125 MHz oscillator, so I can correct for it.
As the temperature changes in my garage quite a lot, I had to change the PPM value of the receiver regularly, which I find annoying. One cheap and simple way to automatically measure the deviation of the clock is to use a reciprocal counter bitstream in the RedPitaya FPGA and measure an external reference clock. As it happens Anton Potočnik happens to have developed such a bitstream. Lucky me!
A reciprocal counter compares the number of signal cycles with cycle of a reference in a given amount of time. An ideal, affordable reference signal can be generated by a GPS/GNSS discipline oscillator (GPSDO); an RF clock i.e. 10 MHz is phase-locked to the GPS/GNSS clocks. That way one can get a 10 MHz reference signal with an Allan deviation of less than 10^-9 (Ref. RA3APW) for ~10 EUR. In other words, we can measure a 28 MHz signal with +-0.001 ppm or +-0.028 Hz trueness, assuming we count enough cycles. This should be enough for WSPR.
The first idea I had, was to measure the frequency deviation as a function of temperature, and create a lookup table that can be used later during receiver operation. The assumption is that the internal temperature sensor of the FPGA has the same temperature (or an offset, at least predictable) as the 125 MHz oscillator. This is also roughly correct and one can correct to probably +-2 ppm, but there is a delay from temperature changes in the FPGA to the oscillator, as the heat is conducted through the heatsink mounted on top of FPGA/CPU and the oscillator:
This makes it difficult to measure temperature dependence, as one has to wait quite a while ~100 s between each data point. I do not have thermal chamber, so I did rely on the natural warming up process after a cold-start. Unfortunately the temperature rises too fast, so the measurement has a conceptional problem here. Also it has to take place in exactly the same boxing, keeping the thermal environment equal (draft etc.). The graph below describes my finding quite well. The function has hysteresis, different measurements do not sufficiently overlap etc. limiting the precision for the look-up table concept.
Another option is to perform the frequency deviation measurement during the break between the WSPR messages between 1:52 min and the next transmission, starting at the even minute. The idea is, that during the SDR-WSPR 24h/7d operation, I have a rather stable thermal environment inside a closed box (see photo below) during lets say 5 min. That means there is enough time to get a stable thermal equilibrium between the temperature sensor inside the FPGA and the 125 MHz oscillator.
The 10 MHz reference is connected to AIN1 and the antenna to AIN2 of the RedPitaya. At 1:53 min the reciprocal counter bitstream is loaded and the ppm deviation is measured and stored with the current temperature. Afterward the SDR-WSPR bitstream is loaded again and at the even minute the reception of a message with the new ppm correction can start.
I am not sure how well this ‘slow’ temperature dependence measurement can be used to create a better look-up table for ppm correction, so far. An update of this post with my findings will follow as soon as I have acquired enough statistics.
I recorded the frequency deviation vs. temperature over several day in my garage and the effort of using a proper enclosure paid out:
As WSPR covers a 200 Hz wide band, but SDR-WSPR monitors 300 Hz, a drift of 50 Hz is still tolerable. The reproduce-ability might be sufficient for 28 MHz WSPR, < 1.7 ppm = +- 50 Hz.
73 de Clemens / DL2ZZ / PA7T