[time-nuts] Yet Another GPSDO design - Timing on the move

William H. Fite omniryx at gmail.com
Mon Jun 26 21:33:12 UTC 2017


Not always, by any means. Stochastic error (in simplest terms, the
difference between expected and actual) may be random or systematic.
Systematic error, which may be reflected in outliers and in other ways, is
at least potentially findable and fixable. Unhappily, random error will
always be present, its amount can never be determined, and while it can be
minimized, it can never be eliminated. I think it is more accurate to say
that anomalous measurements MAY be findable and finding them gives....as
you said.



On Monday, June 26, 2017, Bob kb8tq <kb8tq at n1k.org> wrote:

> Hi
>
> It’s mainly a matter of causality. If you have an anomalous reading, there
> is likely a “findable” reason
> for it. Finding that reason probably gives you useful information about
> the design and how to
> improve it.
>
> Bob
>
> > On Jun 26, 2017, at 4:17 PM, William H. Fite <omniryx at gmail.com
> <javascript:;>> wrote:
> >
> > On Monday, June 26, 2017, Tom Van Baak <tvb at leapsecond.com
> <javascript:;>> wrote:
> >
> >>
> >> Be careful about that. Act like there are no outliers: every point is
> >> trying to tell you something.
> >
> >
> > ARRRRRGHHHH! Your resident statistician just had a sudden, stabbing pain
> in
> > the head. Before an audience of statisticians, you would find that
> > statement extremely difficult to justify. Indeed, some would say it is
> > inherently self-contradictory.
> >
> > Perhaps in this context it does not matter. Your knowledge is vastly
> > greater than mine in the TF domain.
> >
> >
> >
> >> /tvb
> >>
> >> ----- Original Message -----
> >> From: "Jan-Derk Bakker" <jdbakker at gmail.com <javascript:;>
> <javascript:;>>
> >> To: <time-nuts at febo.com <javascript:;> <javascript:;>>
> >> Sent: Monday, June 19, 2017 3:44 PM
> >> Subject: [time-nuts] Yet Another GPSDO design - Timing on the move
> >>
> >>
> >>> Dear all,
> >>>
> >>> After a hiatus of seven years I have finished the first version of my
> >> GPSDO
> >>> design. The full schematic can be found at
> >> https://drive.google.com/file/d/
> >>> 0B7mNymXfcKMqaFcyRXdURC1KMXM/view?usp=sharing (Google Drive seems to
> >> guess
> >>> the file type wrong; Acrobat opens the file just fine). Its first use
> >> will
> >>> be in the telemetry system of my students' solar-powered boat (
> >>> http://cleanmobility.info/voertuigen/solar-2015/ ), on a trip from
> >>> Amsterdam to Monaco.
> >>>
> >>> The design objectives are, in decreasing order of importance:
> >>>
> >>> 1) Providing a reference frequency for a SDR system in the 868MHz ISM
> >> band,
> >>> having a frequency drift over a day no worse than 10% of the maximum
> >>> Doppler shift at a relative speed of 100km/h, while consuming at most
> 2W
> >> in
> >>> steady-state from a 24V net
> >>>
> >>> 2) Testing/teaching platform for the evaluation of different design
> >> choices
> >>> in a GPSDO, including alternative phase detectors, EFC generation by
> DAC
> >> vs
> >>> PWM, FLL/PLL algorithms, timing vs navigation receivers, and OCXO
> choices
> >>>
> >>> 3) When equipped with a timing receiver, having ADEV/MDEV at most 10x
> >> worse
> >>> than a Thunderbolt in the interval between 1s and 1d.
> >>>
> >>> (Yes, objective 1 could be met with a quality OCXO, but where's the fun
> >> in
> >>> that?)
> >>>
> >>> Where possible I tried to stick to the suggested design criteria listed
> >> in
> >>> https://www.febo.com/pipermail/time-nuts/2007-April/025597.html .
> >>>
> >>> The primary phase detector is a TDC7200, which almost feels like
> cheating
> >>> after all the trouble I went through last time (
> >>> https://www.febo.com/pipermail/time-nuts/2010-August/049347.html ).
> The
> >>> '7200 is used in Mode I, which needs at least 12ns between START and
> >> STOP.
> >>> A fairly vanilla synchronizer handles this. As I expect the phase
> offset
> >> in
> >>> lock to be zero (modulo hanging bridges), the first flip-flop is
> clocked
> >>> with an inverted copy of the main clock to further reduce the
> possibility
> >>> for metastability. U16/U17 latch the lower bits of clock divider
> U19/U18
> >> to
> >>> get around synchronizer uncertainty in the microcontroller. A second
> >>> TDC7200 channel is added to ease comparison with other references or
> >>> timestamp external events. (I have a mains ZCD in the works just for
> >> this).
> >>> Both channels have a simple flip-flop as an alternate phase detector;
> the
> >>> second channel can be wired to be driven by the GPS PPS as well.
> >>>
> >>> The microcontroller board holds a 32MHz ATXMega256A3U. While this board
> >>> cannot use the 10MHz oscillator for its main clock, both 10MHz and PPS
> >>> inputs are available as event channels. The microcontroller board also
> >> has
> >>> a microSD socket for standalone phase data logging and a charger for a
> >>> small LiIon cell that can provide power when the boat's systems are
> >> powered
> >>> down. U21 is a 128KB SRAM chip for scratch space, U13 is a FeRAM chip
> to
> >>> store EFC settings (as EEPROM would wear out too fast with regular
> >> writes,
> >>> and I cannot guarantee having enough energy after detecting a brownout
> to
> >>> only write to EEPROM in such conditions). The other systems for the
> boat
> >>> already include a GPS module (Venus 6) which is used for PPS in normal
> >>> circumstances; a footprint for a small Venus8-board offers an
> alternative
> >>> in standalone use ( until I can get my hands on a 3v3 timing receiver
> ).
> >>> The microcontroller measures system temperature, OCXO current and the
> >>> voltages on the raw power nets.
> >>>
> >>> The EFC is based on a pair of 16-bit DACs plus a 24-bit ADC in a PID
> >> loop,
> >>> inspired by Linear/Jim Williams' AN86 ( http://www.linear.com/docs/
> 4177
> >> ).
> >>> The DACs are fairly noisy, an RC with a few film caps plus a quiet
> >> follower
> >>> should take care of that. Plan B for the EFC is a pair of PWM outputs
> >> from
> >>> the microcontroller followed by a 4-pole filter. Both 1in2 OCXOs with
> and
> >>> without internal reference can be used, as well as cheaper
> >> Connor-Winfield
> >>> DOC/DOT-series XOs.
> >>>
> >>> What else? Status LEDs, a heavily filtered synchronized switch-mode
> >> supply
> >>> (necessary to hit the power consumption target), an isolated serial
> debug
> >>> line.
> >>>
> >>> Things I have yet to figure out:
> >>> - how to apply the temperature measurements to the EFC. I guess I can
> >>> measure the holdover performance of the GPSDO in a climate chamber, but
> >>> does such a temperature curve stay mostly-constant over the life of the
> >>> OCXO?
> >>> - similar to the previous point: how to apply the current measurements
> to
> >>> the EFC. Is there any way to measure/estimate the resistance in the
> >> shared
> >>> path between heater GND and EFC GND? (I've done my best to directly
> refer
> >>> the filter and the ADC to the GND pin of the oscillator to reduce this
> >>> effect on the external path).
> >>> - how to properly do outlier removal in a mobile platform which may get
> >>> bumped (leading to OCXO jumps). My starting point looks like
> >>> https://www.febo.com/pipermail/time-nuts/2006-December/022689.html ,
> but
> >>> I'm not sure how to make this robust enough without throwing too much
> >>> useable data away. Possibly monitoring (changes in) the satellites the
> >>> GPSDO uses for its solution might help
> >>> - in relation to the previous point: when to switch between FLL
> >>> (aquisition) and PLL (tracking), and when to switch PLL time constants.
> >>> (Maybe I should have added an accelerometer to detect jolts)
> >>> - how to measure ADEV/MDEV beyond hooking my Thunderbolt and/or my
> >> FE-5680
> >>> to the auxillary input
> >>> (- plus all unknown unknowns)
> >>>
> >>> We're building ten of these to start with. (With a good OCXO, the BOM
> >> cost
> >>> is a bit over the eBay price of a Thunderbolt). Some stay in Amsterdam
> >> over
> >>> the summer to collect phase data; for those coming to Monaco I'm still
> >>> undecided whether I'll try a simple version of my FLL/PLL or to just
> use
> >>> this trip for logging.
> >>>
> >>> Thoughts?
> >>>
> >>> JDB.
> >>> _______________________________________________
> >>> time-nuts mailing list -- time-nuts at febo.com <javascript:;>
> <javascript:;>
> >>> To unsubscribe, go to https://www.febo.com/cgi-bin/
> >> mailman/listinfo/time-nuts
> >>> and follow the instructions there.
> >> _______________________________________________
> >> time-nuts mailing list -- time-nuts at febo.com <javascript:;>
> <javascript:;>
> >> To unsubscribe, go to https://www.febo.com/cgi-bin/
> >> mailman/listinfo/time-nuts
> >> and follow the instructions there.
> >>
> >
> >
> > --
> > William H Fite, PhD
> > Independent Consultant
> > Statistical Analysis & Research Methods
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at febo.com <javascript:;>
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> > and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com <javascript:;>
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>


-- 
William H Fite, PhD
Independent Consultant
Statistical Analysis & Research Methods



More information about the Time-nuts_lists.febo.com mailing list