Clock drift in WSPR mode

Comments

• jks

  November 2017

  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

  November 2017

  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

  November 2017

  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

  November 2017 edited November 2017

  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

  November 2017

  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

  November 2017

  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

  November 2017

  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

  November 2017

  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

  November 2017

  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

  November 2017

  Quite possibly..

  
  
• jks

  November 2017

  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

  November 2017 edited November 2017

  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

  November 2017

  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

  November 2017 edited November 2017

  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

  November 2017

  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

  November 2017

  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

  November 2017

  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

  January 2018

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