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 <[email protected]> wrote: > > 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. _______________________________________________ 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.
