On Monday, June 26, 2017, Tom Van Baak <[email protected]> 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" <[email protected] <javascript:;>> > To: <[email protected] <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 -- [email protected] <javascript:;> > > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > > and follow the instructions there. > _______________________________________________ > time-nuts mailing list -- [email protected] <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 -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
