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

Mon Jun 26 16:17:09 EDT 2017

On Monday, June 26, 2017, Tom Van Baak <tvb at leapsecond.com> 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:;>>
> To: <time-nuts at febo.com <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:;>
> > 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