Re: [time-nuts] I've been thinking about a GPS receiver experiment
Living in south Florida I have been through 8 hurricanes and uncountable thunderstorms, while being a time-nut. At no time a hold over, because of excellent power backup. Once a controlled power shut down in Miami because I had to make a choice between window Air conditioner, refrigerators and coffee maker after 3 days. Lab lost out. Yes holdover when disconnecting antennas for lab work and modifications. Did in no way help. Ambient temperature a much bigger problem. In my humble opinion holdover is for commercial applications, it would be nice if we would spend more time discussing how to improve commercial products not intended for time-nuts application. Lot of room for improvement. Bert Kehren In a message dated 10/26/2017 5:23:39 P.M. Eastern Daylight Time, aph...@comcast.net writes: Terrific points. There are so many levels of sophistication. My own experience is with catastrophic signal loss on the reference. Determining degradation on your primary reference can present challenges. I once designed a device that compared three Cesiums and switched the reference within one cycle if the amplitude of the Cesium that was acting as the reference changed or the zero crossing (10 MHZ) was a few nanoseconds out of spec relative to the other two Cesiums. Nowadays they create ensembles of Cesiums and use them to steer their timing systems while the Cesiums are steered by GPS. Sophisticated Kalman filters are used to steer the signals based on the properties of the signal sources. The Microsemi 4145 Ultraclean Oscillator is designed for catastrophic signal loss and freezes the DAC that controls the BVA oscillator. This works well because even the DAC is ovenized. It will also go into holdover if the input reference drifts too quickly. It is pretty easy to make a simple temperature controlled box to house your temperature sensitive references. Just provide lots of insulation and control it at a temperature higher than your highest expected ambient. I never measured the temperature of oscillators and used the information to compensate holdover but it makes sense with a specific oscillator and enough run time to collect the data to categorize the oscillator for temperature and ageing. This is easier to accomplish when the DAC is is directly controlling the oscillator. Since I prefer analog control loops, it could also be done when the analog loop controls the oscillator if the DAC tracks the analog loop control voltage. A comparator compares the DAC output to the analog loop voltage. The DAC is adjusted to track and thereby characterized so that it can be set to the correct value when switched to holdover. As Bob pointed out this may or may not be the last value of the DAC depending on the mode of failure of the reference signal. As Bob points out, there are very sophisticated ways of doing temperature compensation today. As an example of his point, I was told that the Microsemi CSAC (chip-scale atomic clock) uses temperature compensation at many places in the design to achieve its performance specs. I imagine that is the current ultimate in temperature compensation for commercial products! Bob M On 10/26/2017 8:33 AM, Bob kb8tq wrote: > Hi > > Most GPSDO’s do some sort of “slew” to an average DAC value when they go into holdover. > Freezing at the last value is not (in general) a good idea. Often things degrade before there > is a dropout. Your final DAC value may not be a good one to maximize holdover duration. > > Some setups try to “learn” temperature or aging. That gets fed into the DAC when in holdover. > The value of this depends a lot on the quality of the training process. Separating this and that > input to get a good value for a specific parameter is rarely done with good accuracy. The exception > to that rule are oscillators that have a large TC or a very high drift rate. In most cases those are not > the ones you pick for a GPSDO. > > Bob > >> On Oct 25, 2017, at 7:46 PM, Bob Martinwrote: >> >> The holdover state is a DAC set to the last value of the analog control voltage that adjusts the oscillator frequency. Some designs >> use an analog control loop and switch the DAC into the control loop. >> Others use the DAC to set the control voltage at all times. This can result in a steps in the control voltage (output frequency). >> I've used both methods and prefer the latter. >> >> Bob M >> >> On 10/25/2017 5:30 PM, Mark Sims wrote: No, you set up an oscillator so that is why you have that problem. >>> I hooked the two rubidiums together just to see what would happen. It pretty much did what I expected... chaos... the time-nut equivalent of a naughty schoolboy putting a microphone up to the speaker of the public address system. I't's a tough job, but somebody gotta do it ;-) No, not really. The rubidium would be the real
[time-nuts] I've been thinking about a GPS receiver experiment
The Thunderbolt, Star-4, Trueposition, and HP GPSDOs/Smartclocks are all known to do this. Typically the learning period is around 24 hours before the compensation is allowed to run. My HP GPSDO seems to take a week for best performance. Separating tempco and aging drift seems to me to be a rather thorny problem to do well. --- > I never measured the temperature of oscillators and used the information to compensate holdover but it makes sense with a specific oscillator and enough run time to collect the data to categorize the oscillator for temperature and ageing. ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Terrific points. There are so many levels of sophistication. My own experience is with catastrophic signal loss on the reference. Determining degradation on your primary reference can present challenges. I once designed a device that compared three Cesiums and switched the reference within one cycle if the amplitude of the Cesium that was acting as the reference changed or the zero crossing (10 MHZ) was a few nanoseconds out of spec relative to the other two Cesiums. Nowadays they create ensembles of Cesiums and use them to steer their timing systems while the Cesiums are steered by GPS. Sophisticated Kalman filters are used to steer the signals based on the properties of the signal sources. The Microsemi 4145 Ultraclean Oscillator is designed for catastrophic signal loss and freezes the DAC that controls the BVA oscillator. This works well because even the DAC is ovenized. It will also go into holdover if the input reference drifts too quickly. It is pretty easy to make a simple temperature controlled box to house your temperature sensitive references. Just provide lots of insulation and control it at a temperature higher than your highest expected ambient. I never measured the temperature of oscillators and used the information to compensate holdover but it makes sense with a specific oscillator and enough run time to collect the data to categorize the oscillator for temperature and ageing. This is easier to accomplish when the DAC is is directly controlling the oscillator. Since I prefer analog control loops, it could also be done when the analog loop controls the oscillator if the DAC tracks the analog loop control voltage. A comparator compares the DAC output to the analog loop voltage. The DAC is adjusted to track and thereby characterized so that it can be set to the correct value when switched to holdover. As Bob pointed out this may or may not be the last value of the DAC depending on the mode of failure of the reference signal. As Bob points out, there are very sophisticated ways of doing temperature compensation today. As an example of his point, I was told that the Microsemi CSAC (chip-scale atomic clock) uses temperature compensation at many places in the design to achieve its performance specs. I imagine that is the current ultimate in temperature compensation for commercial products! Bob M On 10/26/2017 8:33 AM, Bob kb8tq wrote: Hi Most GPSDO’s do some sort of “slew” to an average DAC value when they go into holdover. Freezing at the last value is not (in general) a good idea. Often things degrade before there is a dropout. Your final DAC value may not be a good one to maximize holdover duration. Some setups try to “learn” temperature or aging. That gets fed into the DAC when in holdover. The value of this depends a lot on the quality of the training process. Separating this and that input to get a good value for a specific parameter is rarely done with good accuracy. The exception to that rule are oscillators that have a large TC or a very high drift rate. In most cases those are not the ones you pick for a GPSDO. Bob On Oct 25, 2017, at 7:46 PM, Bob Martinwrote: The holdover state is a DAC set to the last value of the analog control voltage that adjusts the oscillator frequency. Some designs use an analog control loop and switch the DAC into the control loop. Others use the DAC to set the control voltage at all times. This can result in a steps in the control voltage (output frequency). I've used both methods and prefer the latter. Bob M On 10/25/2017 5:30 PM, Mark Sims wrote: No, you set up an oscillator so that is why you have that problem. I hooked the two rubidiums together just to see what would happen. It pretty much did what I expected... chaos... the time-nut equivalent of a naughty schoolboy putting a microphone up to the speaker of the public address system. I't's a tough job, but somebody gotta do it ;-) No, not really. The rubidium would be the real hold-over clock. Symmetricom calls the disciplining state where it can't lock to the 1PPS signal the "holdover" state. It's sort of like a GPSDO holdover state. Their discipline firmware does let you set the time constant and damping values. I tried a little playing around with them, but never found any settings that worked consistently well with the LEA-5T. ___ 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. ___ 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. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Hi You get into all sorts of issues trying to estimate tempco. You have time lags and gradients that make it a very messy process. Toss in measurement based on small range temperature swings (like from a HVAC system) …. it’s a mess. If the OCXO is a typical modern part and it’s been on power for a couple of weeks, why bother? The delta is small and it may not be quite the same yesterday as it is today. Guessing it based on the sort of data you have is worse than guessing tempco. This all *assumes* you are chasing the aging and tempco of the OCXO. If your electronics contribute a lot of error (as some do), they may need the help. Bob > On Oct 26, 2017, at 1:28 PM, Mark Simswrote: > > Many years ago I tried to add some code to Lady Heather to calculate the > tempco and aging of the oscillator in a normally running Tbolt. Although > the equations would theoretically work (using SVD decomposition) it seldom > worked properly. Failure seemed to be caused by noise in the small numbers > involved. I wound up adding code that could do it by disabling disciplining > to get aging and varying the temperature to get tempco. > > -- > >> Separating this and that input to get a good value for a specific parameter >> is rarely done with good accuracy > ___ > 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. ___ 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.
[time-nuts] I've been thinking about a GPS receiver experiment
Many years ago I tried to add some code to Lady Heather to calculate the tempco and aging of the oscillator in a normally running Tbolt. Although the equations would theoretically work (using SVD decomposition) it seldom worked properly. Failure seemed to be caused by noise in the small numbers involved. I wound up adding code that could do it by disabling disciplining to get aging and varying the temperature to get tempco. -- > Separating this and that input to get a good value for a specific parameter > is rarely done with good accuracy ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Hi Most GPSDO’s do some sort of “slew” to an average DAC value when they go into holdover. Freezing at the last value is not (in general) a good idea. Often things degrade before there is a dropout. Your final DAC value may not be a good one to maximize holdover duration. Some setups try to “learn” temperature or aging. That gets fed into the DAC when in holdover. The value of this depends a lot on the quality of the training process. Separating this and that input to get a good value for a specific parameter is rarely done with good accuracy. The exception to that rule are oscillators that have a large TC or a very high drift rate. In most cases those are not the ones you pick for a GPSDO. Bob > On Oct 25, 2017, at 7:46 PM, Bob Martinwrote: > > The holdover state is a DAC set to the last value of the analog control > voltage that adjusts the oscillator frequency. Some designs > use an analog control loop and switch the DAC into the control loop. > Others use the DAC to set the control voltage at all times. This can result > in a steps in the control voltage (output frequency). > I've used both methods and prefer the latter. > > Bob M > > On 10/25/2017 5:30 PM, Mark Sims wrote: >>> No, you set up an oscillator so that is why you have that problem. >> I hooked the two rubidiums together just to see what would happen. It >> pretty much did what I expected... chaos... the time-nut equivalent of a >> naughty schoolboy putting a microphone up to the speaker of the public >> address system. I't's a tough job, but somebody gotta do it ;-) >>> No, not really. The rubidium would be the real hold-over clock. >> Symmetricom calls the disciplining state where it can't lock to the 1PPS >> signal the "holdover" state. It's sort of like a GPSDO holdover state. >> Their discipline firmware does let you set the time constant and damping >> values. I tried a little playing around with them, but never found any >> settings that worked consistently well with the LEA-5T. >> ___ >> 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. > ___ > 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. ___ 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.
[time-nuts] I've been thinking about a GPS receiver experiment
Well, the X72 uses a DDS instead of a DAC... not much different except you have no DAC to freq math to worry about. The DDS res is 60 MHz / 8192 - > I've been thinking about a GPS receiver experiment ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Sorry, my mistake, change that to the former! I have used DACs that were monotonic with decent results but prefer analog loops when the time constants are short enough. Bob M On 10/25/2017 5:46 PM, Bob Martin wrote: The holdover state is a DAC set to the last value of the analog control voltage that adjusts the oscillator frequency. Some designs use an analog control loop and switch the DAC into the control loop. Others use the DAC to set the control voltage at all times. This can result in a steps in the control voltage (output frequency). I've used both methods and prefer the latter. Bob M On 10/25/2017 5:30 PM, Mark Sims wrote: No, you set up an oscillator so that is why you have that problem. I hooked the two rubidiums together just to see what would happen. It pretty much did what I expected... chaos... the time-nut equivalent of a naughty schoolboy putting a microphone up to the speaker of the public address system. I't's a tough job, but somebody gotta do it ;-) No, not really. The rubidium would be the real hold-over clock. Symmetricom calls the disciplining state where it can't lock to the 1PPS signal the "holdover" state. It's sort of like a GPSDO holdover state. Their discipline firmware does let you set the time constant and damping values. I tried a little playing around with them, but never found any settings that worked consistently well with the LEA-5T. ___ 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. ___ 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. ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
The holdover state is a DAC set to the last value of the analog control voltage that adjusts the oscillator frequency. Some designs use an analog control loop and switch the DAC into the control loop. Others use the DAC to set the control voltage at all times. This can result in a steps in the control voltage (output frequency). I've used both methods and prefer the latter. Bob M On 10/25/2017 5:30 PM, Mark Sims wrote: No, you set up an oscillator so that is why you have that problem. I hooked the two rubidiums together just to see what would happen. It pretty much did what I expected... chaos... the time-nut equivalent of a naughty schoolboy putting a microphone up to the speaker of the public address system. I't's a tough job, but somebody gotta do it ;-) No, not really. The rubidium would be the real hold-over clock. Symmetricom calls the disciplining state where it can't lock to the 1PPS signal the "holdover" state. It's sort of like a GPSDO holdover state. Their discipline firmware does let you set the time constant and damping values. I tried a little playing around with them, but never found any settings that worked consistently well with the LEA-5T. ___ 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. ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
What "naughty schoolboy"? How else is one supposed to learn feedback theory? Dana On Wed, Oct 25, 2017 at 6:30 PM, Mark Simswrote: > > No, you set up an oscillator so that is why you have that problem. > > I hooked the two rubidiums together just to see what would happen. It > pretty much did what I expected... chaos... the time-nut equivalent of a > naughty schoolboy putting a microphone up to the speaker of the public > address system. I't's a tough job, but somebody gotta do it ;-) > > > > No, not really. The rubidium would be the real hold-over clock. > > Symmetricom calls the disciplining state where it can't lock to the 1PPS > signal the "holdover" state. It's sort of like a GPSDO holdover state. > Their discipline firmware does let you set the time constant and damping > values. I tried a little playing around with them, but never found any > settings that worked consistently well with the LEA-5T. > ___ > 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. > ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Hi naugthy schoolboy Mark, On 10/26/2017 01:30 AM, Mark Sims wrote: No, you set up an oscillator so that is why you have that problem. I hooked the two rubidiums together just to see what would happen. It pretty much did what I expected... chaos... the time-nut equivalent of a naughty schoolboy putting a microphone up to the speaker of the public address system. I't's a tough job, but somebody gotta do it ;-) In the music world, some really like caotic oscillators. You just built a very expensive one. :)0 No, not really. The rubidium would be the real hold-over clock. Symmetricom calls the disciplining state where it can't lock to the 1PPS signal the "holdover" state. It's sort of like a GPSDO holdover state. Their discipline firmware does let you set the time constant and damping values. I tried a little playing around with them, but never found any settings that worked consistently well with the LEA-5T. Well, holdover is the behavior, but a typical design can have several states which is deemed as hold-over. Everything else than tracking is holdover. Cheers, Magnus ___ 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.
[time-nuts] I've been thinking about a GPS receiver experiment
> No, you set up an oscillator so that is why you have that problem. I hooked the two rubidiums together just to see what would happen. It pretty much did what I expected... chaos... the time-nut equivalent of a naughty schoolboy putting a microphone up to the speaker of the public address system. I't's a tough job, but somebody gotta do it ;-) > No, not really. The rubidium would be the real hold-over clock. Symmetricom calls the disciplining state where it can't lock to the 1PPS signal the "holdover" state. It's sort of like a GPSDO holdover state. Their discipline firmware does let you set the time constant and damping values. I tried a little playing around with them, but never found any settings that worked consistently well with the LEA-5T. ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Hi Bob, Well, the PRC-10 actually have additional provisions to help it do well on GPS as signal, and is used by severals to do exactly that. Cheers, Magnus On 10/25/2017 09:26 PM, Bob kb8tq wrote: Hi Everybody I have ever talked to about the internal disciplining on Rb’s comes up with “it’s not for a GPSDO” somewhere in the first minute of the conversation. The objective seems to be to tune the unit to a perfect source to speed up the calibration process. The idea never appears to include noise on the reference signal or odd perturbations in the reference. Bob On Oct 24, 2017, at 6:42 PM, Mark Simswrote: I did a quick silly experiment where I took a PRS-10 disciplined by an X72 which was disciplined by the PRS-10. The result seemed to have created a rupture in the space-time continuum. Nobody was happy... they didn't seem to agree on who was in charge.I need to try it again now that I have my X72 interface boards back from China and can properly connect to the X72. BTW, the firmware based disciplining on the X72 seems to be rather crappy. It has lots of trouble locking to less than perfect 1PPS inputs. For instance it goes into holdover mode over half the time when driven by a Ublox LEA-5T (which seems to have like +/- 60 ns jitter on the 1PPS. It does lock fine with a Tbolt... but needing a GPSDO to discipline a rubidium sort of defeats the purpose of disciplining a rubidium. Lady Heather now has an X72/SA22 disciplining routine built in that works fairly well using the LEA-5T. Adevs are in the mid E-13 range at 10,000 seconds and the 1PPS output is in the +/- 50 ns range. ___ 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. ___ 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. ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Hei Ole Petter, You don't want to look at the PPS in that case. You want to look at how the receivers clock solution pans out. Since the receivers clock is set but then ticks to the speed of the rubidium, you now got a high resolution frequency and phase comparison. Depending on the clock-mode, you might or might not experience clock-reset events. Typically 1 ms shifts of clock time. One needs to handle that in case you are not able to drive the clock quick enough towards on average be where the GPS/UTC average solution drives it to. Anyway, so there is a different clock message, just don't recall it from the top of my head. I just recall that the Novatels is fairly generous with this data Cheers, Magnus On 10/25/2017 06:14 AM, Ole Petter Ronningen wrote: I did log the #TIME message for several weeks on an OEMV-3 a while back. The results were a bit suspicious, so I checked with Novatel support - turns out the PPS on the OEMV (and I presume that also holds for OEM4) is derived from L1 only - and the jitter is nothing to brag about. So for disciplining with PPS, something like a UBlox would be better as far as I can tell. The other option is to log the #RANGE-message from the Novatel, convert to RINEX and solve with PPP, and use the output of that to adjust the rubidium. The added benefit is that you'll have an excellent log of what your reference is doing if you get odd results in some measurements. Ole On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson <mag...@rubidium.dyndns.org <mailto:mag...@rubidium.dyndns.org>> wrote: Skip, I would rather use the rich Novatel reports and read out the time error and use that as your phase detector, then the normal PI-loop stuff with an optional low-pass to add and then use that to steer the rubidium. It's one of those, when I get time, projects. Cheers, Magnus On 10/25/2017 12:17 AM, Skip Withrow wrote: Hello time-nuts, I've been thinking about a GPS receiver experiment and just wondering if there are any opinions or prior experience that might save me a lot of time. What I have been thinking about doing is taking a GPS receiver (Novatel OEM4-G2) that has provisions for an external clock (5 or 10 MHz) and driving it with a rubidium oscillator (that has 1pps disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has settings for OCXO/rubidium/cesium dynamics. Then, (and here is the unknown part) what if the GPS receiver 1pps is used to discipline the rubidium? This basically forms a feedback loop, so could either hurt or help - depending. Supposedly the better oscillator would give a better GPS solution. And the better solution (1pps) should provide a better oscillator frequency. We know that GPS receivers using asynchronous clocks have 1pps errors and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is on 10MHz and disciplined will the 1pps error be reduced such as the Thunderbolt? Comments appreciated. Regards, Skip Withrow ___ time-nuts mailing list -- time-nuts@febo.com <mailto:time-nuts@febo.com> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts <https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts> and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com <mailto:time-nuts@febo.com> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts <https://www.febo.com/cgi-bin/mailman/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/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Hi Mark, On 10/25/2017 12:42 AM, Mark Sims wrote: I did a quick silly experiment where I took a PRS-10 disciplined by an X72 which was disciplined by the PRS-10. The result seemed to have created a rupture in the space-time continuum. Nobody was happy... they didn't seem to agree on who was in charge.I need to try it again now that I have my X72 interface boards back from China and can properly connect to the X72. No, you set up an oscillator so that is why you have that problem. Each rubidium has an integrator and each PI loop adds another, and now that you wire the feedback over them you have an unbalanced 4 pole system. Already a third degree system is somewhat of a challenge to keep stable, so fourth degree... sure, it can be done, but not that way. I have been looking at mutual synchronization and there is some classical articles on it and recently some work have been done too. A good mutual synchronization means that you find your aggregate clock to be at the middle frequency and phase of the two separate clocks. This also means that you want to drive your clocks towards each other, so one is to raise frequency and the other lower frequenncy. For un-equal clock EFCs, you need to scale the driving force accordingly. For more fancy setups of weighted clocks, you need to apply correct weights so that the better clock moves less than the clock being worse. Another factor of the control is that delay needs to be compensated for, and this have already been analyzed in the classical mutual clock setup, but also exists in modern setups, and I happen to touch on that subject in an article, since the delay margin, which is just a different version of phase margin, needs to be adapted in accordance with the control loop bandwidth. With the right key-words you can find out more. I did that work on automatic power-grid stabilization and it was kind of interesting to forge an analysis out of three independent research-fields, so I found myself instructing a PhD student how she would drive here simulations into self-oscillation... and they sure did and we learned stuff. Ah well. Anyway, mutual synchronization require some thought, but ends up not being all that different in the end. BTW, the firmware based disciplining on the X72 seems to be rather crappy. It has lots of trouble locking to less than perfect 1PPS inputs. For instance it goes into holdover mode over half the time when driven by a Ublox LEA-5T (which seems to have like +/- 60 ns jitter on the 1PPS. It does lock fine with a Tbolt... but needing a GPSDO to discipline a rubidium sort of defeats the purpose of disciplining a rubidium. No, not really. The rubidium would be the real hold-over clock. Lady Heather now has an X72/SA22 disciplining routine built in that works fairly well using the LEA-5T. Adevs are in the mid E-13 range at 10,000 seconds and the 1PPS output is in the +/- 50 ns range. Cool. Cheers, Magnusu ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Hi Everybody I have ever talked to about the internal disciplining on Rb’s comes up with “it’s not for a GPSDO” somewhere in the first minute of the conversation. The objective seems to be to tune the unit to a perfect source to speed up the calibration process. The idea never appears to include noise on the reference signal or odd perturbations in the reference. Bob > On Oct 24, 2017, at 6:42 PM, Mark Simswrote: > > I did a quick silly experiment where I took a PRS-10 disciplined by an X72 > which was disciplined by the PRS-10. The result seemed to have created a > rupture in the space-time continuum. Nobody was happy... they didn't seem > to agree on who was in charge.I need to try it again now that I have my > X72 interface boards back from China and can properly connect to the X72. > > BTW, the firmware based disciplining on the X72 seems to be rather crappy. > It has lots of trouble locking to less than perfect 1PPS inputs. For > instance it goes into holdover mode over half the time when driven by a Ublox > LEA-5T (which seems to have like +/- 60 ns jitter on the 1PPS. It does lock > fine with a Tbolt... but needing a GPSDO to discipline a rubidium sort of > defeats the purpose of disciplining a rubidium. > > Lady Heather now has an X72/SA22 disciplining routine built in that works > fairly well using the LEA-5T. Adevs are in the mid E-13 range at 10,000 > seconds and the 1PPS output is in the +/- 50 ns range. > ___ > 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. ___ 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.
[time-nuts] I've been thinking about a GPS receiver experiment
I did a quick silly experiment where I took a PRS-10 disciplined by an X72 which was disciplined by the PRS-10. The result seemed to have created a rupture in the space-time continuum. Nobody was happy... they didn't seem to agree on who was in charge.I need to try it again now that I have my X72 interface boards back from China and can properly connect to the X72. BTW, the firmware based disciplining on the X72 seems to be rather crappy. It has lots of trouble locking to less than perfect 1PPS inputs. For instance it goes into holdover mode over half the time when driven by a Ublox LEA-5T (which seems to have like +/- 60 ns jitter on the 1PPS. It does lock fine with a Tbolt... but needing a GPSDO to discipline a rubidium sort of defeats the purpose of disciplining a rubidium. Lady Heather now has an X72/SA22 disciplining routine built in that works fairly well using the LEA-5T. Adevs are in the mid E-13 range at 10,000 seconds and the 1PPS output is in the +/- 50 ns range. ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Hi Since you are doing a loop design that involves “months long” data runs, having good logging and monitoring is a key part of the process. Without the testing side of the process you are pretty much guaranteed to go astray in one way or the other. That’s not to say you have to have a giant lab full of millions of dollars of gear. You will need something to compare to and good logs of what goes in, what comes out, and as much of the intermediates as you can stand to look at. Bob > On Oct 25, 2017, at 12:14 AM, Ole Petter Ronningen <opronnin...@gmail.com> > wrote: > > I did log the #TIME message for several weeks on an OEMV-3 a while back. > The results were a bit suspicious, so I checked with Novatel support - > turns out the PPS on the OEMV (and I presume that also holds for OEM4) is > derived from L1 only - and the jitter is nothing to brag about. So for > disciplining with PPS, something like a UBlox would be better as far as I > can tell. > > The other option is to log the #RANGE-message from the Novatel, convert to > RINEX and solve with PPP, and use the output of that to adjust the > rubidium. The added benefit is that you'll have an excellent log of what > your reference is doing if you get odd results in some measurements. > > Ole > > On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson < > mag...@rubidium.dyndns.org> wrote: > >> Skip, >> >> I would rather use the rich Novatel reports and read out the time error >> and use that as your phase detector, then the normal PI-loop stuff with an >> optional low-pass to add and then use that to steer the rubidium. >> >> It's one of those, when I get time, projects. >> >> Cheers, >> Magnus >> >> >> On 10/25/2017 12:17 AM, Skip Withrow wrote: >> >>> Hello time-nuts, >>> >>> I've been thinking about a GPS receiver experiment and just wondering >>> if there are any opinions or prior experience that might save me a lot >>> of time. >>> >>> What I have been thinking about doing is taking a GPS receiver >>> (Novatel OEM4-G2) that has provisions for an external clock (5 or 10 >>> MHz) and driving it with a rubidium oscillator (that has 1pps >>> disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has >>> settings for OCXO/rubidium/cesium dynamics. >>> >>> Then, (and here is the unknown part) what if the GPS receiver 1pps is >>> used to discipline the rubidium? This basically forms a feedback >>> loop, so could either hurt or help - depending. Supposedly the better >>> oscillator would give a better GPS solution. And the better solution >>> (1pps) should provide a better oscillator frequency. >>> >>> We know that GPS receivers using asynchronous clocks have 1pps errors >>> and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is >>> on 10MHz and disciplined will the 1pps error be reduced such as the >>> Thunderbolt? >>> >>> Comments appreciated. >>> >>> Regards, >>> Skip Withrow >>> ___ >>> 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. >> > ___ > 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. ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
I did log the #TIME message for several weeks on an OEMV-3 a while back. The results were a bit suspicious, so I checked with Novatel support - turns out the PPS on the OEMV (and I presume that also holds for OEM4) is derived from L1 only - and the jitter is nothing to brag about. So for disciplining with PPS, something like a UBlox would be better as far as I can tell. The other option is to log the #RANGE-message from the Novatel, convert to RINEX and solve with PPP, and use the output of that to adjust the rubidium. The added benefit is that you'll have an excellent log of what your reference is doing if you get odd results in some measurements. Ole On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson < mag...@rubidium.dyndns.org> wrote: > Skip, > > I would rather use the rich Novatel reports and read out the time error > and use that as your phase detector, then the normal PI-loop stuff with an > optional low-pass to add and then use that to steer the rubidium. > > It's one of those, when I get time, projects. > > Cheers, > Magnus > > > On 10/25/2017 12:17 AM, Skip Withrow wrote: > >> Hello time-nuts, >> >> I've been thinking about a GPS receiver experiment and just wondering >> if there are any opinions or prior experience that might save me a lot >> of time. >> >> What I have been thinking about doing is taking a GPS receiver >> (Novatel OEM4-G2) that has provisions for an external clock (5 or 10 >> MHz) and driving it with a rubidium oscillator (that has 1pps >> disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has >> settings for OCXO/rubidium/cesium dynamics. >> >> Then, (and here is the unknown part) what if the GPS receiver 1pps is >> used to discipline the rubidium? This basically forms a feedback >> loop, so could either hurt or help - depending. Supposedly the better >> oscillator would give a better GPS solution. And the better solution >> (1pps) should provide a better oscillator frequency. >> >> We know that GPS receivers using asynchronous clocks have 1pps errors >> and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is >> on 10MHz and disciplined will the 1pps error be reduced such as the >> Thunderbolt? >> >> Comments appreciated. >> >> Regards, >> Skip Withrow >> ___ >> 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. > ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Hi The “best” approach would be to use a receiver that reports what’s going on to some pretty good resolution (say picoseconds). You also measure the pps offset (say to picoseconds). Then you feed *both* numbers into a software loop. Since you are after a loop with a “many days” sort of response, you have *lots* of time to do the math. Updates every minute are probably overkill. Since the math can take a long time, the CPU requirements aren’t very crazy. Equally, you can use a PC and get the job done. OS overhead likely isn’t going to be a big deal. You can separate out the math and run it at a pretty high level. Tweaking this or that would all be done in a high level language. No need for going crazy with assembler The loop is likely to be a “step and wait” sort of thing. There will be a bit of tweaking. Doing that in something easy to use *is* an advantage. Having it buried in some mystery firmware written by who knows who is not a good thing in this case. Bob > On Oct 24, 2017, at 7:09 PM, Dana Whitlow <k8yumdoo...@gmail.com> wrote: > > Hello Skip, > > I have a theory, but it will be interesting to see what others say. > Assuming that the > 1 PPS error to which you refer is the so-called "sawtooth" error, I've come > to suspect > that the rate at which the individual PPS pulses walk across the sawtooth > is related to, > and likely proportional to, the error of the internal (or in this case, the > external) clock > oscillator. If I'm right about its being proportional, then it seems to me > that having > the GPS's clock oscillator right on would freeze the PPS error at some > fixed value, > not necessarily zero. If true, you'd experience a constant bias error to > the timing of > the PPS pulses. > > Now you would seem to be in the perfect position to refute or verify my > thinking, > provided you have the means to vary an external clock's frequency in a > controlled > way, by watching how the PPS error behavior changes as a function of the > clock > frequency. > > If you manage to try the experiment, I'd greatly appreciate hearing the > outcome. > > Dana K8YUM > > > On Tue, Oct 24, 2017 at 5:17 PM, Skip Withrow <skip.with...@gmail.com> > wrote: > >> Hello time-nuts, >> >> I've been thinking about a GPS receiver experiment and just wondering >> if there are any opinions or prior experience that might save me a lot >> of time. >> >> What I have been thinking about doing is taking a GPS receiver >> (Novatel OEM4-G2) that has provisions for an external clock (5 or 10 >> MHz) and driving it with a rubidium oscillator (that has 1pps >> disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has >> settings for OCXO/rubidium/cesium dynamics. >> >> Then, (and here is the unknown part) what if the GPS receiver 1pps is >> used to discipline the rubidium? This basically forms a feedback >> loop, so could either hurt or help - depending. Supposedly the better >> oscillator would give a better GPS solution. And the better solution >> (1pps) should provide a better oscillator frequency. >> >> We know that GPS receivers using asynchronous clocks have 1pps errors >> and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is >> on 10MHz and disciplined will the 1pps error be reduced such as the >> Thunderbolt? >> >> Comments appreciated. >> >> Regards, >> Skip Withrow >> ___ >> 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. >> > ___ > 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. ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Hello Skip, I have a theory, but it will be interesting to see what others say. Assuming that the 1 PPS error to which you refer is the so-called "sawtooth" error, I've come to suspect that the rate at which the individual PPS pulses walk across the sawtooth is related to, and likely proportional to, the error of the internal (or in this case, the external) clock oscillator. If I'm right about its being proportional, then it seems to me that having the GPS's clock oscillator right on would freeze the PPS error at some fixed value, not necessarily zero. If true, you'd experience a constant bias error to the timing of the PPS pulses. Now you would seem to be in the perfect position to refute or verify my thinking, provided you have the means to vary an external clock's frequency in a controlled way, by watching how the PPS error behavior changes as a function of the clock frequency. If you manage to try the experiment, I'd greatly appreciate hearing the outcome. DanaK8YUM On Tue, Oct 24, 2017 at 5:17 PM, Skip Withrow <skip.with...@gmail.com> wrote: > Hello time-nuts, > > I've been thinking about a GPS receiver experiment and just wondering > if there are any opinions or prior experience that might save me a lot > of time. > > What I have been thinking about doing is taking a GPS receiver > (Novatel OEM4-G2) that has provisions for an external clock (5 or 10 > MHz) and driving it with a rubidium oscillator (that has 1pps > disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has > settings for OCXO/rubidium/cesium dynamics. > > Then, (and here is the unknown part) what if the GPS receiver 1pps is > used to discipline the rubidium? This basically forms a feedback > loop, so could either hurt or help - depending. Supposedly the better > oscillator would give a better GPS solution. And the better solution > (1pps) should provide a better oscillator frequency. > > We know that GPS receivers using asynchronous clocks have 1pps errors > and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is > on 10MHz and disciplined will the 1pps error be reduced such as the > Thunderbolt? > > Comments appreciated. > > Regards, > Skip Withrow > ___ > 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. > ___ 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.
Re: [time-nuts] I've been thinking about a GPS receiver experiment
Skip, I would rather use the rich Novatel reports and read out the time error and use that as your phase detector, then the normal PI-loop stuff with an optional low-pass to add and then use that to steer the rubidium. It's one of those, when I get time, projects. Cheers, Magnus On 10/25/2017 12:17 AM, Skip Withrow wrote: Hello time-nuts, I've been thinking about a GPS receiver experiment and just wondering if there are any opinions or prior experience that might save me a lot of time. What I have been thinking about doing is taking a GPS receiver (Novatel OEM4-G2) that has provisions for an external clock (5 or 10 MHz) and driving it with a rubidium oscillator (that has 1pps disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has settings for OCXO/rubidium/cesium dynamics. Then, (and here is the unknown part) what if the GPS receiver 1pps is used to discipline the rubidium? This basically forms a feedback loop, so could either hurt or help - depending. Supposedly the better oscillator would give a better GPS solution. And the better solution (1pps) should provide a better oscillator frequency. We know that GPS receivers using asynchronous clocks have 1pps errors and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is on 10MHz and disciplined will the 1pps error be reduced such as the Thunderbolt? Comments appreciated. Regards, Skip Withrow ___ 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. ___ 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.
[time-nuts] I've been thinking about a GPS receiver experiment
Hello time-nuts, I've been thinking about a GPS receiver experiment and just wondering if there are any opinions or prior experience that might save me a lot of time. What I have been thinking about doing is taking a GPS receiver (Novatel OEM4-G2) that has provisions for an external clock (5 or 10 MHz) and driving it with a rubidium oscillator (that has 1pps disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has settings for OCXO/rubidium/cesium dynamics. Then, (and here is the unknown part) what if the GPS receiver 1pps is used to discipline the rubidium? This basically forms a feedback loop, so could either hurt or help - depending. Supposedly the better oscillator would give a better GPS solution. And the better solution (1pps) should provide a better oscillator frequency. We know that GPS receivers using asynchronous clocks have 1pps errors and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is on 10MHz and disciplined will the 1pps error be reduced such as the Thunderbolt? Comments appreciated. Regards, Skip Withrow ___ 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.