Feasability of GPS disciplined oscillator with integrated frequency counter, witha a P2 MCU
samuell
Posts: 554
in Propeller 2
Hi,
I wanted to implement a GPS disciplined TCXO. I'm choosi g a P2 because of the interrupts. The GPS module I have outputs a 1bps signal, but no 10MHz signal. So, I'm planning to use a P2 to count the frequency from the VCTCXO, using the positive edge from the 1bps coming from the GPS module.
The P2 will also monitor the lock signal from the same module, pass SPI communication to that module, and output to a low noise DAC that controls the Vref of the VCTCXO to fine tune it.
In essence, I need to use a counter to count the 10MHz ish frequency from the VCTCXO, triggered by the rising edge of the same signal. The counter needs to be started and then stopped by the rising edge of the 1bps signal from the GPS module. I would prefer to implement an interrupt for that start/stop function, to ensure accuracy and no latency.
Is it feasable? I would choose the P1, but I think I need an interrupt.
Kind regards, Samuel Lourenço
I wanted to implement a GPS disciplined TCXO. I'm choosi g a P2 because of the interrupts. The GPS module I have outputs a 1bps signal, but no 10MHz signal. So, I'm planning to use a P2 to count the frequency from the VCTCXO, using the positive edge from the 1bps coming from the GPS module.
The P2 will also monitor the lock signal from the same module, pass SPI communication to that module, and output to a low noise DAC that controls the Vref of the VCTCXO to fine tune it.
In essence, I need to use a counter to count the 10MHz ish frequency from the VCTCXO, triggered by the rising edge of the same signal. The counter needs to be started and then stopped by the rising edge of the 1bps signal from the GPS module. I would prefer to implement an interrupt for that start/stop function, to ensure accuracy and no latency.
Is it feasable? I would choose the P1, but I think I need an interrupt.
Kind regards, Samuel Lourenço
Comments
' counter A used to count rising edges of 10Mhz waitpeq pps_mask,pps_mask ' wait for rising edge from 1Hz mov new_count,phsa ' sample the current counter value mov count_10M,new_count ' sub count_10M,old_count ' compute the difference mov old_count,new_count ' ' I think there's a method to do this in 2 instructions, but ' this is easier to understand.Waitpeq triggers with 1 sysclock cycle resolution. You are likely to loose a cycle here and there if you start and stop the counter. If you stop the counter to read it, there will be 8 clocks where the counter does not advance. That guarantees 1 missed 10MHz cycle, but it could be 2. If you stop the counter to read and clear, that takes 12 cycles and you'll miss between 1 and 2 rising edges at 10MHz.Trying to read and reset PHSA without stopping the counter is a bad idea here. If you study the propeller's execution pipeline, reads happen 3 cycles before writes (special purpose registers like PHSA are only accessible as source). So we would still miss edges in a 7 clock window between source read and destination write. I've had good success with simply reading the counter and computing the delta.
If I understand correctly the propeller will operate with from its own independent clock source. This could add some sampling uncertainty, or not. YMMV. I've thought about building a GPSDO with a propeller. What I though would be a clever thing to do would be to drive the propeller with an 80MHz or 100MHz low noise VCXO so it could double as a programmable clock divider. The propeller PLL's phase noise is not quite good enough for RF applications, running directly from a crystal oscillator is fine. I don't know if phase noise is important to you. Would clocking the propeller from the 10MHz improve the performance? I think so but I can't prove it.
However, the duration of the high state of the 1bps signal is not well established. Probably, I'll have to use a latch/divider to get a 0.5Hz signal having precisely equal 1sec high and 1s low periods, if a low to high trigger cannot be used to start and stop the counter. This probably has to be done with interrupts, as this cannot be affected by the CPU clock or have any latency (in order not to miss any cycles from the 10MHz VCTCXO).
The P2 clock is independent, and shouldn't have effect on the measurement. A higher clock should increase granularity, up to a certain point.
Affording any latency will cause the frequency to be incorrectly measured as low, and thus leading to an improper tuning of the VCTCXO.
About the gating, it is a great idea. Probably I'll have to add a latch, so one more AND gate wouldn't be a tall order.
Kind regards, Samuel Lourenço
Interrupts are not essential.
P2 can do this with higher precision, and can use the inbuilt DAC, but it's quite an over kill...
See this :
https://forums.parallax.com/discussion/123170/propbasic-reciprocal-frequency-counter-0-5hz-to-40mhz-40mhz-now
Note the 0.5Hz, that's there specifically to manage 1pps from GPS systems.
I would avoid start/stop and instead capture a running counter. P1 can WAIT on a pin-state, with 1 SysCLK granularity, so a WAIT then READ is 12.5ns precise.
The big advantage of using capture, is you never lose any clock edges, so captures over 10s and 100s give you more precision.
80MHz is 12.5ppb in 1 second, and 1.25ppb in 10 seconds.
Do you plan to clock the P1 from the VCTCXO, or is that in a separate unit ?
The MCU will be clocked independently, for sure. SaucySolition gave me an idea, of gating the 10MHz clock with the 1s signal derived from the 1bps signal. No rising edge triggering needed, as well as no interrupt. I'll use the P1, therefore.
I'll be using an external, low-noise precision DAC. P2 is definitely overkill.
By the way, using Saucy's idea I can run the counter continuously, since the gating is external. So, your sugestion will be implemented too. I'm planning to use two counters, gated in alternate fashions, so while one is counting, the other can be read and set to zero. This will save time between readings.
Kind regards, Samuel Lourenço
I would avoid any gating, as that removes being able to run long term averages, and you do not need it. Just capture on edge and run differences, as shown above.
If you look at the reciprocal-frequency-counter link above, that uses two counters, one measures time and one measures cycles.
In P1 you can clock a counter on slower external edges, so a 80MHz P1 can clock a counter at 10MHz External.
That's slightly less ppb/second than using eg (10MHz/2) to clock the P1, and using the PLL to 80MHz
The EFM8BB3/LB1 have useful DACs, and cost the same/less than an equivalent standalone DAC.
If you want to chase precision, I found useful links a while ago here :
http://www.simonsdialogs.com/2018/10/u-blox-gps-receiver-a-self-regulating-clock-and-a-gpsdo-and-all-of-this-for-the-lowest-cost/222/
The interesting bit here is this :
"This program reads the NAV-CLOCK message from the u-blox receiver, does a magic calculation, and then sets the EFC voltage of the OCXO, which in turn determines the 26.000 MHz clock for the same u-blox receiver. And after not too long time, all is frequency looked."
ie apparently, on GPS modules you can read the NAV-CLOCK message which reports the local GPS error from ideal time, and using that you can get more accurate than the local GPS time.
In you case you use 1pps, and 10MHz TCXO, but also read NAV-CLOCK messages to determine how accurate that 1pps really is...
I've drawn a schematic for the gating, using an 74HC107 and three very fast NAND gates (have to pick the family). Please see the attached file.
So, it is essentially using the positive edge as a trigger to capture the counter value? That would be ideal, but how do you avoid counter turnover? Plus, how do you account for the latency caused by an eventual MCU delay (for example, between seeing a positive edge of the 1bps signal and actually reading the counter)?
Kind regards, Samuel Lourenço
You can add code to check for turnover, but usually a simple difference works ok on unsigned numbers. Check Bean's code in the Freq Ctr.
There is no need to externally gate anything, if you use capture.
If we wanted to measure the 1Hz signal (or Pulse Per Second) against the propeller's system clock we could do it like this. The CNT register increments every clock cycle. We can't reset it. The code is triggered by the rising edge of PPS, so it runs once per second. This code take much less time than the duration of the PPS pulse. So we also wait for the falling edge, to make sure that we don't loop continuously while PPS is high.
However, we actually want to measure against the 10MHz VCXO. We can configure a counter to increment on each rising edge of the 10MHz signal. We let it run and record its value as quickly as we can after each rising edge of PPS.
Counter turnover is not a problem when calculating the difference. As long as the actual difference value does not overflow the registers. The count values for your application would be in the 10 million range, well within the (2^32) -1 limit for a 32 bit register. For example: new-old=difference: $0000_000a - $ffff_fff6 = 20
I have to weight all the possibilities and perform some testing.
I don't know a thing about Spin. Is there any chance of manipulating the counters in C?
Kind regards, Samuel Lourenço
Here is some sample code the is an SBUS decoder for RC equipment.
void doRecSBus(void *par) { int rxmask; int rxbits; int rxdata; int baud; int wcnt; int c; rxmask = 1 << _SBPin; baud = 800; c = 0; while (1) { waitpne(0, rxmask); // Wait for Start Bit rxbits = 10; rxdata = 0; wcnt = baud >> 1; wcnt = wcnt + CNT; while (rxbits > 0) { wcnt += baud; waitcnt2(wcnt, baud); // Wait for Center of Next bit rxdata = rxdata << 1; if ((rxmask & INA) != rxmask) // Reverse Bit value rxdata = rxdata | 1; rxbits--; } rxdata = rxdata >> 2; // Dump Parity and Stop if (rxdata == 0xf0) // SBus Start Byte Frame value c = 0; _Dc[c] = rxdata; if (c++ > 25) // Just in case c = 25; if (c == 24) doChannel(); } }Mike
if you already know any language, spin will be easy.
Kind regards, Samuel Lourenço
-Phil
Fair point, I was thinking of Bean's Reciprocal Frequency Counter code, which is in PropBASIC, which compiles to COG.
This new Basic/C/Spin tool suite from ersmith could be worth a look too... I see his Basic compiler (P1 & P2) is improved again...
https://forums.parallax.com/discussion/comment/1476010/#Comment_1476010
"There's a new release of fastspin with improved BASIC support. This round I've added much better support for objects, including inline class definitions (they no longer have to be in a separate file) and passing objects to functions. There's also a STR$() function for converting numbers to strings, and a new template syntax for generic functions.
I've made an announcement in the fastspin thread, but also wanted to post here because (a) the BASIC language is considerably updated, and (b) it works on P1 as well as P2, and some people may not follow the P2 threads."
IIRC he ported Bean's Reciprocal Frequency Counter, as an early test.
The serial output of timing GPS receivers will send what the quantization error is (calculated).
Something like the M12+ would be a good GPS to use.
It is almost not worth doing for a TCXO (even a 50ppB one) because you will most likely be chasing it all the time and never be able to hold less than a couple ppB. Partly because of the 1pps error and partly because the TCXO will be moving.
I'd get an OCXO if you want to create a frequency standard.
If you are just doing this as an experiment, then feel free to use whatever you wish.
Bean
P.S. The DOT050F-010.0M does not have adjust. You would want the DOT050V-010.0M to be able to connect to the DAC.
I can say that I once built a 10MHz clock reference with one of those, and the deviation was 800ppb, which is way more than the 25ppb that they advertise. Another one, using the same OCXO, showed a deviation of 200pbb.
Kind regards, Samuel Lourenço
On the topic of TCXO stability, I recalled this link I found a while ago.
https://nt7s.com/2016/04/si5351a-breakout-board-tcxo-upgrade/
Shows all TCXOs are not equal and some correct more in a sawtooth fashion.
Murata have some new VCTCXOs here, I might try sometime...
https://www.murata.com/search/productsearch?cate=cgsubCrystalOscillators&partno=XTCLH*J
As for those Murata TCXOs, they are tiny. The AST3TQ series offers similarly rated oscillators. See option 2 in the datasheet: https://abracon.com/Oscillators/AST3TQ.pdf. You may want to consider one of those too.
Kind regards, Samuel Lourenço