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.

Jan-Derk, Thanks for sharing this project with us, and including the schematic. Some comments: > 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. Interesting application. My first thought is that your design will have to pay much more attention to environmental issues than the typical homebrew GPSDO: temperature, humidity, moisture, air flow, and oscillator orientation and acceleration. At least you don't have to worry about poor GPS coverage or changes in altitude! > 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 Can you translate this into T&F units for us? What timing accuracy? What frequency accuracy? What ADEV? Is there a low PN requirement? > 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 Those are all good topics for teaching. I worry that a pre-designed board like yours saves the students from having to think or work. Perhaps they could first try a James Miller analog GPSDO or a Nick Sayer simple digital Arduino-based GPSDO to see how good they are. Note also that the art of measuring a GPSDO is as complex as the art of designing a GPSDO -- and your students should learn both (the hard way). > 3) When equipped with a timing receiver, having ADEV/MDEV at most 10x worse > than a Thunderbolt in the interval between 1s and 1d. Designing a 1/10th TBolt sounds fairly simple. It seems like your schematic is more complex than necessary to meet this requirement. Most of that goal is met with the choice of OCXO and choice of GPS board. > The primary phase detector is a TDC7200, which almost feels like cheating > after all the trouble I went through last time ( Wow. Why use a TDC7200? That's a 60 ps TIC and kind of overkill if your goal is a 1/10th TBolt. Plus, you have stolen from your students the opportunity for them to learn about making their own interpolating TIC, or why 1 ns resolution is more than sufficient for this GPSDO. I guess I'm confused if you're designing a high-end GPSDO, or a 1/10th TBolt GPSDO, or creating a student learning exercise. > 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 ). Based on your desired performance specs, what calculations did you make to conclude that this 16 + 24 bit scheme was required? > 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 As much as I'm a fan of core memory and FeRAM, I don't understand why you plan to update the EEPROM so often. How about just once a day? Or once any time the DAC changes by more than 10 or 100 units. This value is informed by the re-trace spec of your OCXO. After a power loss the OCXO will warm up again. From the first second your PLL will make massive and rapid changes to the DAC, so who cares what the saved DAC value was. You don't need the old value. You don't want the old value; that's what the PLL is for. > - 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? A GPSDO is a closed loop so this and many other long-term worries are silently solved by the PLL. > - how to properly do outlier removal in a mobile platform which may get > bumped (leading to OCXO jumps). My starting point looks like Be careful about that. Act like there are no outliers: every point is trying to tell you something. /tvb ----- Original Message ----- From: "Jan-Derk Bakker" <jdbakker@gmail.com> To: <time-nuts@febo.com> 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@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

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

I'd really like to have a look at the schematic, but trying to read it leads to some app requiring me to bare my machine's soul to an unknown app developer. Could plain .pdf be put somewhere not involving Google? Thanks don On 2017-06-26 14:17, William H. Fite wrote: > On Monday, June 26, 2017, Tom Van Baak <tvb@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@gmail.com <javascript:;>> >> To: <time-nuts@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@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@febo.com <javascript:;> >> To unsubscribe, go to https://www.febo.com/cgi-bin/ >> mailman/listinfo/time-nuts >> and follow the instructions there. >> -- Dr. Don Latham PO Box 404, Frenchtown, MT, 59834 VOX: 406-626-4304

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@gmail.com> wrote: > > On Monday, June 26, 2017, Tom Van Baak <tvb@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@gmail.com <javascript:;>> >> To: <time-nuts@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@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@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@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

d'oh never mind don On 2017-06-26 14:43, djl wrote: > I'd really like to have a look at the schematic, but trying to read it > leads to some app requiring me to bare my machine's soul to an unknown > app developer. Could plain .pdf be put somewhere not involving > Google? > Thanks > don > > On 2017-06-26 14:17, William H. Fite wrote: >> On Monday, June 26, 2017, Tom Van Baak <tvb@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@gmail.com <javascript:;>> >>> To: <time-nuts@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@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@febo.com <javascript:;> >>> To unsubscribe, go to https://www.febo.com/cgi-bin/ >>> mailman/listinfo/time-nuts >>> and follow the instructions there. >>> -- Dr. Don Latham PO Box 404, Frenchtown, MT, 59834 VOX: 406-626-4304

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@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@gmail.com > <javascript:;>> wrote: > > > > On Monday, June 26, 2017, Tom Van Baak <tvb@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@gmail.com <javascript:;> > <javascript:;>> > >> To: <time-nuts@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@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@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@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@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

On Mon, Jun 26, 2017 at 7:43 PM, Tom Van Baak <tvb@leapsecond.com> wrote: > Thanks for sharing this project with us, and including the schematic. > Thanks! In the past week we've built ten of these, and I've gotten started on the software. The EFC inner control loop works (using a 24-bit ADC to servo two 16-bit DACs), and I've gotten a simple FLL working (intended for frequency acquisition before handing over to the PLL). > > 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. > > Interesting application. My first thought is that your design will have to > pay much more attention to environmental issues than the typical homebrew > GPSDO: temperature, humidity, moisture, air flow, and oscillator > orientation and acceleration. At least you don't have to worry about poor > GPS coverage or changes in altitude! > Indeed. After a very unfortunate accident last year (boat flipped over, we spent an all-nighter in a hotel room refurbishing soaked electronics and a 1.5kWh LiFePO4 battery) we've put all electronics in boxes sealed to IP68. This does cut down on several of the environmentals you mention. Temperature is a big issue; we've seen 30+C swings in the electronics compartment in recent years. As for orientation and acceleration: we do monitor that on our custom data logger, but right now there's no way for the OCXO to access that data (let alone try to compensate for it). > > 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 > > Can you translate this into T&F units for us? What timing accuracy? What > frequency accuracy? What ADEV? Is there a low PN requirement? > Doppler shift amounts to ~100ppb. The receiver can handle start-of-transmission timing being off by almost a minute in the current code, as we're transmitting 6-second bursts at a 10% duty cycle and the students are doing brute-force acquisition on every burst ATM. (Not completely unreasonable, as the link is simplex from boat to shore, and the receive end can be argued not to be too (computing/electrical)-power limited). For any reasonable OCXO, even in undisciplined state, ADEV is dwarfed by this brute force acquisition plus the uncertainty of the propagation time between Tx and Rx. (From a timing perspective, that is; frequency drift should still fit the "1/10th of Doppler or better"-criterium) PN is potentially more interesting. As of this morning OFDM carrier spacing is 80Hz@868MHz, and we're using QPSK. That's not pushing the phase noise requirements too hard, but I expect that after some channel sounding experiments (scheduled for Any Day Now) they will want to go for longer OFDM symbols (and thus reduce carrier spacing). Plus I've seen them do some preliminary experiments with higher-order QAM, both of which will need tighter phase noise specs. (At the moment I've populated the boards with Taitien NA-2000 series OCXOs, with a specified max PN of -90dBc@1Hz. The PCB can also be fitted with Connor-Winfield DOC-series OCXOs, with a specified typical PN of -67dBc@1Hz. I expect this to make an interesting example, once the OFDM requirements get tightened up.) > 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 > > Those are all good topics for teaching. I worry that a pre-designed board > like yours saves the students from having to think or work. Perhaps they > could first try a James Miller analog GPSDO or a Nick Sayer simple digital > Arduino-based GPSDO to see how good they are. Note also that the art of > measuring a GPSDO is as complex as the art of designing a GPSDO -- and your > students should learn both (the hard way). > I hear you, I really do, but I only have them for a very limited amount of time (4 years on paper, 2.5 years effectively, at undergraduate level). There is so much I would like to put in the curriculum, but I'm training Electrical Engineers, not Time-Nuts (not even telecom engineers or metrologists). With the learning curve for general EE being as steep as it is (plus these days you want them proficient in analog, digital *and *embedded software) there's not a lot of room left. As far as I can tell, the FLL I have now is very similar to Nick Sayer's design. From there the students can go to a 1-bit flip-flop phase detector, and from there to the TDC. (In previous projects I have found that for more complex systems, like 3kW BLDC drivers, multiphase MPPT solar power converters and RF systems, it helps to give the students a 'development board' that they can get started on while developing their own 2.0, lest they run out of time to get their own 1.0 up and running. Not too dissimilar from the process used at several of the companies I've worked with in the past.) > > > The primary phase detector is a TDC7200, which almost feels like cheating > > after all the trouble I went through last time ( > > Wow. Why use a TDC7200? That's a 60 ps TIC and kind of overkill if your > goal is a 1/10th TBolt. Plus, you have stolen from your students the > opportunity for them to learn about making their own interpolating TIC, or > why 1 ns resolution is more than sufficient for this GPSDO. > > I guess I'm confused if you're designing a high-end GPSDO, or a 1/10th > TBolt GPSDO, or creating a student learning exercise. > All of the above, really. At the top level, we need to have a <2W frequency reference. That by itself could have been handled with a free-running (or perhaps hand-tuned) OCXO. One step deeper, I want to have my students play with various aspects including the difference between an FLL and a PLL. And, to be honest, beyond that *I* want to know first hand how much difference a 60ps TIC (+ a timing receiver) really makes. Partly because it makes me a better teacher, partly just because that mountain is there. (The second TDC channel also enables TICC-like experiments, for which there's also some demand. But that honestly is more of a happy coincidence than a design goal). > 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 > ). > > Based on your desired performance specs, what calculations did you make to > conclude that this 16 + 24 bit scheme was required? > >From memory (because my lab notes are still at work): a perfectly linear 16-bit DAC might just do the job for a good OCXO with a 1ppm tuning range. I want some margin for error, and I also want to be able to use XOs with wider tuning range (like the CW DOT range, with a 20ppm tuning range). This is one of the parts I got working over the weekend. The PID loop worked better (less noise) as a PI loop, with the time constant increasing the longer no EFC updates are requested. Right now the ADC is showing ~2.5uVRMS EFC voltage noise (for a CV range of 2.8V). I need to play a bit more to see how much of that is ADC noise (specced at 1.5uVRMS typical), and how much I can filter out either in the analog domain or in the control loop. > > 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 > > As much as I'm a fan of core memory and FeRAM, I don't understand why you > plan to update the EEPROM so often. How about just once a day? Or once any > time the DAC changes by more than 10 or 100 units. This value is informed > by the re-trace spec of your OCXO. > This is mostly me being overly cautious. For the trip to Monaco we are cheating a bit by adding a backup battery. Race regulations (in Monaco, and elsewhere) forbid such extra energy storage, even supercaps are not allowed. The system (including the OCXO) has to be powered off completely when hitting the emergency shutdown, and some of our drivers have the tendency to over-use that Big Red Button. Many such interruptions will last no more than a minute. I've seen EEPROM corruption on similar platforms if the time between writing and power-down is too short, hence the FeRAM + frequent writes. > After a power loss the OCXO will warm up again. From the first second your > PLL will make massive and rapid changes to the DAC, so who cares what the > saved DAC value was. You don't need the old value. You don't want the old > value; that's what the PLL is for. > ...why would I want to engage the PLL right after power on? I was planning to drive the old EFC value until either OCXO current or a time-out indicates the end of warm-up (and until the GPS is locked), then switch to FLL with increasing time constants for coarse lock, and only then enable the PLL. > > - 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? > > A GPSDO is a closed loop so this and many other long-term worries are > silently solved by the PLL. > Sure, but in a mobile platform (one that deliberately seeks the sun, too!) I am concerned that thermal changes happen faster than the longish loop time I'd want for a jittery GPS PPS. > - how to properly do outlier removal in a mobile platform which may get > > bumped (leading to OCXO jumps). My starting point looks like > > Be careful about that. Act like there are no outliers: every point is > trying to tell you something. > That was inspired by this thread: https://www.febo.com/pipermail/time-nuts/2006-December/022689.html (and several others like it). I am very interested in what the outliers are trying to tell me. Is it because the satellite combination used for a fix has changed? Is it because we're sailing from the open countryside into an urban canyon (or under a big steel bridge)? Thanks for your feedback, JDB. > ----- Original Message ----- > From: "Jan-Derk Bakker" <jdbakker@gmail.com> > To: <time-nuts@febo.com> > 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@febo.com > > To unsubscribe, go to https://www.febo.com/cgi-bin/m > ailman/listinfo/time-nuts > > and follow the instructions there. > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/m > ailman/listinfo/time-nuts > and follow the instructions there. >

On Mon, Jun 26, 2017 at 10:43 PM, djl <djl@montana.com> wrote: > I'd really like to have a look at the schematic, but trying to read it > leads to some app requiring me to bare my machine's soul to an unknown app > developer. Could plain .pdf be put somewhere not involving Google? > Save As... should hopefully fix that for now. My last Ubuntu upgrade killed my server's Apache installation (presumably over an incompatibility in the config files which I've not updated in the last decade). I hope to fix that this week, so I can give a more proper home to the design (+ some pictures + some logs). JDB.

		Attila Kinali

On Mon, 26 Jun 2017 10:43:24 -0700 "Tom Van Baak" <tvb@LeapSecond.com> wrote: > > 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 > > As much as I'm a fan of core memory and FeRAM, I don't understand why you > plan to update the EEPROM so often. How about just once a day? Or once any > time the DAC changes by more than 10 or 100 units. This value is informed by > the re-trace spec of your OCXO. If you are worried about the number of write cycles, that's not an issue with FeRAM/FRAM. Their spec'ed number of read/write cycles is in the order of 1e10 to 1e14. I.e. reading/writing the same cell every second would result in a lifetime somewhere between 300 and 3 million years. I am not sure I believe the latter number, but I wouldn't worry about wear-out of FeRAM/FRAM cells under normal conditions. The write cylces, speed, and power consumption of FeRAM/FRAM is so good that TI has been using it as SRAM replacement for the MSP430FR family of lowest power uC (think of years-of-runtine-from-a-tiny-coin-cell kind of low power). So, if continuously writing the EFC value to FeRAM simplifies the software flow, then this isn't a wrong thing to do. Attila Kinali PS: If you need a simple uC and non-volatile memory for a project, I'd rather use an MSP430FR instead of an AVR with some EEPROM/FeRAM chip. Makes things a lot simpler if you don't need to access an external chip but can just use an internal memory cell...beside the uC being 16bit instead of 8bit (makes software easier in general). -- You know, the very powerful and the very stupid have one thing in common. They don't alters their views to fit the facts, they alter the facts to fit the views, which can be uncomfortable if you happen to be one of the facts that needs altering. -- The Doctor