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

[Bob kb8tq]

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> wrote:
> 
> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.