External clock frequency value report needed in /status page [added in v1.658]

Comments

• jks

  January 15

  Hi Rob,

  Sure, I will do that.

  clk_ext_gps=

  First value is 0 or 1 indicating if the external ADC clock has been selected (admin config tab, "External ADC clock?" yes/no setting.

  Second value is 0-5 indicating value of "GPS correction of ADC clock" menu selection also on that page.
• n6gn

  January 15 edited January 15

  Is there a chance of having an output on the status page that allows access to the present ext_clock frequency added to status?

  It seems that among ext_clock, frequency, GPS or not and versions it has become a bit complex. There has become a matrix of possibilities. If these could be known perhaps the precise correction factor might be used to arrive at an accurate value for the correction to be applied at baseband.

  As Rob has said, this is mostly an issue for special but very interesting capabilities and studies so probably doesn't matter to most users. A couple of hundred mHz (or something) of error probably won't cause most users to lose sleep but it might make the difference to some very interesting application(s).

  It would seem that the kiwiSDR knows all of this so perhaps a line for ext_clock frequency field could be accessed?

  Don't know how much I'm asking but wondering.
• jks

  January 15 edited January 15

  Is there a chance of having an output on the status page that allows access to the present ext_clock frequency added to status? 

  Isn't this what Rob just asked for? (I've already implemented it, so it will be in the next release)

  Maybe you mean the internal clock oscillator (ADC XO) when the external clock is not being supplied and the Kiwi GPS is correcting that internal clock?
• rrobinet

  January 15

  Thanks!

  FYI, we have verified that 'continuous' is the best setting for WSPR decoding
• n6gn

  January 15

  Yes, I wasn't sure that it was clear that we needed to know the ext clock frequency as well as its presence.

  Thanks John.
• jks

  January 15

  Okay. So the new /status value clk_ext_freq=... will just be whatever happens to be entered in that field on the admin config tab. clk_ext_gps=1,... will mean the external clock is actually active.
• n6gn

  January 16

  That will be great as far as I can tell. All we can ask for is what the user entered as the ext clock frequency. Hopefully the HW is adequately referenced and has provided what he entered.

  Thanks for doing that.
• jks

  January 23

  Okay, clk_ext_freq=... is in v1.658 just released.
• G3ZIL

  January 23

  Thank you, John, for this adding this useful metadata

  I've made a series of measurements as set out in the Table below with the Notes below the Table outlining the setup.

  1. The two rows in green are for the external clock frequencies for the old and new decimation factors multiplied by the baseband sampling rate. The good news is that the frequency errors at baseband are not different from zero given my measurement capability.
  2. However, when I apply what I thought I knew about calculating the baseband frequency error from the ratio of the external clock frequency to the (decimation x sampling rate) frequency my measurements - those in the 'Correct error' columns - not not match my calculations in the rightmost two columns.
  3. I did the 66.660000 MHz measurements first, then repeated as I could not understand the difference.
  4. I then tried the other frequencies, and was completely surprised that the results essentially showed no baseband error.

  What have I misunderstood? Now that we have the clock frequency metadata we need to know how to use it to apply baseband correction.

  Gwyn G3ZIL

  
• jks

  January 23

  Well, I don't know.

  What's the difference between your "raw" and "corrected" numbers? And how exactly are you computing the expected error values?
• G3ZIL

  January 23

  1. Difference between raw and corrected number is that the -0.013 Hz OCXO error at 10 MHz has been corrected for.
  2. Expected error from:

  

  all frequencies in Hz

  Gwyn
• jks

  January 23

  Okay, thanks.

  I'll look at this more when I have some time. Today is the deadline for having the final Kiwi-2 sd card image finished. And I'm not quite ready. So huge stress..
• G3ZIL

  February 14

  John

  I appreciate you have had many matters to attend to.

  Any insights into these measurements would be helpful ahead of the HamSci Workshop in March.

  thanks

  Gwyn G3ZIL
• jks

  February 19

  Just getting back to this. I am still really confused.

  The expression ext_clock_freq/(decimation_factor*sample_rate) is always one. Hence subtracting one from it is always zero. You can't use a rounded sample rate value such as 23995.68 in the calculation.

  So your 10 MHz OCXO is 0.013 Hz low. Then you should always see that error when receiving at 10 MHz no matter what the ADC clock input value is. Decimation and sample rate have no effect on that. If you're feeding the Kiwi 66.66 or 66.72 or 66.6666 MHz, and you give that value to the admin interface, then the received result should always be exactly 10 MHz + 0.013 Hz.

  This is why the Kiwi GPS-based clock correction works. It doesn't care what frequency the ADC XO on the board is running at. It uses the GPS to accurately measure the true XO frequency. Fixed offset, temperature drift, aging, everything. And then adds a correction factor to whatever the "10 MHz" tuning value is being sent to the RF mixers of the DDC. So you're always getting a received signal tuned to exactly 10 MHz.

  Now the tradeoff is that the current, precise audio output sample rate is going to be random and changing. 12 kHz +/- whatever. Because the decimation factor is fixed. For just listening you don't care about sample rate because you can't hear the small difference.

  But if your ADC clock is fixed and accurate then the sample rate will be too. Still possibly fractional, unless the division by the decimation factor puts it exactly on 12 kHz. But accurate.

  For cases where the precise sample rate does matter (when using the internal GPS-adjusted clock) it can be queried from the API. So for the internal extensions like FAX and SSTV you get results that aren't slanted (unless they were sent that way or unless there were dropouts in the audio sampling).

  So if you're using an external clock of 66.66 with Kiwi-1 where the decimation is 5555 or 66.672 with Kiwi-2 where the decimation is 2778*2=5556 then you should see no errors at all, ever. Assuming your external clock is good.