ADC Clock Frequency Correction via GPS Timing

Comments

• jks

  June 2017 edited June 2017

  The ADC clock counting occurs before the DDS and is unaffected by any tuning compensation. You're correct, the "slightly off" sample rate derived from the division of the ADC clock is not corrected. But it doesn't matter. You just want to fix the downstream effects of the sample rate being slightly off. Namely getting the waterfall to look "on frequency" and the audio to produce the exactly correct tones. If you can determine what the exact, slightly off, constantly changing sample rate is using the GPS then this should be similar to having used a very expensive TCXO/VCTCXO with no GPS involved at all. Fixing the tuning completely compensates for the sample rate being off.

  
  

  The 48-bit counter in the FPGA, clocked by the ADC clock and sampled by the GPS, is very similar to a traditional frequency counter. If the gate time of the counter is known to be accurate then the ratio of the counter to the gate time gives you the frequency: ADC_clk (Hz) = ADC_count / GPS_gate_time, where Hz is "counts" per second and GPS_gate_time is the difference between two GPS time samples measured in seconds. Another way:

  
  

  ADC_clk (counts)   ADC_count (counts)             1

  ---------------- = ------------------- X -------------------

          (sec)                            GPS_gate_time (sec)

  
  

  The software GPS in the Kiwi doesn't even have a 1 PPS. It produces a new GPS position/time solution every 4 seconds or so and GPS_time is simply the difference between two successive solutions. Since both solutions are accurate to roughly a microsecond the "gate time" is accurately known. There is one more thing required. In the FPGA the ADC clock counter is sampled simultaneously when the GPS hardware that determines a solution is sampled. So the sampling is synchronized.

  
  

  
• MikeR

  June 2017

  Hi John,

  Thanks for the rapid reply which adds a significant detail - the presence of a GPS solution signal in the FPGA.  I wonder if a combination of the GPS solution signal, the FPGA's PLLs and some logic could produce a desired ADC clock frequency.  Merely a thought experiment at the moment.  What's the path name to that signal in the verilog design?

  Cheers,

  Mike.

  
  
• jks

  June 2017

  The 66.7 MHz XO input to the FPGA in on verilog/kiwi.v:ADC_CLKIN. That get's buffered by an IBUFG and distributed around the FPGA as adc_clk. Similarly for the 16 MHz GPS clock, GPS_TCXO -> IBUFG -> gps_clk. I actually experimented with the FPGA clock generators in an early prototype. Most designers would cringe at the idea of using an FPGA-derived clock as an ADC clock. But modern FPGAs seem to go to a great deal of trouble to produce clean clocks under some circumstances. I could never characterize running the ADC clocked this way because I didn't have the necessary test equipment at the time. And I had to move on to other things. So I took the safe approach and used an external XO with known performance.

  
  

  But yeah, using an FPGA clock PLL tuned by the GPS so the ADC sample rate is dead-on would be a fun experiment. You'd only have to add one wire to try this. The board already has an external ADC clock input that can be chosen, instead of the XO, by a control signal from the FPGA. You just have to add a wire from one of the FPGA GPIO outputs that appears on a board trace to this external input. See J5 on the schematics: http://kiwisdr.com/docs/KiwiSDR/kiwi.schematic.pdf

  
  
• MikeR

  June 2017

  Hi John,

  Thanks for that.  I'd figured out the one wire solution.  We're on the same page.  The FPGA signal I was hoping you'd identify is the signal you mentioned earlier which indicates a GPS solution.

  
  

  By the way, hope you're celebrating the Kiwi America's Cup victory.  Fantastic.  Who'd have thought sailing could be more fun to watch than F1!

  Cheers,

  Mike.
• WA2ZKD

  June 2017

  F1 has become awful to watch. I saw the USGP live at WGI in the 60's so prefer those days!

  
  
• jks

  June 2017 edited June 2017

  Well, there is no signal in the FPGA which indicates a solution really. Just like there's no PPS or GPS-locked clock. If the GPS software running on the Beagle decides it has at least 4 "good" sats then every 4 seconds or so it asks the hardware to take a "snapshot" of its internal state for all the sats simultaneously. This state includes all the things necessary to calculate the "time of transmission" of each satellite (code phase, code position, navigation bits decoding position etc.) Combined with information decoded from the navigation message (GPS "time of week") this gives an uncorrected sat clock time. And from there computing the iterative navigation solution fine-tunes the resulting time solution.

  
  

  The "GPS_gate_time" I mentioned earlier is not an FPGA signal but just a software variable in the Beagle code. It's the difference of the last two successful GPS time solutions whatever that happens to be. It's around 4 seconds but varies a lot due to when the measurements were initiated from the Beagle. But the exact period of the gate time doesn't matter since the corresponding ADC counter is capturing however many ADC clock cycles occur during the particular gate time.

  
  

  Now if you need to create a known, periodic signal locked to the GPS (1 PPS, 10 kHz, whatever) to discipline another PLL with that's going to take a little more work. You've got these nice carrier and code NCOs locked to the sat on each GPS channel. But each of those is not constant. The NCO values are being updated as the sats are tracked. The worst effect is going to be the doppler shift. So I think you have to consider all of them and take the navigation solution into account in order to derive a constant, GPS-locked clock. Maybe someone here knows how this is done.

  
  
• MikeR

  June 2017

  Thanks John.

  
  

  By the way, what is the exact nominal frequency of the external oscillator?  Is it exactly 66.6666MHz as shown on the schematic?  If it were 66.6600MHz then decimation would produce _exactly_ 12kHz.

  Cheers,

  Mike.

  
  
• G8JNJ

  June 2017 edited June 2017

  Hi,

  
  

  I assume part of this query and previous similar discussions also relate to the slope observed on Fax images.
  

  
  

  Has the original division ratio had to be changed as a result of recently increasing the ADC sample rate from 9,6K to 12 K ?  as this could possibly account for the differences in TCXO frequencies.

  
  

  My 66.6667MHz TCXO measures as 66.66616MHz and the 16.384MHz TCXO as 16.38398MHz

  
  

  Regards,

  
  

  Martin - G8JNJ
• G8JNJ

  June 2017

  Oops sorry, I meant Audio sample rate not ADC sample rate.

  
  

  Regards,

  
  

  Martin - G8JNJ
• MikeR

  June 2017

  Hi all,

  Why is the oscillator (ADC sample) frequency 66.6667MHz?  All the evidence appears to point to 66.6600MHz being what the system needs.  This would allow decimation down to _exactly_ 8.25kHz or 12kHz.  It seems this should remedy the fax "slope" problem.

  
  

  I'm guessing the answer might be cost.  If so then a PLL solution in the FPGA may be an alternative, although that requires a board mod too (as discussed earlier in this thread).

  73s,
  

  Mike.

  
  

  
  
• jks

  June 2017

  The ADC XO is 66.666600 MHz +/- 50 ppm because that is a standard value available inexpensively in quantity. The DDC decimation is currently 5555 giving an audio sample rate of 12001.188 kHz. Previously is had been 6944 giving 9600.605 kHz.

  
  

  I haven't looked into the FAX skew problem in detail yet. I'm supposedly using the corrected audio sample rate to do the alignment but it may be incorrect. All FAX programs require some per-station fine-tuning, manually and/or via measuring the phasing signal period (or locking to the sync pulses if possible). All of that is disabled in the code at present. I hope to be able to get back to the FAX extension soon. I'm being pulled in about 12 different directions at the moment.

  
  
• KQ6XA

  August 2017

  What is the expected GPS-corrected accuracy in +/- Hertz when tuned to 10 MHz?