Clock drift in WSPR mode

rrobinet

After running two WSPR sessions overnight I noticed that most of the rx transmissions are now below the '0 to 200 hz' waterfall window.  Looking at the one spot I saw this afternoon, I can see that I record it at 150 Hz below all of the other spotters.  GPS tracking appears to be suspended with only one wspr session and three empty ones and the Kiwi's clock has drifted up 150 hz.  

If this 'no GPS tracking while running wspr' is an inherent limitation, the utility of the wspr extension is severely  limited.  In all other respects I prefer this WSPR to that built into the WSJT-x SW.

 2017-11-20 22:22 KJ6WSM 14.097196 -22 0 CM98hs 2 NU3E FN20pb 3965 73 

 2017-11-20 22:22 KJ6WSM 14.097174 -15 0 CM98hs 2 W7REK DM42lk 1169 124 

 2017-11-20 22:22 KJ6WSM 14.097191 -30 0 CM98hs 2 TI5LUA EK70sh 4837 121 

 2017-11-20 22:22 KJ6WSM 14.097181 -2 0 CM98hs 2 KE7A EM12kx 2270 99 

 2017-11-20 22:22 KJ6WSM 14.097035 -22 0 CM98hs 2 AI6VN BL10rx 3890 250 

 2017-11-20 22:22 KJ6WSM 14.097188 +9 0 CM98hs 2 VE6JY DO33or 1786 19 

 2017-11-20 22:22 KJ6WSM 14.097181 -13 0 CM98hs 2 W3BCW FM19ka 3791 75 

 2017-11-20 22:22 KJ6WSM 14.097185 0 0 CM98hs 2 KA4PKB EN41kf 2578 74 

 2017-11-20 22:22 KJ6WSM 14.097190 -25 0 CM98hs 2 CF3ROM EN58 2791 57

jks

What's the ambient temperature situation like where the Kiwi is? Also, can you tune to 15 MHz WWV/H and see how far off the carrier is? Going through the manual cal procedure will help as it will tell you how far off the ADC clock is in ppm which can be translated to Hz at the WSPR operating frequency. The frequency cal being off by 200 Hz at 14 MHz is 14 ppm. That seems high for what should be mostly be temperature drift after the initial GPS correction performed at server start.

jks

It's not GPS tracking that gets suspended, only acquisition that involves the expensive (realtime-wise) FFT. So you'll continue to get GPS solutions, just no new sats as the ones being tracked slowly drift out-of-range. It's possible that some hybrid solution could be used where acquisition is enabled occasionally to "top-up" the number of tracked sats.

The problem with running acquisition is that it causes realtime response problems, especially with 3 or 4 simultaneously connections. There's only so much the Beagle can do..

rrobinet

The Kiwi is i a weatherproof box outdoors in Maui where the temperature varies from 70 at night to 80 in the day.

I looked at WWVH and it is shown within a few hz of 15, so you are right that the Kiwi's clock is not the problem. 
I'll need more time than I have this afternoon to look into this more deeply.

You can access the Kiwi yourself at:  http://kiwisdr.robinett.us:8073/

jks

I looked at the code that determines when the acquisition process runs and it's a little different than I remembered (gps/search.cpp:SearchTaskRun()) It will actually start acquiring whenever there are fewer than 4 "good" sats, the minimum needed to generate a position/time solution. It does this independent of the number of active connections. So in theory you won't have the problem of clock correction stopping because all the tracked sats have orbited out of view (but see below).

The problem I noticed is that the acquisition process is slowed way down by the task scheduling when there is more than one active user connection. The acquisition FFTs have to be scheduled to run at just the right time so as not to disrupt the audio tasks which are very realtime sensitive. When there is more than one connection there are much fewer opportunities to do this scheduling, so the acquisition process effectively stops. This situation would be very much improved if the waterfall tasks could be stopped or slowed down. That is an option people have asked about for a long time. So maybe it is finally time to do something about that..

rrobinet

I am now mystified about how the WSPR extension drifted off frequency since the Kiwi's spots for the last 24 hours seem to be quite accurate.  I will experiment with 1..2..3 active WSPR sessions to see if that affects the frequency accuracy.

In addition to optionally suppressing the waterfall, could you also optionally send uncompressed audio?  Compression works poorly on noisy signals and delivering a (3,000 hertz audio * 2  times over sample * 8 bits per sample ==) 48 Kbps audio instead of the waterfall would address one of the few criticisms of the Kiwi I have found online. 

jks

Yes, that's a good idea. There's actually already code to disable the compression. It's just not hooked up to a button.

rrobinet

Until this morning the Kiwi was spotting my friend Glenn Elmoire N6GN within 1 Hz of his tx frequency 14.097100 (his beacon is derived from a Rubidium standard) until 19:06, about the time I started two more WSPR sessions on the Kiwi  and a friend in Graton, CA started a fourth session.  It is now spotting about 15 hz too high.  Do you have explanation for this subtle, but for our WSPR group significant error?

 2017-11-23 22:12 N6GN 14.097115 -8 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 21:50 N6GN 14.097116 -12 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 21:42 N6GN 14.097116 -10 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 21:32 N6GN 14.097115 -7 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 21:10 N6GN 14.097115 -12 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 20:50 N6GN 14.097116 -6 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 20:30 N6GN 14.097116 -13 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 20:18 N6GN 14.097115 -9 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 20:10 N6GN 14.097116 -7 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 19:56 N6GN 14.097116 -8 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 19:48 N6GN 14.097116 -8 1 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 19:26 N6GN 14.097116 -8 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 19:16 N6GN 14.097116 -3 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 19:06 N6GN 14.097116 -12 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 18:58 N6GN 14.097100 -3 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 18:48 N6GN 14.097100 -2 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 15:34 N6GN 14.097101 -22 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 08:20 N6GN 14.097100 -25 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 08:08 N6GN 14.097100 -23 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 07:56 N6GN 14.097100 -24 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 07:48 N6GN 14.097099 -23 1 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 07:40 N6GN 14.097100 -22 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 07:30 N6GN 14.097099 -23 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 07:20 N6GN 14.097099 -23 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 07:10 N6GN 14.097100 -25 2 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 07:02 N6GN 14.097099 -27 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 06:52 N6GN 14.097100 -24 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 06:34 N6GN 14.097100 -27 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 01:56 N6GN 14.097100 -7 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 01:44 N6GN 14.097099 -10 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 01:36 N6GN 14.097100 -13 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 01:24 N6GN 14.097100 -11 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 01:12 N6GN 14.097100 -11 -1 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 01:02 N6GN 14.097100 -7 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-23 00:54 N6GN 14.097099 -5 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-22 22:44 N6GN 14.097100 -13 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-22 22:36 N6GN 14.097100 -13 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

 2017-11-22 22:24 N6GN 14.097100 -14 0 CM88ok 5 AI6VN/KH6 BL10rx 3762 249 

jks

I looked at the wspr.net database to see what frequencies other stations reported at 2017-11-23 18:58 and 19:06 for N6GN. They didn't change, so we know it isn't a frequency shift by the transmitter (and I wouldn't expect one given his clock source).

It's impossible to say what might be happening without more logged data (GPS clock corrections, etc.) The only real clue is what you said about having made more connections running the WSPR extension. That's going to put much more realtime stress on the Beagle. It's possible this is causing some issue with decoder. But it's difficult to imagine how this would result in a frequency error. I just use the K9AN decoder code pretty much as-is.

rrobinet

In another context, Glenn mentioned he had seen clock errors due to rounding errors in 32 math which were corrected by the use of 64 integer calculations. Of course I don't know it that has any relevance to the Kiwi.

jks

Quite possibly..

jks

I have a strategy I'd like to try to debug this. But it's going to be some time before I can get to it (moving QTH this week, holidays, EOY financials, 18 other things in development, mailbox full, ...)

rrobinet

Thanks for your interest.

I think you can rely on N6GN's beacon to always be within 10^-5 Hz of 14.097100.

If you can't spot him from NZ, you are welcome to experiment on the Kiwi you gave me.

rrobinet

I've just returned from an overnight trip and see that my 20M spots are about 160 Hz too low, so much so that I no longer see the 20M WSPR band.  I don't want to fight the Kiwi, so I'll just leave it as it is and see if it autocorrects itself.  You are welcome to experiment with the Kiwi if you wish.  It might be useful to ask the Kiwi community if anyone else is experiencing this problem. 

 2017-11-24 23:20 N6VYM 14.097148 -18 -2 DM04 0.2 W7SZ CN85uo 1267 348 

 2017-11-24 23:20 N6VYM 14.097147 -18 -4 DM04 0.2 K9AN EN50wc 2791 68 

 2017-11-24 23:10 N6VYM 14.097155 -22 -3 DM04 0.2 KB9AMG EN52tx 2804 61 

 2017-11-24 23:10 N6VYM 14.097164 -13 -3 DM04 0.2 W7OWO CN85lh 1252 345 

 2017-11-24 23:10 N6VYM 14.097179 -27 -2 DM04 0.2 K7GDS CN85 1269 346 

 2017-11-24 23:10 N6VYM 14.097156 -22 -2 DM04 0.2 W7SZ CN85uo 1267 348 

 2017-11-24 23:10 N6VYM 14.096994 -24 -3 DM04 0.2 AI6VN/KH6 BL10rx 3956 258 

 2017-11-24 23:10 N6VYM 14.097156 -23 -3 DM04 0.2 K9AN EN50wc 2791 68 

 2017-11-24 23:00 N6VYM 14.097150 -20 -2 DM04 0.2 K9AN EN50wc 2791 68 

 2017-11-24 22:50 N6VYM 14.097159 -10 -4 DM04 0.2 W7OWO CN85lh 1252 345 

 2017-11-24 22:50 N6VYM 14.097174 -25 -4 DM04 0.2 K7GDS CN85 1269

jks

When I connect to your Kiwi, and look at the status panel at lower left, it shows a passband center frequency of 14097.26 for your 20m WSPR connection. Why is that? It's supposed to be 14097.10 Did you bump the "dial"? The WSPRs on 30m (10140.20) and 40m (7040.10) were fine. This is exactly the 160 Hz error you see in the wsprnet.org database.

Note that for the WSPR extension the freq shown in the status panel, admin page, etc. is the PB center instead of the carrier freq (dial freq) The dial freq for WSPR should be 14096.35 (750 Hz lower than 14097.10) unless you've changed the WSPR offset value on the admin page. You will see the dial freq in the frequency entry box when the WSPR extension is closed. I can't remember exactly why I did this, but my guess is that I thought it made sense to show the more familiar PB center freq for WSPR that everyone is used to.

WWVH @ 15 MHz was only off 8 Hz. There were no recent GPS solutions because all the sats had drifted out of range and the acquisition process was getting locked out by the three running WSPRs.

KA7U

I'm testing tonight. I have the 4 slices set for an overnight run. working 40 meters and down. Check the running report here:

http://wsprnet.org/olddb?mode=html&band=all&limit=300&findcall=&findreporter=KA7U&sort=date

That should work it. The room temperature here is 72 deg. F. The KiwiSDR is on a wood desk, with no fan. 

See the attached image for the current satellite spread.

Ron - KA7U

Attachments:
https://forum.kiwisdr.com/uploads/Uploader/35/a99d0894910c0f9ee08b0bc40a1d86.png

rrobinet

Yes, I can see that my tuning was off, but I didn't intentionally change it.  

My theory is that in clicking on the Kiwi window I selected it in waterfall region to bring it to the front and also  changed the tuning frequency of that WSPR session.

That error condition seems pretty subtle and I wonder if it could be avoided if the WSPR extension reprogrammed the tuning frequency before each 2 minute capture rather than only at start time.

KA7U

After a night of 4 slices receiving WSPR the satellites rotated off the grid, so to speak, but the frequency remained true according to the magnified spectrum display on WWV @ 10.0MHz. It has been a pleasure to test with you rrobinet.

It would seem that the KiwiSDR remained quite frequency accurate throughout this test. I'd leave it testing but others have written complaining about the receiver not being available.

As an aside, it would not be logical to have the WSPR mode correct manual adjustments every so often. A manual adjustment should override a preset, in my opinion.

73,

Ron Morell

KA7U

Attachments:
https://forum.kiwisdr.com/uploads/Uploader/d4/737fbf2be4442ec1f802159171548b.png
https://forum.kiwisdr.com/uploads/Uploader/7d/331bd872756a98b8912e4d9de5220d.png

rrobinet

Thanks for investing time in what turned out to be an operating error