Re: [time-nuts] Z3816 Oscillator Saga
Chris,
The Z3816 has a few design short comings. In the circuit board pic the MTI
oscillator circuit board grounding is improved. Subsequently I opened and
modified the oven internally and added an extra oven feedthrough pin. The
issue is the oven heater current modulates the ground pin voltage and that
effects the EFC value (poor layout). I finally connected the oven power
pins to a separate floating PSU with the new internal oven EFC signal
ground pin the only common connection point, while hunting for the source
of a short transient EFC event.
I would caution you that the circuit board traces and hole plating are very
thin, and both are easily damaged by external forces. I used multiple irons
for un soldering problem pins.
The two tantalum capacitors with the black marker dots are not original.
These two capacitors had the wrong voltage rating and became noisy. These
might also be the source of your problem. It can cause unexpected jumps in
the reported EFC value and are not an oscillator problem, just a dumb
assembly mistake. FYI at the turn of the century cell phone sales had a
surge and tantalum capacitors became impossible to get at 10x the price.
I replaced the Z3816 oscillator temporarily with no problems but observed
at power up the smart clock algorithm used a much higher gain in the EFC
loop for about an hour then drops to a more normal value.
I also adjusted the oven temperature turning point pot, however, I suspect
the MTI internal oven circuitry self calibrates the crystal turning point.
I never figured out how to stop the oven from self calibration and had
intended to fix the oven circuit before I determined it was a feature. The
pot adjustment seemed to have more effect at power up. As I recall, during
the relatively short calibration event, the frequency changes by 0.008Hz
with a maximum gps phase error of about 400ns. I had wondered if the two
algorithms were interacting badly but I never verified this. Even with this
quirk, the 260 is a great oscillator.
-Peter
Hi, I'm new here so please be gentle!
I'm considering designing and building some dataloggers, probably ARM
Cortex based (eg. STM32F4xx), which record the time of infrequent
events, preferably to better than 100ns and if possible better than
50nS. The data loggers will be continuously powered, in fixed locations
and should have reasonably good views of the sky so the use of a low
cost GPS module should be feasible. I believe it shouldn't be too
difficult to resolve the PPS timing to +/- 5ns or better with a 100MHz+
microcontroller clock, but obviously jitter would add to the error
requiring the GPS to be better than perhaps 90ns or so worst case.
Inevitably cost and power constraints apply - ideally the GPS would cost
less than $20 (in quantities of 100), and < $15 would be good, but it
doesn't seem easy to find very lost cost receivers with timing outputs
that are properly specified, presumably because of the relative market
volumes. The power consumption of most timing receivers also seem to be
higher than navigation units - eg. the Trimble SMT-x spec is 100mA
compared to the ADAfruit MTK3339-based module which draws 20mA (but they
are a bit too expensive at $24 apiece).
There are several cheap modules that have PPS outputs but no accuracy
specification; it's possible that these could be used with sufficient
averaging/filtering of the PPS output. Actually repeatability is the
important requirement rather than accuracy as they could be calibrated.
Perhaps even a PPS o/p is not absolutely necessary - could the NEMA
output timing be used given enough averaging and a sufficiently stable
oscillator? Compromising the timing accuracy requirement a bit to say
150ns may be acceptable if the GPS device is cheap enough.
I understand that the PPS outputs of some cheap modules sometimes become
ill-behaved, but in this application the time stamp can be adjusted (or
anomalous clocks ignored) post-event if necessary to correct for
temporary disturbances.
This also raises questions about the short term stability of the
microcontroller oscillator required to maintain sufficient accuracy when
GPS timing is temporarily lost for some reason - but how long would that
need to be? 30s? 5 minutes? 30 minutes? An OCXO or a Stratum-3 TXCO
would be too expensive, but oscillator manufacturers don't seem to
publish short term frequency stability specifications for low cost/low
power oscillators, and finding such information isn't easy. Can anyone
point to figures for a typical non-TXCO low cost oscillator, 10 or 16MHz?
I did find this study, http://tf.nist.gov/general/pdf/2276.pdf,
measuring the stability of some low cost quartz wristwatches which gives
some interesting data of 20 to 65ppb Allan deviation over 100s. That,
but a 32kHz oscillator might give rise to jitter problems when
multiplied up to a suitable frequency.
Some oscillator datasheets specify Allan deviation values, but I guess
what I need for estimating worst case timestamp error during holdover
periods are actually MTIE values. Is there any way to estimate the
latter from Allan deviations specs? Would an ADev of 65 x 10^-9 over
100s imply up to 6.5us of error after 100s?
Any thoughts? Thanks,
Tony H
here is what I'd do....
Get a decent OCXO (ovenized crystal oscillator and control it with your
GPS. Don't worry if the GPS's PPS is 50ns or 5ns. You are going to be
averaging these for a while. Basically you build a GPSDO. These have
become very easy to make. I have one I made for about $8 and it has not
gained or lost 100ns in weeks.
Next get a second uP, not the one controlling the GPSDO. let your GPSDO
10MHz output drive this uP's counter and have the thing your are timing
connect to the pin that will capture the counter. This is done in
HARDWARE. The pin can cause the hardware counter to be captured to a
register. So the software need not be "real time" The counter is ALSO
captured by the 1 PPS from the gps. This way you capture both the one
second "tick" and your event. You log the number of "counts" past the
second.
You can use ARM processors but I'm doing this with an Arduino cone I got on
eBay for under $4. You do not need much CPU power as all the real time
stuff is done in the uP's peripheral hardware. The uP only has to send the
data over a link or log it so an SD memory card. even the 8-bit AVR is
faster than I need for that.
On Fri, May 2, 2014 at 3:54 PM, Tony tnuts@toneh.demon.co.uk wrote:
Hi, I'm new here so please be gentle!
I'm considering designing and building some dataloggers, probably ARM
Cortex based (eg. STM32F4xx), which record the time of infrequent events,
preferably to better than 100ns and if possible better than 50nS. The data
loggers will be continuously powered, in fixed locations and should have
reasonably good views of the sky so the use of a low cost GPS module should
be feasible. I believe it shouldn't be too difficult to resolve the PPS
timing to +/- 5ns or better with a 100MHz+ microcontroller clock, but
obviously jitter would add to the error requiring the GPS to be better than
perhaps 90ns or so worst case.
Inevitably cost and power constraints apply - ideally the GPS would cost
less than $20 (in quantities of 100), and < $15 would be good, but it
doesn't seem easy to find very lost cost receivers with timing outputs that
are properly specified, presumably because of the relative market volumes.
The power consumption of most timing receivers also seem to be higher than
navigation units - eg. the Trimble SMT-x spec is 100mA compared to the
ADAfruit MTK3339-based module which draws 20mA (but they are a bit too
expensive at $24 apiece).
There are several cheap modules that have PPS outputs but no accuracy
specification; it's possible that these could be used with sufficient
averaging/filtering of the PPS output. Actually repeatability is the
important requirement rather than accuracy as they could be calibrated.
Perhaps even a PPS o/p is not absolutely necessary - could the NEMA output
timing be used given enough averaging and a sufficiently stable oscillator?
Compromising the timing accuracy requirement a bit to say 150ns may be
acceptable if the GPS device is cheap enough.
I understand that the PPS outputs of some cheap modules sometimes become
ill-behaved, but in this application the time stamp can be adjusted (or
anomalous clocks ignored) post-event if necessary to correct for temporary
disturbances.
This also raises questions about the short term stability of the
microcontroller oscillator required to maintain sufficient accuracy when
GPS timing is temporarily lost for some reason - but how long would that
need to be? 30s? 5 minutes? 30 minutes? An OCXO or a Stratum-3 TXCO would
be too expensive, but oscillator manufacturers don't seem to publish short
term frequency stability specifications for low cost/low power oscillators,
and finding such information isn't easy. Can anyone point to figures for a
typical non-TXCO low cost oscillator, 10 or 16MHz?
I did find this study, http://tf.nist.gov/general/pdf/2276.pdf, measuring
the stability of some low cost quartz wristwatches which gives some
interesting data of 20 to 65ppb Allan deviation over 100s. That, but a
32kHz oscillator might give rise to jitter problems when multiplied up to a
suitable frequency.
Some oscillator datasheets specify Allan deviation values, but I guess
what I need for estimating worst case timestamp error during holdover
periods are actually MTIE values. Is there any way to estimate the latter
from Allan deviations specs? Would an ADev of 65 x 10^-9 over 100s imply up
to 6.5us of error after 100s?
Any thoughts? Thanks,
Tony H
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
-----Original Message-----
From: Tony
[]
I'm considering designing and building some dataloggers, probably ARM
Cortex based (eg. STM32F4xx), which record the time of infrequent
events, preferably to better than 100ns and if possible better than
50nS. The data loggers will be continuously powered, in fixed locations
and should have reasonably good views of the sky so the use of a low
cost GPS module should be feasible. I believe it shouldn't be too
difficult to resolve the PPS timing to +/- 5ns or better with a 100MHz+
microcontroller clock, but obviously jitter would add to the error
requiring the GPS to be better than perhaps 90ns or so worst case.
[]
---==
The MAX-7Q has a TCXO and works well as a PPS source.
https://www.u-blox.com/en/gps-modules/pvt-modules/max-7.html
or perhaps the MAX-M8Q but I've not played with one of those.
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Moin,
On Fri, 02 May 2014 23:54:25 +0100
Tony tnuts@toneh.demon.co.uk wrote:
I'm considering designing and building some dataloggers, probably ARM
Cortex based (eg. STM32F4xx), which record the time of infrequent
events, preferably to better than 100ns and if possible better than
50nS. The data loggers will be continuously powered, in fixed locations
and should have reasonably good views of the sky so the use of a low
cost GPS module should be feasible. I believe it shouldn't be too
difficult to resolve the PPS timing to +/- 5ns or better with a 100MHz+
microcontroller clock, but obviously jitter would add to the error
requiring the GPS to be better than perhaps 90ns or so worst case.
if i'm not mistaken the c/c units of the STM32F4xx run at half main clock,
ie 84MHz max. That would give you a resolution of 12ns.
If you run of a VCXO and can stear the average PPS to lie at the border
between two bins, ie that half of the time the PPS is higher, half of
the time lower, then you should be able to get a bit better than 12ns.
Inevitably cost and power constraints apply - ideally the GPS would cost
less than $20 (in quantities of 100), and < $15 would be good, but it
doesn't seem easy to find very lost cost receivers with timing outputs
that are properly specified, presumably because of the relative market
volumes. The power consumption of most timing receivers also seem to be
higher than navigation units - eg. the Trimble SMT-x spec is 100mA
compared to the ADAfruit MTK3339-based module which draws 20mA (but they
are a bit too expensive at $24 apiece).
You can try the LEA modules from u-blox. Single piece they are available
from ebay. You can get them from u-blox directly too. But you have to
buy a couple at once otherwise you pay way too much. IIRC prices get
reasonable from 20 pieces upward.
Even the non-timing modules have usually PPS specified to be better than 100ns.
This also raises questions about the short term stability of the
microcontroller oscillator required to maintain sufficient accuracy when
GPS timing is temporarily lost for some reason - but how long would that
need to be? 30s? 5 minutes? 30 minutes? An OCXO or a Stratum-3 TXCO
would be too expensive, but oscillator manufacturers don't seem to
publish short term frequency stability specifications for low cost/low
power oscillators, and finding such information isn't easy. Can anyone
point to figures for a typical non-TXCO low cost oscillator, 10 or 16MHz?
Have a look at John Vig's crystal oscillator tutorial to get an understanding
of the different effects that affect the oscillator. As mentioned already
temperature should be your first concern.
I did find this study, http://tf.nist.gov/general/pdf/2276.pdf,
measuring the stability of some low cost quartz wristwatches which gives
some interesting data of 20 to 65ppb Allan deviation over 100s. That,
but a 32kHz oscillator might give rise to jitter problems when
multiplied up to a suitable frequency.
The frequency does not affect the jitter as much as you think. It's more
the Q of the oscillator that determines the close in phase noise.
But as you are using a uC, the phase noise will be dominated by the
PLL and VCO in the uC itself more than the one of the external oscillator.
Also, the phase noise induced jitter is negligible compared to other
effects when you are time stamping (a good oscillator gives you a jitter
of <10ps, much below the ~10ns you can measure).
Some oscillator datasheets specify Allan deviation values, but I guess
what I need for estimating worst case timestamp error during holdover
periods are actually MTIE values. Is there any way to estimate the
latter from Allan deviations specs? Would an ADev of 65 x 10^-9 over
100s imply up to 6.5us of error after 100s?
Under the assumption of no other environmental changes, yes.
But on the order of 100s, temperature becomes significant for the
accuracy you want to acheive. You either have to compensate it in
the oscillator (using a TXCO) or correct it in software by measuring
the temperature yourself. Alternatively, you can try to keep the
quartz temperature within +/-1°C using some heating element.
(it does not need to be a full OCXO)
Also keep in mind that the ADEV values is the statistical variation
of the signal. ie it represents a 1 sigma value. As a normal distribution
is assumed, your error is unbounded (not actually true). If you are
sensitive to maximum error, you should work with a 3 to 6 sigma value
instead of with the ADEV value directly.
Also note: ADEV changes with integration time and its value cannot
easily be extrapolated, in general. You can take certain assumptions
as to what kind of effect takes place in which time scale and apply
its slope, but that's at most a rough guess.
For more information on this topic see "Phase Noise and Frequency Stability
in Oscillators" by Enrico Rubiola.
HTH
Attila Kinali
--
I pity people who can't find laughter or at least some bit of amusement in
the little doings of the day. I believe I could find something ridiculous
even in the saddest moment, if necessary. It has nothing to do with being
superficial. It's a matter of joy in life.
-- Sophie Scholl