Re: [time-nuts] Software Sawtooth correction prerequisites?
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY On Aug 1, 2007, at 0:51, Dr Bruce Griffiths wrote: Henk There is no theory to show that sigma delta modulators of order higher than 2 are actually unconditionally stable. Yes, but with the Gerzon-Craven theory is is possible to predict stability of noise shapers. My experience with Gerzon-Craven in a number of noise shapers is very good, and upto 11th order (never tried more). Merely simulating the device is not conclusive proof that the modulator will never saturate, albeit infrequently. Most implementations include saturation detection circuitry that resets the modulator should this occur. We use feed-forward and graceful degradation. In this way saturated noise shapers recover correct. In our application overdriven noise shapers can not be avoided at input signal transients. If saturation isn't too frequent then for most purposes this is only a minor annoyance. However cascaded first order modulators as employed in the MASH technique are stable in theory and practice. How to match analog circuits with digital circuits for the mash, that is the question. How do you avoid leakage? However if one adopts a non linear control theory approach, one can actually design high order modulators that both stable in theory and in practice. Unconditionally? Do you have a link for me? Henk ___ 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] Software Sawtooth correction prerequisites?
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY Henk ten Pierick wrote: However if one adopts a non linear control theory approach, one can actually design high order modulators that both stable in theory and in practice. Unconditionally? Do you have a link for me? Henk Henk Try: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/9861/31519/01470725.pdf?arnumber=1470725 http://txspace.tamu.edu/bitstream/1969.1/3768/1/etd-tamu-2005A-ELEN-He.pdf Bruce ___ 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] Software Sawtooth correction prerequisites?
); SAEximRunCond expanded to false
Errors-To: [EMAIL PROTECTED] RETRY
On Jul 24, 2007, at 1:32, Dr Bruce Griffiths wrote:
Perhaps a software implementation of a 1 bit oversampled DAC the 1 bit
output of which is low pass filtered to control the EFC input is the
closest approach to this ideal.
With an appropriate algorithm the idle tone and inherent instability
problems (of high order modulators - 3rd or higher order) of the sigma
delta modulator will not occur.
It is easy to design stable sigma delta converters of orders higher
than two. I have calculated a 7th order ADC which is implemented on
silicon and stable of coarse. A 11th order sigma delta with
oversampling ratio 128 is stable in simulation and has 228dB snr.
{This is no typo two hundred and twenty eight dB)
Higher order sigma delta converter require higher order
reconstruction filters but it is easy to design for more bandwidth
than needed and so to relax the filter spec.
Henk
___
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] Software Sawtooth correction prerequisites?
); SAEximRunCond expanded to false
Errors-To: [EMAIL PROTECTED] RETRY
Henk ten Pierick wrote:
On Jul 24, 2007, at 1:32, Dr Bruce Griffiths wrote:
Perhaps a software implementation of a 1 bit oversampled DAC the 1 bit
output of which is low pass filtered to control the EFC input is the
closest approach to this ideal.
With an appropriate algorithm the idle tone and inherent instability
problems (of high order modulators - 3rd or higher order) of the sigma
delta modulator will not occur.
It is easy to design stable sigma delta converters of orders higher
than two. I have calculated a 7th order ADC which is implemented on
silicon and stable of coarse. A 11th order sigma delta with
oversampling ratio 128 is stable in simulation and has 228dB snr.
{This is no typo two hundred and twenty eight dB)
Higher order sigma delta converter require higher order
reconstruction filters but it is easy to design for more bandwidth
than needed and so to relax the filter spec.
Henk
Henk
There is no theory to show that sigma delta modulators of order higher
than 2 are actually unconditionally stable.
Merely simulating the device is not conclusive proof that the modulator
will never saturate, albeit infrequently.
Most implementations include saturation detection circuitry that resets
the modulator should this occur.
If saturation isn't too frequent then for most purposes this is only a
minor annoyance.
However cascaded first order modulators as employed in the MASH
technique are stable in theory and practice.
However if one adopts a non linear control theory approach, one can
actually design high order modulators that both stable in theory and in
practice.
The resulting circuit isn't a sigma delta modulator, however it has
similar noise shaping characteristics.
Bruce
___
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] Software Sawtooth correction prerequisites?
Tom Van Baak wrote: This sure sounds like a more complicated measurement than is necessary to me. If you have a 10 MHz oscillator, simply feed it into the D input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of the latch is a 0 or 1 depending on the precise phase of the oscillator. You want this latched 0/1 measurement to average to ½ over a long term (seconds). As the statistics deviate from a 50/50 split, you tweak the oscillator. The ~1 nsec of residual noise from the sawtooth corrected GPS rcvr acts a natural dither. No counters, no ramps, no big A/D converter -- it couldn't be simpler! And if the 10MHz (= 100 nsec phase ambiguity) is too fine for your oscillator, then divide it to 5 MHz (=200 nsec) or 1 MHz (= 1µsec). This should be good enough to pull in a xtal that is off by 1:10e6. This sounds really simple and irresistible. Have you or Rick tried it out? I see instead of a TIC (Time Interval Counter) you have a TAC (Time Average Controller ;-) Not just GPS 1PPS noise but any oscillator noise (jitter), if large enough, is also a source of natural dither. Sounds like this design would be especially ideal for a low-end GPSDO; i.e., one that only needs to be accurate to 10^-9 or 10^-10. Did you envision that the OCXO EFC would be driven by a statistics-collecting microprocessor and a high-resolution DAC? Or is there some clever way to tie statistical results of the D-latch to the EFC and avoid the DAC too? /tvb Tom Perhaps a software implementation of a 1 bit oversampled DAC the 1 bit output of which is low pass filtered to control the EFC input is the closest approach to this ideal. With an appropriate algorithm the idle tone and inherent instability problems (of high order modulators - 3rd or higher order) of the sigma delta modulator will not occur. An oversampling ratio of 1000 - 1 should readily be possible together with a resolution of 24 bits or more with low gain and offset tempcos together with a monotonic transfer function. A low integral non linearity isn't necessary as the EFC control input transfer function typically isnt that linear. Relaxing the integral linearity spec simplifies the design considerably. A 1 bit output also simplifies isolation (either optical or chip scale transformer isolation??) of the DAC from the processor should this be required. Bruce ___ 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] Software Sawtooth correction prerequisites?
Just to clarify, credit for the clever D-latch idea goes to a posting by the other Tom (Dr Tom Clark), not me. Tom Clark, K3IO wrote (on May 11, 2007): This sure sounds like a more complicated measurement than is necessary to me. If you have a 10 MHz oscillator, simply feed it into the D input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of the latch is a 0 or 1 depending on the precise phase of the oscillator. You want this latched 0/1 measurement to average to ½ over a long term (seconds). As the statistics deviate from a 50/50 split, you tweak the oscillator. The ~1 nsec of residual noise from the sawtooth corrected GPS rcvr acts a natural dither. No counters, no ramps, no big A/D converter -- it couldn't be simpler! And if the 10MHz (= 100 nsec phase ambiguity) is too fine for your oscillator, then divide it to 5 MHz (=200 nsec) or 1 MHz (= 1µsec). This should be good enough to pull in a xtal that is off by 1:10e6. Tom Van Baak (tvb) replied: This sounds really simple and irresistible. Have you or Rick tried it out? I see instead of a TIC (Time Interval Counter) you have a TAC (Time Average Controller ;-) Not just GPS 1PPS noise but any oscillator noise (jitter), if large enough, is also a source of natural dither. Sounds like this design would be especially ideal for a low-end GPSDO; i.e., one that only needs to be accurate to 10^-9 or 10^-10. Did you envision that the OCXO EFC would be driven by a statistics-collecting microprocessor and a high-resolution DAC? Or is there some clever way to tie statistical results of the D-latch to the EFC and avoid the DAC too? /tvb ___ 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] Software Sawtooth correction prerequisites?
Tom Van Baak wrote: Define cheap. You can already get essentially single chip TICs with a resolution (and accuracy) better than 100ps for around 100 Euros or so. Has anyone in the group tried one of these? I would very much like to see the results. All except Xavier seem to have shied away from obtaining these on cost grounds and the need to layout a 4 layer PCB. Although the vendor does offer an evaluation system (External box plus card plugs into PC with fat multiconductor SCSI type (but not SCSI signalling)cable connecting the two), too expensive for general use but perhaps useful for performance evaluation. The above price was for an earlier version the later reduced cost higher resolution version (range 5 nanosec - 4millisec) should be cheaper. The range can easily be extended to years if required (using CPLD counters (or even a PIC with built in counters - eg PIC18F4550) + software+ 74AC164). However the optimal solution doesn't use a TIC at all, just use a good GPS receiver that makes the carrier phase observables available. Quite a few of the older receivers used to make the carrier phase data available. Many of the Oncore VP's did this, but I don't know of anyone, amateur or commercial, that built a GPSDO using that feature. That makes me wonder if carrier phase observables alone is not enough. You also need code phase measurements as a sanity check, to determine the ionospheric delay, and to initialise the control loop. To obtain maximum performance you also need to know the GPS antenna location accurately. This may take several days to establish using code phase SV transit data. The catch is that the GPS receiver local oscillator must be phase locked to the OCXO. Some receivers use a 10MHz crystal oscillator in which case this can be removed and replaced with an external 10MHz signal derived from the OCXO being disciplined. Right, this is the key. Do you know any OEM receivers that allow an external 5/10/20 MHz? I know my Z12T does (but that is far from an OEM receiver). The Novatel SuperstarII receivers use an on board Rakon 10MHz TCXO (made a little (120km) to the North of me) local oscillator which can be disconnected with relatively little surgery and replaced with a piece of thin coax and a connector. However the required amplitude is relatively small - easily fixed with a pair of resistors - typically the output from the onboard TCXO itself has to be attenuated. Magnus acquired some of these cheaply, however even the new price isn't too steep. UNSW has used these receivers in geodetic survey/monitoring applications. The code phase field data from some of these exhibits encouraging stability (about 5 -10x better than the oscillator specs) when averaged over a few seconds even with the standard TCXO. If you want to roll your own GPS receiver the MITEL/ZARLINK chipsets use a 10MHz reference. Unfortunately there are as yet no relatively inexpensive off the shelf implementations of the GPS carrier phase discipling technique available. The calculations involved for maximum performance are somewhat complex, however not too much computing horsepower should be required. The QL carrier phase GPSDO is unique and probably not cost-effective. Sounds like it's a custom single-channel GPS receiver designed from the ground up. If there were an easier way surely someone would have done it in the past ten years. Yes $30,000 Euros or so is a little steep. Depends what you mean by easy. Vested interest in an existing receiver can lead to inertia. The other players seem wedded to using PPS disciplining, possibly because of all the existing equipment using it. Investigations into using multichannel carrier phase disciplining have been somewhat sporadic. Although single channel receivers employing carrier phase measurement have been successfully deployed in geodetic arrays for monitoring applications. Magnus hopes to remedy this lack of suitable software and hardware sometime in the future. That would be very nice. Will it be L1 only or L1/L2? Only L1 as that's all the Superstar receivers provide. However combining carrier and code phase measurements allows correction for the ionospheric delay. /tvb Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Bruce Griffiths wrote: The Dallas delay lines aren't all that accurate, you need to calibrate them to acheive 1ns accuracy (read the specs) and then you have to worry about temperature variations. To use them you need to decode the sawtooth correction message from the GPS timing receiver. If you've decoded this message then you have all the information needed to make a software correction to the measured phase error. I need to correct some impressions that seem to have gone astray. To help me, I refer you to a PowerPoint presentation that I gave to the technicians and operators at the world's VLBI (Very Long Baseline Interferometry) sites. The presentation is available at http://gpstime.com as the 2007 version of Timing for VLBI. [Aside -- If you are interested in learning about some of VLBI's buzz-words, I also gave a tutorial What's all this VLBI stuff, anyway? that was intended as a view of the Physics and Radio Astronomy of making VLBI measurements. Some people find my de-mystifying of Heisenberg's Uncertainty Principle interesting -- especially the Schroedinger quotes at #21. This plays best if you view it as a PPT presentation.] Starting on Slide #20, I describe the reason that the Motorola receivers have the sawtooth dither. Basically clock edges of the receiver's 1PPS pulse are locked to a crystal oscillator in the receiver and that oscillator is on a frequency that is not neatly commensurate with the true second marks. As has been pointed out in these discussions, Motorola reports an estimate of the error on the NEXT 1PPS tick. Slides 21 and 22 show some of the pathological example we have seen on typical receivers. AFAIK, all the bizarre behavior has been traced to firmware problems. The reason for making sawtooth corrections (and not simply averaging multiple samples) can be seen in the hanging bridges (22:34 to 22:36 on #22, 01:04:30 to 01:05:30 on #23) when the 1PPS signal went thru a zero-beat. For these 1-2 minute windows, all statistical averaging breaks down and typical GPSDO's perform badly. However, when the sawtooth is corrected in software (blue line on #23) the resulting paper clock is well behaved (at ~1.5 nsec RMS level). Slides #24 #25 describe an annoying problem in VLBI -- we want to be able to blindly trust ANY 1PPS pulse whenever (rarely) we need to reset the working VLBI clock. Slide #26 is the block diagram of the circuit that Rick has implemented in his newest clock. Slide #29 shows a (more noisy than normal) comparison between the hardware ans software correction performance with only 0.3 nsec RMS noise between the two. Bruce noted a misconception that may have come from our earlier implementation of the correction algorithm. What we found was that EVERY sample of the 1 nsec step Dallas/Maxim delay line showed considerably more scatter.What we found, on closer examination, was that it seems that the DSI delay line chip defines one nsec about 10% differently than Motorola's one nsec. After correcting for this definition problem, as you see in #30, the hardware and software correction are in agreement with an observed regression coefficient of 0.9962 (on this sample, which shows correlation coefficient 0.999) and good tracking between samples. Bruce also made some disparaging comments on the stability of the delay lone. I can say that we have not seen any stability problems at all. This is quite logical when you carefully reverse engineer the DSI chip based on its data sheets. The delay inside the chip is really an analog delay. The 8-bit number you sent to the chip programs a D/A converter to produce a (256 step) constant current source. When the input pulse is applied to the DSI delay line, the constant current charges an on-chip capacitor. When the resulting ramp matches the level defined by a comparator, the output is changed. The comparator level and capacitor value are temperature compensated by a second, fixed rate ramp. This is pretty much the same thing that you all have been described here. The place where I suspect that there may be some temperature sensitivity is in the modular GPS receivers. If you look at my slide #19 from late 2000, the really great Never Happened receiver had to be temperature controlled (to ~ 1ºC), otherwise it showed diurnal room temperature variations. All these receivers have a bandpass filter with ~1.8 MHz wide somewhere in their IF chain; this filter's bandwidth is matched to the 1.023 MHz C/A code chip rate that is the root of the timing performance. Heisenberg would argue that a filter this wide will show a group delay ~500 nsec and it is often implemented as a SAW (Surface Acoustic Wave) device at an IF in the 50-200 MHz range. This is a measurement topic itching for some work! Regarding the SAW filters, on slide #33 you will see that the 4 M12+ receivers that Rick tested at USNO fell into two groups with ~4-5 nsec DC timing difference between them.You will also note on #36 that the one sample of the new iLotus
Re: [time-nuts] Software Sawtooth correction prerequisites?
What is the cost of the two channel pci system, if you happen to have the price in hand. If not, I will ask direct. Full Name: Lester B Veenstra Job Title: Communication Sys Des Engr Sr Stf Department: 6L01 Site Operations Collaboration and Reach-Back (SOCAR) Company:Integrated Systems Solutions Business Address: Lockheed Martin ISS PSC 45 Box 781 APO AE 09468 Home Address Address: Dawn Cottage Norwood, Harrogate HG3, 1SD UK Telephones: Office 940-6456 Office +44-(0)1423-846-385 Home: +44-(0)1943-880-963 UK Cell +44-(0)7716-298-224 US Cell +1-240-425-7335 Jamaica+1-876-352-7504 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr Bruce Griffiths Sent: Saturday, May 12, 2007 7:00 AM To: Tom Van Baak; Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Software Sawtooth correction prerequisites? Tom Van Baak wrote: Define cheap. You can already get essentially single chip TICs with a resolution (and accuracy) better than 100ps for around 100 Euros or so. Has anyone in the group tried one of these? I would very much like to see the results. All except Xavier seem to have shied away from obtaining these on cost grounds and the need to layout a 4 layer PCB. Although the vendor does offer an evaluation system (External box plus card plugs into PC with fat multiconductor SCSI type (but not SCSI signalling)cable connecting the two), too expensive for general use but perhaps useful for performance evaluation. The above price was for an earlier version the later reduced cost higher resolution version (range 5 nanosec - 4millisec) should be cheaper. The range can easily be extended to years if required (using CPLD counters (or even a PIC with built in counters - eg PIC18F4550) + software+ 74AC164). However the optimal solution doesn't use a TIC at all, just use a good GPS receiver that makes the carrier phase observables available. Quite a few of the older receivers used to make the carrier phase data available. Many of the Oncore VP's did this, but I don't know of anyone, amateur or commercial, that built a GPSDO using that feature. That makes me wonder if carrier phase observables alone is not enough. You also need code phase measurements as a sanity check, to determine the ionospheric delay, and to initialise the control loop. To obtain maximum performance you also need to know the GPS antenna location accurately. This may take several days to establish using code phase SV transit data. The catch is that the GPS receiver local oscillator must be phase locked to the OCXO. Some receivers use a 10MHz crystal oscillator in which case this can be removed and replaced with an external 10MHz signal derived from the OCXO being disciplined. Right, this is the key. Do you know any OEM receivers that allow an external 5/10/20 MHz? I know my Z12T does (but that is far from an OEM receiver). The Novatel SuperstarII receivers use an on board Rakon 10MHz TCXO (made a little (120km) to the North of me) local oscillator which can be disconnected with relatively little surgery and replaced with a piece of thin coax and a connector. However the required amplitude is relatively small - easily fixed with a pair of resistors - typically the output from the onboard TCXO itself has to be attenuated. Magnus acquired some of these cheaply, however even the new price isn't too steep. UNSW has used these receivers in geodetic survey/monitoring applications. The code phase field data from some of these exhibits encouraging stability (about 5 -10x better than the oscillator specs) when averaged over a few seconds even with the standard TCXO. If you want to roll your own GPS receiver the MITEL/ZARLINK chipsets use a 10MHz reference. Unfortunately there are as yet no relatively inexpensive off the shelf implementations of the GPS carrier phase discipling technique available. The calculations involved for maximum performance are somewhat complex, however not too much computing horsepower should be required. The QL carrier phase GPSDO is unique and probably not cost-effective. Sounds like it's a custom single-channel GPS receiver designed from the ground up. If there were an easier way surely someone would have done it in the past ten years. Yes $30,000 Euros or so is a little steep. Depends what you mean by easy. Vested interest in an existing receiver can lead to inertia. The other players seem wedded to using PPS disciplining, possibly because of all the existing equipment using it. Investigations into using multichannel carrier phase disciplining have been somewhat sporadic. Although single channel receivers employing carrier phase measurement have been successfully deployed in geodetic arrays for monitoring applications. Magnus hopes
Re: [time-nuts] Software Sawtooth correction prerequisites?
Tom Clark, K3IO wrote: Bruce Griffiths wrote: The Dallas delay lines aren't all that accurate, you need to calibrate them to acheive 1ns accuracy (read the specs) and then you have to worry about temperature variations. To use them you need to decode the sawtooth correction message from the GPS timing receiver. If you've decoded this message then you have all the information needed to make a software correction to the measured phase error. I need to correct some impressions that seem to have gone astray. To help me, I refer you to a PowerPoint presentation that I gave to the technicians and operators at the world's VLBI (Very Long Baseline Interferometry) sites. The presentation is available at http://gpstime.com as the 2007 version of Timing for VLBI. [Aside -- If you are interested in learning about some of VLBI's buzz-words, I also gave a tutorial What's all this VLBI stuff, anyway? that was intended as a view of the Physics and Radio Astronomy of making VLBI measurements. Some people find my de-mystifying of Heisenberg's Uncertainty Principle interesting -- especially the Schroedinger quotes at #21. This plays best if you view it as a PPT presentation.] Starting on Slide #20, I describe the reason that the Motorola receivers have the sawtooth dither. Basically clock edges of the receiver's 1PPS pulse are locked to a crystal oscillator in the receiver and that oscillator is on a frequency that is not neatly commensurate with the true second marks. As has been pointed out in these discussions, Motorola reports an estimate of the error on the NEXT 1PPS tick. Slides 21 and 22 show some of the pathological example we have seen on typical receivers. AFAIK, all the bizarre behavior has been traced to firmware problems. The reason for making sawtooth corrections (and not simply averaging multiple samples) can be seen in the hanging bridges (22:34 to 22:36 on #22, 01:04:30 to 01:05:30 on #23) when the 1PPS signal went thru a zero-beat. For these 1-2 minute windows, all statistical averaging breaks down and typical GPSDO's perform badly. However, when the sawtooth is corrected in software (blue line on #23) the resulting paper clock is well behaved (at ~1.5 nsec RMS level). Slides #24 #25 describe an annoying problem in VLBI -- we want to be able to blindly trust ANY 1PPS pulse whenever (rarely) we need to reset the working VLBI clock. Slide #26 is the block diagram of the circuit that Rick has implemented in his newest clock. Slide #29 shows a (more noisy than normal) comparison between the hardware ans software correction performance with only 0.3 nsec RMS noise between the two. Bruce noted a misconception that may have come from our earlier implementation of the correction algorithm. What we found was that EVERY sample of the 1 nsec step Dallas/Maxim delay line showed considerably more scatter.What we found, on closer examination, was that it seems that the DSI delay line chip defines one nsec about 10% differently than Motorola's one nsec. After correcting for this definition problem, as you see in #30, the hardware and software correction are in agreement with an observed regression coefficient of 0.9962 (on this sample, which shows correlation coefficient 0.999) and good tracking between samples. Bruce also made some disparaging comments on the stability of the delay lone. I can say that we have not seen any stability problems at all. This is quite logical when you carefully reverse engineer the DSI chip based on its data sheets. The delay inside the chip is really an analog delay. The 8-bit number you sent to the chip programs a D/A converter to produce a (256 step) constant current source. When the input pulse is applied to the DSI delay line, the constant current charges an on-chip capacitor. When the resulting ramp matches the level defined by a comparator, the output is changed. The comparator level and capacitor value are temperature compensated by a second, fixed rate ramp. This is pretty much the same thing that you all have been described here. I know exactly how these delay devices work, the problem is that using them in this way relies on a one time calibration of the device delays, it would be far better if delay calibration cycles could be interspersed between PPS transitions. This would technique would cope with any ageing or temperature drifts. The variable slope technique (see Dallas application note AN107) for setting the delays used in these devices means that the delay jitter increases faster with increasing delay than in the equivalent fixed slope variable threshold ramp timed delay technique. The DS1020 -15-datasheet specifies a 4ns max deviation from the programmed delay. There is no statement on the datasheet as to if this error is due to scale factor error, offset error or integral linearity error or differential linearity error. If one doesn't calibrate each individual chip how can
Re: [time-nuts] Software Sawtooth correction prerequisites?
Tom Tom Clark, K3IO wrote: Why add the cost of a programmable delay line when the additional cost of correction is a few lines of code? They also don't remove the requirement for subnanosecond phase measurement resolution and accuracy. But the receiver itself has intrinsic noise at the nsec level. You are better off by averaging sawtooth corrected (either hardware or software) measurements to achieve sub-nsec precision; IMHO, sub-nsec individual measurements aren't needed. Surely you don't plan to tweak a GPSDO every second! A good xtal is much better than ANY GPS rcvr on times of 1-100 sec. Whilst an analog phase lock loop can have the necessary resolution they are somewhat impractical for the relatively long averaging times required when optimally disciplining a good OCXO. The computational load isnt that severe as you only make one phase measurement per second. One of the simplest ways of achieving subnanosecond phase measurement resolution is to feed a quadrature phase 10MHz sinewave into a pair of simultaneous sampling ADCs (MAXIM have suitable devices prices seem reasonable). The sinewaves are sampled at the leading edge of the GPS receiver PPS signal. The ADC outputs can then be used to determine where in the cycle the PPS edge occurred. This in effect is a subnanosecond resolution phase detector with a range of 100nsec. The range can easily be extended by using a small CPLD which incorporates a couple of synchronisers (one clocked by the positive slope transition of the 10MHz signal and the other clocked by the negative slope xero crossing transition of the 10MHz signal) The output of both synchronisers samples the value of a synchronous counter which is clocked by the positive slope zero crossing of the 10MHz sinewave. Software then sorts out which latched count is most reliable (the synchroniser whose clock edge is furthest from the PPS transition). This sounds complex but it isnt, especially if you select the right PIC (or other micro) with built in counters (PIC18F4550?) that can be sampled by an external transition (output of a synchroniser). The counter need only be an 8 bits counter. This sure sounds like a more complicated measurement than is necessary to me. If you have a 10 MHz oscillator, simply feed it into the D input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of the latch is a 0 or 1 depending on the precise phase of the oscillator. You want this latched 0/1 measurement to average to ½ over a long term (seconds). As the statistics deviate from a 50/50 split, you tweak the oscillator. The ~1 nsec of residual noise from the sawtooth corrected GPS rcvr acts a natural dither. No counters, no ramps, no big A/D converter -- it couldn't be simpler! And if the 10MHz (= 100 nsec phase ambiguity) is too fine for your oscillator, then divide it to 5 MHz (=200 nsec) or 1 MHz (= 1µsec). This should be good enough to pull in a xtal that is off by 1:10e6. Very nice technique, much better to make use of the receiver noise if you can. In this case hardware correction of the PPS error is of course essential. In essence this technique implements a servo with a narrow proportional band of a few nanoseconds the width of the proportional band being determined by the corrected PPS signal noise characteristics. Outside the proportional band the servo saturates but retains the sign of the phase error. As the noise of the receiver increases so does the width of the proportional band. How then does one then actually measure the receiver timing noise, if one wishes to detect when it deteriorates to a point where it is prudent to go into holdover mode? Perhaps a chain of (3) flipflops whose D inputs are driven by the OCXO derived (10MHz, IMHz, etc) frequency and the clock inputs of which are driven by successively delayed (stable delay) versions of the PPS edge. For example the first flipflop is clocked by the PPS edge, the second fliflop is clocked by the PPS edge delayed by say T ns, and the third flipflop is clocked by PPS delayed by 2T ns. Follow these flipflops by a set of synchronisers. Lock the OCXO so that the 2nd Flipflop has 50% probability of being either 1 or 0. The probability of occurrence of say a logic 1 at the outputs of the other first and third flipflops can then be used to monitor the receiver timing noise level. Alternatively the D inputs to the flipflops could be successively delayeed by T ns whilst all flipflops are clocked by the PPS signal. Surely it would be better to use a synchroniser and/or a flipflop/latch with extremely short regeneration time constant to ensure that the probability of metastable states is insignificant. In this case subsequent stages of the synchroniser could be clocked by delayed (fixed non critical delay) versions of the PPS transition as waiting several seconds for a particular decision to propagate to the output of the synchroniser if each
Re: [time-nuts] Software Sawtooth correction prerequisites?
Lester I have no idea you'll need to contact Acam direct. http://www.acam.de Bruce Lester Veenstra M0YCM K1YCM wrote: What is the cost of the two channel pci system, if you happen to have the price in hand. If not, I will ask direct. Full Name: Lester B Veenstra Job Title: Communication Sys Des Engr Sr Stf Department: 6L01 Site Operations Collaboration and Reach-Back (SOCAR) Company:Integrated Systems Solutions Business Address: Lockheed Martin ISS PSC 45 Box 781 APO AE 09468 Home Address Address: Dawn Cottage Norwood, Harrogate HG3, 1SD UK Telephones: Office 940-6456 Office +44-(0)1423-846-385 Home: +44-(0)1943-880-963 UK Cell +44-(0)7716-298-224 US Cell +1-240-425-7335 Jamaica+1-876-352-7504 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr Bruce Griffiths Sent: Saturday, May 12, 2007 7:00 AM To: Tom Van Baak; Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Software Sawtooth correction prerequisites? Tom Van Baak wrote: Define cheap. You can already get essentially single chip TICs with a resolution (and accuracy) better than 100ps for around 100 Euros or so. Has anyone in the group tried one of these? I would very much like to see the results. All except Xavier seem to have shied away from obtaining these on cost grounds and the need to layout a 4 layer PCB. Although the vendor does offer an evaluation system (External box plus card plugs into PC with fat multiconductor SCSI type (but not SCSI signalling)cable connecting the two), too expensive for general use but perhaps useful for performance evaluation. The above price was for an earlier version the later reduced cost higher resolution version (range 5 nanosec - 4millisec) should be cheaper. The range can easily be extended to years if required (using CPLD counters (or even a PIC with built in counters - eg PIC18F4550) + software+ 74AC164). Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Will do Likes like an interesting product line Full Name: Lester B Veenstra Job Title: Communication Sys Des Engr Sr Stf Department: 6L01 Site Operations Collaboration and Reach-Back (SOCAR) Company:Integrated Systems Solutions Business Address: Lockheed Martin ISS PSC 45 Box 781 APO AE 09468 Home Address Address: Dawn Cottage Norwood, Harrogate HG3, 1SD UK Telephones: Office 940-6456 Office +44-(0)1423-846-385 Home: +44-(0)1943-880-963 UK Cell +44-(0)7716-298-224 US Cell +1-240-425-7335 Jamaica+1-876-352-7504 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr Bruce Griffiths Sent: Saturday, May 12, 2007 10:12 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Software Sawtooth correction prerequisites? Lester I have no idea you'll need to contact Acam direct. http://www.acam.de Bruce Lester Veenstra M0YCM K1YCM wrote: What is the cost of the two channel pci system, if you happen to have the price in hand. If not, I will ask direct. Full Name: Lester B Veenstra Job Title: Communication Sys Des Engr Sr Stf Department: 6L01 Site Operations Collaboration and Reach-Back (SOCAR) Company:Integrated Systems Solutions Business Address: Lockheed Martin ISS PSC 45 Box 781 APO AE 09468 Home Address Address: Dawn Cottage Norwood, Harrogate HG3, 1SD UK Telephones: Office 940-6456 Office +44-(0)1423-846-385 Home: +44-(0)1943-880-963 UK Cell +44-(0)7716-298-224 US Cell +1-240-425-7335 Jamaica+1-876-352-7504 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr Bruce Griffiths Sent: Saturday, May 12, 2007 7:00 AM To: Tom Van Baak; Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Software Sawtooth correction prerequisites? Tom Van Baak wrote: Define cheap. You can already get essentially single chip TICs with a resolution (and accuracy) better than 100ps for around 100 Euros or so. Has anyone in the group tried one of these? I would very much like to see the results. All except Xavier seem to have shied away from obtaining these on cost grounds and the need to layout a 4 layer PCB. Although the vendor does offer an evaluation system (External box plus card plugs into PC with fat multiconductor SCSI type (but not SCSI signalling)cable connecting the two), too expensive for general use but perhaps useful for performance evaluation. The above price was for an earlier version the later reduced cost higher resolution version (range 5 nanosec - 4millisec) should be cheaper. The range can easily be extended to years if required (using CPLD counters (or even a PIC with built in counters - eg PIC18F4550) + software+ 74AC164). Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Tom Clark, K3IO wrote: If you have a 10 MHz oscillator, simply feed it into the D input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of the latch is a 0 or 1 depending on the precise phase of the oscillator. You want this latched 0/1 measurement to average to ½ over a long term (seconds). As the statistics deviate from a 50/50 split, you tweak the oscillator. The ~1 nsec of residual noise from the sawtooth corrected GPS rcvr acts a natural dither. No counters, no ramps, no big A/D converter -- it couldn't be simpler! And if the 10MHz (= 100 nsec phase ambiguity) is too fine for your oscillator, then divide it to 5 MHz (=200 nsec) or 1 MHz (= 1µsec). This should be good enough to pull in a xtal that is off by 1:10e6. Tom How does one do robust statistical filtering of outliers when one uses this technique?? Bruce I hope these comments helped a bit -- 73, Tom ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Jim Miller wrote: My first post...newbie...be gentle... I spent the last several evenings reading the archives and saw mention of sawtooth error correction in software. Since the corrections to be applied are on the order of 1e-9 seconds it would seem that the phase detector outputs to which these are applied must be similar in resolution. That would seem to require a pretty hefty phase detector and a pretty substantial computing resource. Doesn't sound inexpensive. Is there a way around this? OTOH, the Dallas Semi delay line pushes the computation out into the input of the phase detector at the cost of a $17 chip (1k qty) which in small quantities is likely $50 or so. This would seem to allow for a wider variety of phase measurement techniques. Do I have this right? tnx jim miller ab3cv ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts Jim DS1021-15 (SOIC package) price is about $31 (1 off) from the Maxim-Dallas on line shop Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
$31 is certainly a reasonable price and would allow flexibility in the phase comparator design. I had forgotten that Maxim had a direct sale page. My bad... tnx jim miller ab3cv - Original Message - From: Dr Bruce Griffiths [EMAIL PROTECTED] To: Jim Miller [EMAIL PROTECTED]; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, May 12, 2007 9:18 AM Subject: Re: [time-nuts] Software Sawtooth correction prerequisites? Jim DS1021-15 (SOIC package) price is about $31 (1 off) from the Maxim-Dallas on line shop Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
I got a few of them off eBay a long time ago, it doesn't appear the seller has any more of them (they were removed from some other equipment IIRC). I still have two of the Superstar II receivers. They are older OEM models with the 4mb flash (all the new firmwares require the 8mb flash) so they are not firmware upgradeable. I scrounged up some PDFs with basic info, their pinout is very similar to the older Rockwell Jupiter receivers. Anyhow, yes they do have the Rakon 10 MHz TCXO on them. I was going to do something with these, but I know I'll never get around to it and I'm sure one of you guys could put them to better use. $25 shipped takes the pair of receivers and a pair of 9 MCX-SMA pigtails. Contact me off-list... first come first serve. Jason The Novatel SuperstarII receivers use an on board Rakon 10MHz TCXO (made a little (120km) to the North of me) local oscillator which can be disconnected with relatively little surgery and replaced with a piece of thin coax and a connector. However the required amplitude is relatively small - easily fixed with a pair of resistors - typically the output from the onboard TCXO itself has to be attenuated. Magnus acquired some of these cheaply, however even the new price isn't too steep. UNSW has used these receivers in geodetic survey/monitoring applications. The code phase field data from some of these exhibits encouraging stability (about 5 -10x better than the oscillator specs) when averaged over a few seconds even with the standard TCXO. If you want to roll your own GPS receiver the MITEL/ZARLINK chipsets use a 10MHz reference. ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
This sure sounds like a more complicated measurement than is necessary to me. If you have a 10 MHz oscillator, simply feed it into the D input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of the latch is a 0 or 1 depending on the precise phase of the oscillator. You want this latched 0/1 measurement to average to ½ over a long term (seconds). As the statistics deviate from a 50/50 split, you tweak the oscillator. The ~1 nsec of residual noise from the sawtooth corrected GPS rcvr acts a natural dither. No counters, no ramps, no big A/D converter -- it couldn't be simpler! And if the 10MHz (= 100 nsec phase ambiguity) is too fine for your oscillator, then divide it to 5 MHz (=200 nsec) or 1 MHz (= 1µsec). This should be good enough to pull in a xtal that is off by 1:10e6. This sounds really simple and irresistible. Have you or Rick tried it out? I see instead of a TIC (Time Interval Counter) you have a TAC (Time Average Controller ;-) Not just GPS 1PPS noise but any oscillator noise (jitter), if large enough, is also a source of natural dither. Sounds like this design would be especially ideal for a low-end GPSDO; i.e., one that only needs to be accurate to 10^-9 or 10^-10. Did you envision that the OCXO EFC would be driven by a statistics-collecting microprocessor and a high-resolution DAC? Or is there some clever way to tie statistical results of the D-latch to the EFC and avoid the DAC too? /tvb ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
The statement that Dallas' version of the nanosecond differs by 10% from Motorola's is somewhat disconcerting until one analyses how the delay generator works. Simplified description Aside from the contribution from internal logic propagation delays Delay = Constant*RC, Where R is the value of a resistor that determines the current used to charge a capacitor and the constant is determined by resistor ratios. Thus a naive implementation may use 256 equal resistors (r) connected in series with a set of switches used to select the the required resistance value (Nr) in 256 nominally equal steps. The delay would then be proportional to N. Unfortunately the ramp slope would vary over a range of 256 to 1 as would the current. The current mirror used in the actual circuit may have some dificulty in operating accurately over a current range of 256:1. Also the power dissipation in some of the resistors in the string would vary over a large range. The large range (256:1) in the ramp slew rate seen by the comparator would lead to significant variations in the comparator delay. Fortunately if the effective value of the resistor corresponding to N=0 is made somewhat larger (=Ro) than r then although the N=0 delay will increased, the range of currents seen by the current mirror and the corresponding slew rates seen by the comparator can be reduced significantly improving the performance and reducing the variation in resistor dissipation. This implementation should be inherently monotonic despite variations in r and Ro. The effective RC product and the corresponding delay can be designed to have a low temperature coefficient. The RC product will vary from lot to lot and this variation can be compensated by resistor trimming. There are other schemes other than a series resistor string that can be used, however most of these are not inherently monotonic and resistor trimming to correct this error as well as the scale error may be necessary. The attached plot of the error of a typical DS1020-15 illustrates that the integral non linearity of the delay may amount to several nanoseconds worst case. This indicates that if one uses say 30ns of the range to correct for the sawtooth error of an M12M or equivalent GPS timing receiver, that a typical correction error due to the intergral non linearity of the DS1020-15 may be as large as 1ns. However this can be reduced significantly by calibration or perhaps by just calibrating the gain. However unless an actual calibration or parameter fitting to a more elaborate model for the INL other than just a change of scale factor the specified data sheet maximum value for the delay it is unlikely that a mere adjustment of the scale factor will ensure that the delay error of every DS1021-15 that meets its datasheet specification will be less than 1 nanosecond. The optimum scale factor may also vary from wafer to wafer as well as within the wafer. Thus whilst it is highly likely that calibrating the delay and using a lookup table or a model for the INL using several adjustable parameters will allow a programmed delay error of under 1ns, it is unlikely that merely adjusting the gain will reduce the programmed delay error to under 1ns for all DS1021-15s ever produced that meet the datasheet specifications. More detailed inline: DS1020-15.gif___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Tom Van Baak wrote: This sure sounds like a more complicated measurement than is necessary to me. If you have a 10 MHz oscillator, simply feed it into the D input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of the latch is a 0 or 1 depending on the precise phase of the oscillator. You want this latched 0/1 measurement to average to ½ over a long term (seconds). As the statistics deviate from a 50/50 split, you tweak the oscillator. The ~1 nsec of residual noise from the sawtooth corrected GPS rcvr acts a natural dither. No counters, no ramps, no big A/D converter -- it couldn't be simpler! And if the 10MHz (= 100 nsec phase ambiguity) is too fine for your oscillator, then divide it to 5 MHz (=200 nsec) or 1 MHz (= 1µsec). This should be good enough to pull in a xtal that is off by 1:10e6. This sounds really simple and irresistible. Have you or Rick tried it out? I see instead of a TIC (Time Interval Counter) you have a TAC (Time Average Controller ;-) Not just GPS 1PPS noise but any oscillator noise (jitter), if large enough, is also a source of natural dither. Sounds like this design would be especially ideal for a low-end GPSDO; i.e., one that only needs to be accurate to 10^-9 or 10^-10. Did you envision that the OCXO EFC would be driven by a statistics-collecting microprocessor and a high-resolution DAC? Or is there some clever way to tie statistical results of the D-latch to the EFC and avoid the DAC too? /tvb ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts Tom A D flipflop is a better choice than a transparent latch. If the PPS signal also interrupts the micro, the built in interrupt synchroniser will ensure sufficient delay that when the output of the D flipflop is sampled the probability of its output being in a metastable state will be extremely low particularly if a 74AC74 or faster flipflop is employed. Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Hi Jim: The size of the sawtooth error depends on which GPS receiver you are using. The older 6 and 8 channel Motorola receivers were a little over 50 ns and the newer 12 channel receivers are around 10 ns. But it's my understanding that there's a bug in the sawtooth output on all the 6 channel units and all but the very newest firmware versions of the 8 channel units so that you increase the errors by attempting to correct their sawtooh errors, better to just average them. The 12 channel receivers have working firmware and so applying the correction works. If you use the HP 53131 or 53132 counter and the TAC32 software (join TAPR to get it at the ham discount price) then the correction is done in that software for you. It's nothing fancy just subtracting the offset error from the measurement. CNS who sells TAC32 also has a box that includes the hardware correction built in. But the first versions of that box did not work as well as they should and there's a firmware update that helps. Whether you need the hardware approach would depend on your use. For data logging like when comparing a source to GPS the post processing method costs much less and the result is identical with the hardware approach. But for disciplining a Rb of Cs standard the hardware approach would be better. There's been quite a bit of discussion about the deficiencies the current home brew GPSDO designs have when used with the 12 channel Motorola (whatever the new name is) chips and there's some preliminary work on a phase detector up to the stability needs of that receiver. Sawtooth correction will be a part of that design. Have Fun, Brooke Clarke, N6GCE http://www.PRC68.com http://www.precisionclock.com Jim Miller wrote: My first post...newbie...be gentle... I spent the last several evenings reading the archives and saw mention of sawtooth error correction in software. Since the corrections to be applied are on the order of 1e-9 seconds it would seem that the phase detector outputs to which these are applied must be similar in resolution. That would seem to require a pretty hefty phase detector and a pretty substantial computing resource. Doesn't sound inexpensive. Is there a way around this? OTOH, the Dallas Semi delay line pushes the computation out into the input of the phase detector at the cost of a $17 chip (1k qty) which in small quantities is likely $50 or so. This would seem to allow for a wider variety of phase measurement techniques. Do I have this right? tnx jim miller ab3cv ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Brooke Thanks for the quick response. I'm definitely in the amateur/hobbyist, frequency quadrant of the spectrum of posters/lurkers here. I'm mostly interested in the homebrew M12M/GPSDO activities so the HP counter doesn't appear applicable. tnx jim miller ab3cv ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Jim Miller wrote: My first post...newbie...be gentle... I spent the last several evenings reading the archives and saw mention of sawtooth error correction in software. Since the corrections to be applied are on the order of 1e-9 seconds it would seem that the phase detector outputs to which these are applied must be similar in resolution. That would seem to require a pretty hefty phase detector and a pretty substantial computing resource. Doesn't sound inexpensive. Is there a way around this? OTOH, the Dallas Semi delay line pushes the computation out into the input of the phase detector at the cost of a $17 chip (1k qty) which in small quantities is likely $50 or so. This would seem to allow for a wider variety of phase measurement techniques. Do I have this right? tnx jim miller ab3cv Jim Your conclusions are somewhat astray. The Dallas delay lines aren't all that accurate, you need to calibrate them to acheive 1ns accuracy (read the specs) and then you have to worry about temperature variations. To use them you need to decode the sawtooth correction message from the GPS timing receiver. If you've decoded this message then you have all the information needed to make a software correction to the measured phase error. Why add the cost of a programmable delay line when the additional cost of correction is a few lines of code? They also don't remove the requirement for subnanosecond phase measurement resolution and accuracy. Whilst an analog phase lock loop can have the necessary resolution they are somewhat impractical for the relatively long averaging times required when optimally disciplining a good OCXO. The computational load isnt that severe as you only make one phase measurement per second. One of the simplest ways of achieving subnanosecond phase measurement resolution is to feed a quadrature phase 10MHz sinewave into a pair of simultaneous sampling ADCs (MAXIM have suitable devices prices seem reasonable). The sinewaves are sampled at the leading edge of the GPS receiver PPS signal. The ADC outputs can then be used to determine where in the cycle the PPS edge occurred. This in effect is a subnanosecond resolution phase detector with a range of 100nsec. The range can easily be extended by using a small CPLD which incorporates a couple of synchronisers (one clocked by the positive slope transition of the 10MHz signal and the other clocked by the negative slope xero crossing transition of the 10MHz signal) The output of both synchronisers samples the value of a synchronous counter which is clocked by the positive slope zero crossing of the 10MHz sinewave. Software then sorts out which latched count is most reliable (the synchroniser whose clock edge is furthest from the PPS transition). This sounds complex but it isnt, especially if you select the right PIC (or other micro) with built in counters (PIC18F4550?) that can be sampled by an external transition (output of a synchroniser). The counter need only be an 8 bits counter. Another technique is to start a ramp on the leading edge of the PPS signal from the GPS receiver and stop it at the corresponding output transition of a synchroniser (clocked at 10MHz) whose output samples an (8bit) counter (also clocked at 10MHz - your local OCXO standards frequency). The final value of the ramp is sampled by an ADC and combined with the sampled count to resolve the 1 count ambiguity at the synchroniser output. The ramp is then reset for the next PPS pulse. Calibration of the ramp generator is required but calibration cycles are easily interleaved between PPS pulses. Although it may seem that a fast opamp is required for the ramp generator, this isnt so as you can wait for any opamp (and/or ADC input) to settle to before sampling the ramp output. With careful design curvature correction isn't required (don't slavishly copy the Linear technology Application note, you can do better with less). The ramp generator needs a range of 300ns or greater with a 10MHz synchroniser clock. A 10-12 bit ADC will provide subnanosecond resolution. The ADC need not be fast (10us per conversion is adequate), however a sigma delta ADC is unsuitable. Synchronisers can easily be built from shift registers. Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
My first post...newbie...be gentle... I spent the last several evenings reading the archives and saw mention of sawtooth error correction in software. Since the corrections to be applied are on the order of 1e-9 seconds it would seem that the phase detector outputs to which these are applied must be similar in resolution. Right. When a correction is way smaller than the signal one usually doesn't bother with a correction. On the other hand, some might argue that every little bit helps. That would seem to require a pretty hefty phase detector and a pretty substantial computing resource. Doesn't sound inexpensive. Is there a way around this? I would agree. A 1 ns phase detector is usually more than a single IC. Not sure what to say about the computer resource, though. The sawtooth correction is usually obtained though a low-speed (e.g., 9600 baud) serial message from the GPS receiver. Most any $2 microcontroller can handle a task like this. When someone finds a cheap single-shot 1 ns TIC-on-a-chip please let me know. OTOH, the Dallas Semi delay line pushes the computation out into the input of the phase detector at the cost of a $17 chip (1k qty) which in small quantities is likely $50 or so. This would seem to allow for a wider variety of phase measurement techniques. Do I have this right? Yes, although it depends on the application. If you are using GPS, for example, to monitor the long-term performance of a cesium standard then you already need a high-resolution TIC. Sawtooth correction is useful but it doesn't make more than 1 ns difference if it's hardware or software. Sometimes using two serial ports and correcting in software is fine. Other times it's more convenient to use a box like the CNS-II where it's all nicely done in hardware. If you hare thinking of a GPSDO you need a phase detector so you have to ask yourself if hardware sawtooth correction with a good phase detector is better than an excellent phase detector with just software correction. You'd have to do the math to decide which was better. The other factor that someone can comment on is what effect time averaging has on all this. Can a coarse phase detector do the job if you average long enough? Most GPSDO don't need to make decisions every second. If you have a good OCXO and tweak the EFC only once every 100 or 1000 seconds, can you get away with a cheaper phase detector design? All of this reminds me -- how many of you would be able to, or would like to, do a GPSDO simulation? I have or can get days of M12+ raw data, sawtooth data, and OCXO data. It should be quite possible, then, to model a GPSDO. Once you have this virtual GPSDO you can instantly see what effect something like sawtooth correction has. Or see what effect making the phase detector 5x better or 5x worse has on the output. Or see what happens when there is a frequency jump in the OCXO. Or the effect of a temporary loss of GPS signal, etc. Or vary the cross-over point to see how the ADEV of the VGPSDO changes. Or test different PID algorithms. Or compare the effect of a cheap vs. good OCXO, etc. /tvb tnx jim miller ab3cv ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Tom Van Baak escribió: When someone finds a cheap single-shot 1 ns TIC-on-a-chip please let me know. www.acam.de Not very expensive although not cheap. I've some samples... but not yet time to experiment with them. Regards, Javier, EA1CRB ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Javier wrote: Tom Van Baak escribió: When someone finds a cheap single-shot 1 ns TIC-on-a-chip please let me know. www.acam.de Not very expensive although not cheap. I've some samples... but not yet time to experiment with them. Regards, Javier, EA1CRB Javier You still need some additional hardware like a synchroniser (shift register). However this is indeed about as close as you will get to a single chip solution. For an analog style TAC see attached schematic. The required level shifting has been omitted for clarity. NB current mode logic is employed where either P1 or P2 collector current is equal to alpha times P3's collector current. Similarly for N1, N2, N3. During reset both N2 and P2 are ON. Diodes D1 and D2 conduct equal currents. The collector current of N3 is 2x the collector current of P3. The START input turns off N2 so that P2 charges C1. The STOP input turns off P2 leaving the ramp voltage corresponding to the time between the START and STOP transitions stored on C1. The opamp is then takes a few microsec to settle at which point its output can be sampled by an ADC. When START and STOP both go to zero the capacitor voltage ramps down until it is clamped at 0V by D1 and D2. Bruce inline: OLAPTAC.gif___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Javier Corrected Analog TAC schematic attached. The number of extra chips required depends on if one uses a CPLD or SSI logic (eg 74HC/74AHC parts) and if your selected micro has a suitable internal ADC and or a counter that can be sampled by an external signal transition. Bruce inline: OLAPTAC.gif___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Synchronisers can easily be built from shift registers. What do you mean by synchronizer? Are you talking about a delay so the times line up correctly or a circuit to avoid metastability? -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Hal Murray wrote: Synchronisers can easily be built from shift registers. What do you mean by synchronizer? Are you talking about a delay so the times line up correctly or a circuit to avoid metastability? Hal Usually just a fast shift register with the number of stages selected to achieve a suitably low rate of metastable states at the output. Its usually easy to ensure that the failure rate is less than once in a few terayears. The PPS signal will not be synchronous with the local OCXO due to noise and sawtooth error so that metastable states are possible when the PPS is connected to the D input of a flipflop clocked by the OCXO. Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Hi Tom I thought the 1ns resolution phase detector combined with a significant phase error in a PLL could generate a number large enough to need a 4 byte representation which would then need signed arithmetic done on it. Accumulating many of those over the integration period means even greater precision in the PI software. Lots of work for a little PIC. Lesser resolution means easier computation although 1 second is a long time. I finally found where the sawtooth info comes from: the RAIM message...I mentioned I was a newbie. Since it is just an signed 8bit number in nanoseconds and is in the 50ns range it doesn't seem too useful if a low resolution phase detector has already quantized the phase sample. I suppose it could be accumulated anyway in the off chance the mean of the errors was significantly non-zero. I'm strictly an amateur looking at building a GPSDO for a workbench frequency standard and perhaps for occasional use on a ham rig. My oscillator will most likely be a HP10811 or similar. Your simulator sounds interesting. Would it need to be built on a commercial package? tnx jim miller ab3cv ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
