[Time Nuts!!] Help Understanding and Improving on GPS 'assisted' VFO? - Page 1
Forum section: electronics / beginners

author: rwgast_lowlevellogicdesin
author_rank: Frequent Contributor
timestamp: September 09, 2017, 01:43:48 am
content: Ok so I am working on building my own version ofthis project (a GPS 1PPS assited VFO using si5351)myself. I'm not using the project as is mostly because I want to learn and also I hope some of my ideas may improve on VFO. Most of the article is pretty basic and the only part that really matters to me is the part about "disciplining the si5351 outputs"QuoteSo im hoping someone can clear up a few things for me. So were counting 40 GPS pulses (this should equal 100mhz), Im guessing that 40 seconds was chosen to produce easy to work with numbers? Then were using the arduino counts over a 40 seconds to calibrate the si5351 clock? Well the arduino is using a 20ppm crystal, so how is that accurate?My Si5351 board has a 2.5ppm TCXO's on board and I'm looking to make it more accurate with parts I have on hand (e.g im not going to use a timing GPS and an OCXO etc etc, i want to make do with mostly what I have). So what is one were to use a 16mhz TCXO on the arduino, i don't understand how this project gets the accuracy it does using a 20ppm xtal on the chip that is doing the counting. Next what if instead of updating every 40s, we put a divide by 4 on the 1pps and then did the si5351's 25mhz clock calibration every 250ms?Ive been trying to dig through the code of the original project but im having a hard time dissecting it all, so for now im doing more research on the si5351 itself till things make more sense, but I feel like i am misunderstanding something maybe. I mean if the crystal is 20parts per million and a 100mhz is 100 million parts, doesn't that mean the arduino count can be up to 2000 counts off?

author: jpb
author_rank: Super Contributor
timestamp: September 09, 2017, 01:23:41 pm
content: Quote from: rwgast_lowlevellogicdesin on September 09, 2017, 01:43:48 amYour link didn't work for me but I think I found the right article by DuckDuckGoing (alternative to Google:)).I only skim read it but the impression I got is that the Arduino is only counting so its own clock accuracy doesn't matter - all that matters are the accurate (to plus or minus a few 10s of nanosecs) 40 seconds from the GPS 1PPS and the number of si5351 cycles it counts in that period so the Arduino's clock shouldn't come into it. I would guess 40 seconds was chosen as the GPS 1PPS jitter is of the order of a few 10s of nanosecs but this would be reduced by a factor of 40 giving close to nanosec accuracy for frequency measurement.There will be an uncertainty of 1 or 2 cycles which worse case is 1000 nsecs for the 1MHz output but this is measured over 40 seconds so should be reduced to more like 25 nanosecs to which a nanosecond or so for the GPS needs to be added. The whole thing would then be accurate to something under 50 nanosecs or 1/20 of a Hz at 1MHz which gives the claimed accuracy of less than 1 part in 10^7.At the high frequency end the 1 cycle will only be at 100MHz 10 nanosecs with the GPS jitter adding say 30 or so nanosecs so the total would be around 50 nanosecs over 40 seconds comming down to around 1 nanosec which is again around 1/10 of a Hz but would be much less than 1 part in 10^7EDIT:Looking at your quote, the frequency being measured is always 2.5MHz (presumably other frequencies are generated by the chips PLL) so the accuracy over 40 seconds is say 400 nanosecs (1 cycle, perhaps 800 nanosecs would be more accurate given uncertainty both ends) plus say 50 nanosecs or so for the jitter in the 1PPS so the accuracy would be aound 500 to 1000 nanosecs over 40 secs which is say 10^-6 over 40 or 2.5 x 10 ^-8.

author: StillTrying
author_rank: Super Contributor
timestamp: September 09, 2017, 04:07:20 pm
content: http://www.arrl.org/files/file/QEX_Next_Issue/2015/Jul-Aug_2015/Marcus.pdf"Im guessing that 40 seconds was chosen to produce easy to work with numbers"I think it's 40 seconds to give a total count of 100M to be able to detect changes of +/-0.01ppm - in theory."I mean if the crystal is 20parts per million and a 100mhz is 100 million parts, doesn't that mean the arduino count can be up to 2000 counts off?"The timing of when the si5351's 2.5MHz / 100M count is captured is controlled by the GPS's 1PPS.As long as the arduino's clock is >2.5X faster than the 2.5MHz the 100M count will be captured within +/-1 count.

author: Kleinstein
author_rank: Super Contributor
timestamp: September 09, 2017, 04:54:35 pm
content: How accurate the frequency counting works, depends on the implementation on the Arduino. Normally connecting the 1 pps signal to the int0 input is not the best way to make a high resolution counter, though it is possible to get a good accuracy, if tricks like going to a sleep mode to avoid extra interrupt jitter are used. However there would be an additional error of up to +-1 clock cycle of the µC.The more logical way would be using a 10 to 20 MHz clock (e.g. 12.5 MHz) from the Si5351 to clock the µC and than route the 1PPS signal to the ICP input. This would give a slightly higher resolution due a higher count number, simpler software and no extra error from the extra µC clock. Ideally the software could use extrended resolution mode by looking at all the 1PPS pulses and not just the first and last in a 40 seconds window. This could give a little additional suppression of jitter of the 1 PPS pulses and maybe slightly better resolution (depending on the frequencies used - it won't help with exactly 12.5 MHz).PS. Even if counting over 40 seconds, 2,5 MHz are still 2,5 MHz it is just 100 million counts.

author: rwgast_lowlevellogicdesin
author_rank: Frequent Contributor
timestamp: September 09, 2017, 07:09:26 pm
content: @Kleinstien, your way does make much more sense, its how I originally envisioned this would work before reading this QEX article. Iv'e already decided if I use the interrupt technique described in the article I will probably dedicate an Attiny to doing nothing but setting up the si5351 and calibrating it against the 1pps signal. This way there is no interrupts or other code throwing off the timing, or I may just switch from AVR to a propeller chip and dedicate a full core to the task. The thing is I want to add a nicte 2.8inch TFT and two DDS chips locked to the clock, this way I can have quadrature squares or sign waves so I may just be moving it all to a cypress PSOC or something, in which case I can use the hardware blocks to separate any microcontroller issues from the timing.@Jpb, StillTrying thank you the paper makes much more sense now than it did before. But I am still hung up on the arduinos 20ppm crystal.. to me the logic is, yes all the arduino is there for is to count the 2.5mhz signal for 40 seconds, but wouldn't that be like using a frequency counter with 20ppm of accuracy, or am I confused and the counter peripherals are somehow not effected by system clock jitter?Code:As long as the arduino's clock is >2.5X faster than the 2.5MHz the 100M count will be captured within +/-1 count.Does this have something to do with NyQuist? I understand in order to recreate the original signal you have to sample that you have to same it at a clock rate at least 2x faster than itself, but I guess I am not seeing how that ties in to the accuracy of the count.Im sorry I keep pushing this 20ppm thing I am just not understanding why the micro that is counting the si5351 frequency wouldnt want a clock with less error, I am not arguing at this point that it needs a better clock only trying to understand why its accuracy is not important.

author: Kleinstein
author_rank: Super Contributor
timestamp: September 09, 2017, 07:53:16 pm
content: When using the method described in the article, the accuracy of the µCs clock does not matter (it could us the µC internal RC clock, that is something like +-1%). The µC is counting the 2.5 MHz clock, but sampled at the µCs clock.However the additional clock (even of stable) adds an additional jitter from the extra synchronization / sampling. So if clocked at 10 MHz, this would be another +-100 ns. It is only if the µC's clock is in sync with the signal to count that there would be no big additional jitter. Due to the synchronized input of the AVRs external counter input (for timer 1 - timer 2 can be async, but does not have a capture function) the µCs needs to be higher than 2 times the clock to count - this is the Nynqueist limit. A factor of 2.5 is more like a practical number to allow for uneven H/L.Using the interrupt method would essentially need a dedicated µC, or at least a way to have that µC not doing much else at the start and end of the gate time.When using the µC ICP function, the µC can do other things too, as the critical timing part is done in hardware. I have build a frequency counter that way, where is µC is also doing LED display multiplexing and checking keys. Especially with a 1PPS signal, the µC is essentially 99.9% free to to other things, maybe even relative time critical parts. So it seems reasonable to have the µC also program the clock generator or a DDS chip - however startup might be tricky as the clock is needed to start with. I don't think the AVRs allow to change the clock source on the fly - other µC might do.

author: tggzzz
author_rank: Super Contributor
timestamp: September 09, 2017, 07:55:55 pm
content: Quote from: rwgast_lowlevellogicdesin on September 09, 2017, 07:09:26 pmNah. Use a £12 xCORE startKIT devboardStuff the XO output into a buffered input and use software to count edge transitions in a 62.5Mb/s input stream. Good to >15MHz, assuming a reasonable approximation to a 50% duty cycle.

author: StillTrying
author_rank: Super Contributor
timestamp: September 09, 2017, 08:36:35 pm
content: Quote from: rwgast_lowlevellogicdesin on September 09, 2017, 07:09:26 pmYep similar, assuming I am/was on the right page (I might not be!) ofAtmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-28P_datasheet_Complete.pdfPage 138/9(of 660) says:"17.3 External Clock SourceAn external clock source applied to the T1/T0 pin can be used as Timer/Counter clock (clkT1/clkT0). The T1/T0 pin is sampled once every system clock cycle by the pin synchronization logic. The synchronized (sampled) signal is then passed through the edge detector....The registers are clocked at the positive edge of the internal system clock (clkI/O)....The synchronization and edge detector logic introduces a delay of 2.5 to 3.5 system clock cycles from an edge has been applied to the T1/T0 pin to the counter is updated....Each half period of the external clock applied must be longer than one system clock cycle to ensure correct sampling. The external clock must be guaranteed to have less than half the system clock frequency (fExtClk< fclk_I/O/2) given a 50/50% duty cycle. Since the edge detector uses sampling, the maximum frequency of an external clock it can detect is half the sampling frequency (Nyquist sampling theorem). However, due to variation of the system clock frequency and duty cycle caused by Oscillator source (crystal, resonator, and capacitors) tolerances, it is recommended that maximum frequency of an external clock source is less than fclk_I/O/2.5."I don't think the Marcus.pdf is using the hardware ICP1 capture pin, (I only had a quick-ish look) maybe just using every 40th GPS interrupt to capture the ~100M count value.EDITYRun the uP on its internal RC clock while it sets up the Si5351B to output 10MHz or 20MHz.Then switch the uP to use that as it's clock, the timer can then run/count at that frequency.I think you can use one of the analogue comparators on the 1PPS to capture the timer count every 1 second.That would then give you a 100M count for VCO adjustments every 5 or 10 seconds.Simples!EDITY2I think Kleinstein is correct above, I didn't see any way to swap to the internal RC osc even as a backup.And on the Si5351 data sheet I had only the Si5351Bversion had the VCO input.

author: Kleinstein
author_rank: Super Contributor
timestamp: September 10, 2017, 09:34:50 am
content: It looks like there are versions of the Si5351 that have pre-programmed settings to start with - so there would be a clock to start with, so the µC could run on this clock all the time.Another option would be using an external clock (e.g. 25 MHz oscillator, or if needed an VCXO) and use this to drive both the Si5351 and the AVR. Though only specified for 20 MHz (CPU clock) it should be OK, if the AVR internal divider is used to make the CPU run at half the speed.There is also the x-mega series that can directly run from 25 MHz - they may also switch the clock source while running, though might program there own clock source. At least some PICs and ARMs can do this.Though complicated in software to get it correct one could use a normal pin for the 1PPS signal. Using the ICP input is mainly avoiding the time critical program. The important step to avoid an extra error would be having the µC clock in sync. An alternative would be an external HW gate before the µCs counter input - sounds simple, but can be a little tricky with the sampling nature of the counter. A simple logic gate won't work, but a transparent latch would.

author: tggzzz
author_rank: Super Contributor
timestamp: September 10, 2017, 10:47:40 am
content: Quote from: Kleinstein on September 10, 2017, 09:34:50 amMany processors have the ability to use either an internal clock multiplied from an external XO/resonator, or an external clock.One example is the XMOS xCORE devices, which can have clock-multiplied internal clocks up to 500MHz (=> 250Mb/s i/o per pin) derived from XOs up to 30MHz or external clocks up to 100MHz.

author: pigrew
author_rank: Frequent Contributor
timestamp: September 10, 2017, 03:57:17 pm
content: My understanding is that without DGPS, the GPS PPS signal will always have roughly sigma=15ns even with quantization error correction,See this ublox app-note.So, it's a good idea to have the phase measurement circuitry to have at least this accuracy (or else the system is limited by the phase measurement). >100 MHz clocks may be enough. I see a few options for doing this: using an external timing IC (such as the TDC7200), using a CPLD with a fast internal clock (>300 MHz or so, FPGAs are slower), or using a MCU timer (XMOS, PSoC, ESP32, whatever fast MCU you can find).I don't see any advantages to clocking the CPU with the reference clock, unless there are cross-talk/signal integrity concerns?

author: Kleinstein
author_rank: Super Contributor
timestamp: September 10, 2017, 04:55:52 pm
content: There is a definitive advantage in having the µC clocked from the reference clock (or one derived from it): most timers in the µCs are synchronized to the CPU clock (or maybe even a lower IO clock). If not in sync, this additional sampling would add an extra uncertainty of +-1 CPU clock. In addition there would be the +-1 clock from the reference that needs to be lower than the CPU clock. The problem gets smaller with a faster µC, but it is avoidable. Of cause it is not a problem with an extra TDC or similar to do the timing.One might avoid much of the extra error with a 2 step measurement:1. f(µC) relative to 1 PPS and 2. f(µC) relative to f(reference) using a higher frequency and this way less error. However this is still one extra step.There are also ARM based µCs with timer clocks up to the 100 MHz range. These usually allow to start from a different clock source. There are also some plans for a relatively simple analog timing interpolator based on a slow µC, with relatively little extra hardware.The 40 seconds timing is not a fixed value - usually it takes much longer to get a thermally stable value. Depending on the crystal oscillator, the optimum GPS to crystal cross over is at a longer time scale.

author: tggzzz
author_rank: Super Contributor
timestamp: September 10, 2017, 05:07:56 pm
content: Quote from: Kleinstein on September 10, 2017, 04:55:52 pmOne justification for 40s might be that 100MHz and a 32-bit counter => rollover every 42.94s.

author: pigrew
author_rank: Frequent Contributor
timestamp: September 10, 2017, 05:31:08 pm
content: Quote from: Kleinstein on September 10, 2017, 04:55:52 pmExactly. I had been thinking about using a Tiva C at 80 MHz, clocking the counter with 10MHz reference, and triggering the count to be stored at the PPS edge.

author: Kleinstein
author_rank: Super Contributor
timestamp: September 10, 2017, 08:38:48 pm
content: Quote from: pigrew on September 10, 2017, 05:31:08 pmI think, you miss-understood me completely: This way would give you a 100 ns resolution from the 10 MHz clock plus likely an extra 12.5 ns extra jitter from synchronization to the µC clock (if the timer or 1 PPS capture is synchronous, as it is with nearly all µCs). So a total worst case error of +-112,5 ns plus analog uncertainties from slopes.The way I meant would be measuring the 80 MHz µC clock from the 1 PPS which would give an 12.5 ns uncertainty. Ideally this would be all it takes if the µC clock is accurately liked to the reference by an PLL. Otherwise one could divide down the Reference to a slower clock of maybe 10 kHz. This cold than be measured similar to the 1 PPS signal if done the simple way (start and stop only) the error for the whole step would be at 25 ns.When not just looking at the first and last pulse one can increase the resolution a little. This is kind of averaging all the 40 pulse instead of using only the first and last. The 1PPS measurement might get better by something like a factor of around 3. The gain in resolution also applies to some of the GPS uncertainties (especially jitter from quantization).Due to the larger number of pulses for a 10 kHz signal it might give an improvement by maybe an additional factor of up to 100. So the overall error could be reduced. Especially the second step from the reference to the 80 MHz clock can be very accurate this way and the two step process could be nearly as good as having a fixed (e.g. PLL) link. It is a kind of FLL link in software.

author: rwgast_lowlevellogicdesin
author_rank: Frequent Contributor
timestamp: September 10, 2017, 08:48:18 pm
content: So if I were to just clock the AVR from the same 2.5ppm 25mhz tcxo that is driving the si5351, I would virtually eliminate any short term jitter error, when counting the 2.5mhz output? What is the best way to do this, do I need an unity gain opamp between the tcxo and avr, or some extra hardware to make sure the tcxo can drive both systems?I have been reading up a lot on GPS 1pps jitter and made some most likely inaccurate measurements on my scope, so it seems reasonable to say a 1pps output suffers from 10 to 40ns jitter, what is the best way to handle this? The amount of jitter reduced from the 1pps measurement will greatly effect the very short term stability of si5351, right? I would assume over long periods of time the 1pps jitter will eventually equal itself out?Im sorry this is a real learning experience for me as far as timing and accuracy go. In the end I want to use the VFO a lot of things involving decently accurate quadrature clocking. But for now i'm really looking at using it to replace the 100mhz tcxo in my ADF4351 sig gen, this way I can accurately clock SDR applications for microwave satcom and radio astronomy. Is there any way this will ever be a better (i.e more accurate, phase noise is a whole other story) clock than the .5ppm tcxo on my airspy? The results the original author got look very promising, and i am assuming if slapping a .5ppm tcxo on the si5351 was more accurate that would have been the route he would have taken.

author: rwgast_lowlevellogicdesin
author_rank: Frequent Contributor
timestamp: September 10, 2017, 09:00:53 pm
content: Also what would be my best option of measuring accuracy if I don't have any frequency standard? ATM all I can think of is to experiment and measure any changes I make against the results before and when optimized just rely on the fact that GPS is a pretty stable reference.

author: jpb
author_rank: Super Contributor
timestamp: September 10, 2017, 09:13:31 pm
content: Quote from: rwgast_lowlevellogicdesin on September 10, 2017, 08:48:18 pmThe GPS 1PPS is very accurate over 24 hours but suffers from short term jitter of the order of 10 to 50 nsecs, though with a good aerial and a timing receiver it should be nearer 10 nsecs than 50 nsecs. The longer the time interval the less important the jitter is but the more the drift in the crystal clock so a compromise is needed (as with a GPSDO). With a GPSDO the best compromise is taking a loop time constant that approximates where the Allan Deviation of the OCXO (or Rubidium) crosses over the Allan Deviation plot of the GPS receiver 1PPS. This can be anything from 100 secs to 10,000s of secs.The author of the article has selected 40 secs as a compromise which seems reasonable given that it makes the fractional error of the jitter only around 1E-9 but is not so long that temperature changes and so on mean that the characteristics of the crystal clock being calibrated are drifting significantly.You can't really do much about the jitter (other than installing a good outside antenna and say getting a cheap Lea-6T off ebay) but you can experiment with different time intervals for the measurement or improve the crystal clock (though I guess this is difficult if it is built-in to the circuit).I think worrying about the GPS 1PPS jitter is pointless as it is much less than the cycle time of the calibration clock (2.5MHz). A greater source of improvement would be to use some sort of interpolation scheme of calibrate at a higher frequency.

author: jpb
author_rank: Super Contributor
timestamp: September 10, 2017, 09:15:40 pm
content: Quote from: rwgast_lowlevellogicdesin on September 10, 2017, 09:00:53 pmGPS is a pretty good reference if you take longer gate times. If you have a counter of some sort which measures down to 1Hz (I used a TI930) then taking a 100 second gate will give a very good measure of the accuracy of the counter.

author: StillTrying
author_rank: Super Contributor
timestamp: September 10, 2017, 09:39:27 pm
content: If I was using a 40 seconds count period, I'd create at least 8 40s counting periods all offset by 5 seconds to give a possible correction calculation every 5 seconds. Of course the counter is never stopped or reset because it helps to cancel some of the jitter, and detecting and fixing rollovers in the count-count periods is easy enough, well it is if you say it quick.