Precise waits
average joe
Posts: 795
Trying to figure precision waits and having a bit of difficulty. The instruction in bold seems to be the problem. My question is how many clock cycles should I have as the offset. I know I need to subtract something from the delay to compensate for the time the waitcnt takes to calculate. For some reason, the number 384 keeps popping into my head. Any help is greatly appreciated!
CON _delay = (_clkfreq * 5) - 1920 PUB Test | d outa[_trigger] := 0 d := cnt repeat [B]waitcnt(d += _delay)[/B] dira[_trigger] := 1 Update(@packet,3000,@timeStamp,@channel) dira[_trigger] := 0
Comments
-Phil
Bean
Do you overwrite _clkfreq somewhere? _clkfreq is one of the values stored in the first 16 bytes of a propeller binary.
Update packet just strips the time stamp from a precision timing source and displays it on my terminal.
With this bit of code, the count gains 1/10,000 of a second every 14-18 seconds. I was subtracting some clock cycles to try to compensate for this drift. 1920 was around the number of clock cycles that caused me to lose 1/10,000 over a longish period. (40 seconds or so.)
I started thinking about it last night and I'm beginning to wonder if this the maximum accuracy possible with this clock source (4mhz, x16pll, +- 10ppm). It may be due to connections, stray capacitance / inductance? This is a breadbord test so that might explain some degree. I do see some clock pulses that look suspicious on the LA.
Its been going since September and its off by 9 seconds. So, it drifts in and out, but when it drifts out it, pretty much drift back in later.
This is in a basement where temperature is stable, the one in the garage drifted around more, but that test ended when I bumped the power supply.
Does your application require it to be sync'd with a source, or are you just seeing how good you can get it?
-Phil
10ppm is reasonably good starting precision for a generic crystal.
You can trim to better, but expect to need to do that per-crystal,as you chase down the last few ppm.
Also expect some ppm of wander, with temp and age.
To go much under 1ppm, you need to move to a TCXO, or use a GPS 1pps as a calibrator, and adjust your Divider value. (I read specs on one today that claimed +/- 11ns, 12mA locked and ~$20, needs antenna )
A. The accuracy of your computer language.
pfth can do accuracate delays in the 30 microsecond range and maybe as low as 20 or 15 microseconds... according to the numerical count.
PASM should be able to precise delays down to much further.
But only the numbers are precise.. actual time wanders with the stabilty of the oscillator.
B. The stability of your oscillator... variation is mainly due to changes in ambient temperature.
A regular crystal is about 3% accuracy due to ambient temperature changes, some are better than that.
More expensive crystals in ovens are higher stability in the range of hundreds of dollars.
And you can go much higher if you have deep pockets and care nothing of compact size.
It get rather silly to chase exceptional timekeeping on Propeller unless you really need it. It is easier to synch with GPS or the internet.
But losing 1/10,000 in 15s is 1/150,000 is 6ppm
You may want to edit that. A 3% crystal would be sent back as wrongly labeled.
Crystals are specified in ppm. 50-100ppm is typically the poorest specs.
For long run stability use someone else's precise clock.
With gps you have the 1pps signal which is quite tight, as long as you can get a fix signal.
Moreover not all the gps units handle the 1pps the same way, so it might not be a good solution.
Internet time is another nice long term clock solution.
In both cases you rely to the xtal clock, and adjust the time occasionally, in case it fits your requirements...
Massimo
? If it is called 1pps, surely it had pulses once a second ?
I've seen variances of the leading edge delay from formal exact second, (not usually an issue), and some variances in pulse widths, but they all seem to spec a precise one second cadence.
True, but the delay of the 1pps with respect to GPS time is well defined. I have in mind A1035-H datasheet, but probably many others have similar specs.
Citing the datasheet:
Under good signal conditions the 1PPS signal comes between 620ns and 710ns
after the full GPS system second which is accurately (around 10ns) synchronized to
UTC. Therefore the 1 second clock can be derived and maintained within around
90ns under good signal conditions.
Note: The 1PPS clock accuracy directly depends on the position accuracy! The
GPS signals travel at the speed of light, therefore a position inaccuracy directly
translates into 1PPS inaccuracies.
10 m position deviation ≈ 33 ns 1PPS deviation (typically)
100 m position deviation ≈ 333 ns 1PPS deviation (typically)
Moreover not all the gps units handle the 1pps the same way, so it might not be a good solution.
A bit more information, I am using a TXCO specd at +-10ppm. Later versions will likely switch to +- 10ppb or better. At least I have a good starting point, and have verified my results are within expected specifications. Hopefully I can share more information soon!
You can get 2.5ppm quite cheaply (eg FOX924B) and VCTXCO are slightly more, but VCTXCO allow you to manually trim them.
(Those will need a small external divider, as 4MHz is less common in TCXO, & tends to be outside the lowest prices)
My point exactly, I have difficulty explaining it, sorry.
The 1pps deviation figures are derived from the specific unit datasheet.
The 1pps could offer a tighter sync, but it is device dependent.