[time-nuts] Of rubidium life and piggy-bank anemia....
Greetings, all-- As a newbie to this list, I am playing catchup in a number of arenas so please forgive me if I post something which is old news to most. In any event, something John Miles said pointed me towards investigating what it would take to cobble up something that would get me to the next higher level of frequency accuracy that exceeded my Trimble Thunderbolt. My primary purpose is to have the most (relatively) accurate 10MHz or 100MHz frequency reference to use in measurements above 2GHz but below 24GHz. Obviously, a somewhat anemic piggy-bank prohibits me from dropping several thousands of $$$ (choke) on a surplus cesium reference, so I am going to have to settle for rubidium. I see lots of rubidium oscillators come and go on eBay for several hundred $$. I started out to see what it would take to replace the OCXO in my T-bolt with a rubidium oscillator. One concern I had was paying $400 for a surplus rubidium oscillator and then discovering that it only had a year or two of life left in it. I stumbled across an interesting (but a tad dated) Air Force study titled: Observations on the Reliability of Rubidium Frequency Standards on Block II/IIA GPS Satellites It is found at: http://tycho.usno.navy.mil/ptti/1995/Vol%2027_10.pdf It may well turn out that after the tears dry following the realization that I probably cannot afford a tighter frequency reference than my T-bolt provides I will just have to resign myself to the E-12 of the T-Bolt and be happy... Your thoughts and comments are most welcome-- Mike Baker Micanopy, Florida - ___ 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] Of rubidium life and piggy-bank anemia....
Hi Mike -- Most modern Rbs, and particularly the small telecom ones (which is what most of the <$500 ones are) have a quite long lamp life; I haven't heard of any of them failing because of lamp burnout. However, note that those Rbs tend to have only modest short term stability and phase noise. In fact, the Tbolt is likely to be significantly better in those regards than the Rb. So swapping out the OCXO for an Rb may not be the best move. But on the other hand, having a free-running Rb that you calibrate against the Tbolt (or some other reference) every so often isn't a bad idea; it gives you a source that's independent of external factors. John Michael Baker said the following on 11/29/2007 05:31 PM: > Greetings, all-- > > As a newbie to this list, I am playing catchup > in a number of arenas so please forgive me if > I post something which is old news to most. > > In any event, something John Miles said pointed > me towards investigating what it would take to > cobble up something that would get me to the next > higher level of frequency accuracy that exceeded my > Trimble Thunderbolt. My primary purpose is to have > the most (relatively) accurate 10MHz or 100MHz frequency > reference to use in measurements above 2GHz but > below 24GHz. Obviously, a somewhat anemic piggy-bank > prohibits me from dropping several thousands of $$$ (choke) > on a surplus cesium reference, so I am going to have to > settle for rubidium. I see lots of rubidium oscillators > come and go on eBay for several hundred $$. > > I started out to see what it would take to replace the > OCXO in my T-bolt with a rubidium oscillator. One > concern I had was paying $400 for a surplus rubidium > oscillator and then discovering that it only had a year > or two of life left in it. > > I stumbled across an interesting (but a tad dated) Air > Force study titled: > > Observations on the Reliability of Rubidium Frequency > Standards on Block II/IIA GPS Satellites > > It is found at: > > http://tycho.usno.navy.mil/ptti/1995/Vol%2027_10.pdf > > It may well turn out that after the tears dry following > the realization that I probably cannot afford a tighter > frequency reference than my T-bolt provides I will just > have to resign myself to the E-12 of the T-Bolt > and be happy... > > Your thoughts and comments are most welcome-- > > Mike Baker > Micanopy, Florida > - > > > > > ___ > 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] Of rubidium life and piggy-bank anemia....
John Ackermann N8UR wrote: > > But on the other hand, having a free-running Rb that you calibrate > against the Tbolt (or some other reference) every so often isn't a bad > idea; it gives you a source that's independent of external factors. > > John This was the road to hell for me :) I bought a Z3801A (moral equivalent to the Trimble Thunderbolt) back in 2000. I've happily used it as my house reference for both PPS and 10MHz for many years confident that I have a solid timebase. For the last several years I've been designing spectrometers for radio telescopes and it's been convenient and sometimes essential to have a timebase that's not too much worse than a modern radio telescope. I see the lock light, I make a few plots, and I get a warm feeling that I know what time it is. http://www.mock.com/gps I recently bought an Rb source for fun. Nominally I use it as the timebase for my frequency counter and run everything else off of the z3801a. Now I live in constant state of flux not really knowing what 10MHz is anymore. I need more clocks, my Rb source is amplifying my personality quirks. jeff ___ 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] Of rubidium life and piggy-bank anemia....
A very old saying: Give a man a watch and he will always know what time it is. Give him two, and he is never sure. -Chuck Harris > This was the road to hell for me :) I bought a Z3801A (moral equivalent > to the Trimble Thunderbolt) back in 2000. I've happily used it as my > house reference for both PPS and 10MHz for many years confident that I > have a solid timebase. > > For the last several years I've been designing spectrometers for radio > telescopes and it's been convenient and sometimes essential to have a > timebase that's not too much worse than a modern radio telescope. I see > the lock light, I make a few plots, and I get a warm feeling that I know > what time it is. > http://www.mock.com/gps > > I recently bought an Rb source for fun. Nominally I use it as the > timebase for my frequency counter and run everything else off of the > z3801a. Now I live in constant state of flux not really knowing what > 10MHz is anymore. I need more clocks, my Rb source is amplifying my > personality quirks. > > jeff > > > ___ > 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] Of rubidium life and piggy-bank anemia....
So, is it a case where someone who has a Thunderbolt and a telco grade Rb should use the TB for normal use when GPS is up and use it to resync the Rb on occasion, so that the Rb can be used as a backup when the GPS goes out? Should the Rb be phase locked to the TB with a very long time constant, and if so, how long? I guess the answer is: plot the Allan Variance of the Rb, knowing what that of the TB is, and you know the answer :-) The problem is, if you only have a TB and an Rb, how do you plot the Allan Variance? Borrow tvb's Cesium? In favor of the TB, I may point out that the power consumption of a Rb oscillator is not negligible, compared to that of most GPSDOs. If you are concerned about heat or power consumption, you may want to consider that. Didier KO4BB > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Ackermann N8UR > Sent: Thursday, November 29, 2007 5:10 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia > > Hi Mike -- > > Most modern Rbs, and particularly the small telecom ones > (which is what most of the <$500 ones are) have a quite long > lamp life; I haven't heard of any of them failing because of > lamp burnout. > > However, note that those Rbs tend to have only modest short > term stability and phase noise. In fact, the Tbolt is likely > to be significantly better in those regards than the Rb. So > swapping out the OCXO for an Rb may not be the best move. > > But on the other hand, having a free-running Rb that you > calibrate against the Tbolt (or some other reference) every > so often isn't a bad idea; it gives you a source that's > independent of external factors. > > John ___ 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] Of rubidium life and piggy-bank anemia....
Hal Murray wrote: >> I think the rest of the saying probably is: "Give him three clocks, >> and he will start to calculate Allen Variances..." >> > > If I had a good clock (aka place to stand), I think I could use it to > calculate the Allen Variance of a not-so-good clock. > > How do I do it if I have several clocks and there isn't one that is obviously > better than the others? > > > Use the three cornered hat technique. 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] Of rubidium life and piggy-bank anemia....
I think the rest of the saying probably is: "Give him three clocks, and he will start to calculate Allen Variances..." -Chuck Harris [EMAIL PROTECTED] wrote: > But TVB has added: > "That three clocks are better than two.so measure, measure, measure!" > > Or some words to that point. > > -Brian, WA1ZMS > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Chuck Harris > Sent: Thursday, November 29, 2007 9:35 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia > > > A very old saying: > > Give a man a watch and he will always know what time it is. Give > him two, and he is never sure. > > -Chuck Harris ___ 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] Of rubidium life and piggy-bank anemia....
> I think the rest of the saying probably is: "Give him three clocks, > and he will start to calculate Allen Variances..." If I had a good clock (aka place to stand), I think I could use it to calculate the Allen Variance of a not-so-good clock. How do I do it if I have several clocks and there isn't one that is obviously better than the others? -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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] Of rubidium life and piggy-bank anemia....
But TVB has added: "That three clocks are better than two.so measure, measure, measure!" Or some words to that point. -Brian, WA1ZMS -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Chuck Harris Sent: Thursday, November 29, 2007 9:35 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia A very old saying: Give a man a watch and he will always know what time it is. Give him two, and he is never sure. -Chuck Harris > This was the road to hell for me :) I bought a Z3801A (moral equivalent > to the Trimble Thunderbolt) back in 2000. I've happily used it as my > house reference for both PPS and 10MHz for many years confident that I > have a solid timebase. > > For the last several years I've been designing spectrometers for radio > telescopes and it's been convenient and sometimes essential to have a > timebase that's not too much worse than a modern radio telescope. I see > the lock light, I make a few plots, and I get a warm feeling that I know > what time it is. > http://www.mock.com/gps > > I recently bought an Rb source for fun. Nominally I use it as the > timebase for my frequency counter and run everything else off of the > z3801a. Now I live in constant state of flux not really knowing what > 10MHz is anymore. I need more clocks, my Rb source is amplifying my > personality quirks. > > jeff > > > ___ > 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] Of rubidium life and piggy-bank anemia....
Magne Mæhre wrote: > Ulrich Bangert wrote: > >> Use the three-cornered-hat method to rank your clocks! >> > > The literature seems to say that you need to do the measurements > simultanously to get good results from the TCH method. I guess > most of us have only one TIC at home, so I wonder how the results > will be affected by taking them one at a time ? > > --Magne > > ___ > 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. > > So use a gate array to implement a multichannel time stamp device. 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] Of rubidium life and piggy-bank anemia....
Ulrich Bangert wrote: > Use the three-cornered-hat method to rank your clocks! The literature seems to say that you need to do the measurements simultanously to get good results from the TCH method. I guess most of us have only one TIC at home, so I wonder how the results will be affected by taking them one at a time ? --Magne ___ 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] Of rubidium life and piggy-bank anemia....
Use the three-cornered-hat method to rank your clocks! Regards Ulrich Bangert > -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Hal Murray > Gesendet: Freitag, 30. November 2007 06:18 > An: Discussion of precise time and frequency measurement > Betreff: Re: [time-nuts] Of rubidium life and piggy-bank anemia > > > > > I think the rest of the saying probably is: "Give him > three clocks, > > and he will start to calculate Allen Variances..." > > If I had a good clock (aka place to stand), I think I could use it to > calculate the Allen Variance of a not-so-good clock. > > How do I do it if I have several clocks and there isn't one > that is obviously > better than the others? > > > -- > These are my opinions, not necessarily my employer's. I hate spam. > > > > > ___ > 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] Of rubidium life and piggy-bank anemia....
Maybe quasi-simultaneously is adequate, using a switch to sample the 3 pairs in rotation. The HP59307A can be used for that under GPIB control. I would think the main reason for doing it simultaneously is so that whatever source of error exists (temperature, vibration, etc) will affect the 3 oscillators the same way. The switch won't help with vibration, but it will help with temperature and other slow changing variables, such as time of day. Didier KO4BB > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Griffiths > Sent: Friday, November 30, 2007 11:00 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia > > Magne Mæhre wrote: > > Ulrich Bangert wrote: > > > >> Use the three-cornered-hat method to rank your clocks! > >> > > > > The literature seems to say that you need to do the measurements > > simultanously to get good results from the TCH method. I > guess most > > of us have only one TIC at home, so I wonder how the > results will be > > affected by taking them one at a time ? > > > > --Magne > > > > ___ > > 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. > > > > > So use a gate array to implement a multichannel time stamp device. > > 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. ___ 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] Of rubidium life and piggy-bank anemia....
> So use a gate array to implement a multichannel time stamp device. FPGA development boards are readily available and some people consider the price within range. Would digital inputs be good enough? Suppose you feed several 10 MHz signals into a FPGA and program it so each input signal drives a counter. Ignoring implementation details like synchronization, is that good enough to be interesting? I'm assuming you have a PC that grabs all the counters every N ticks/seconds/hours/whatever. Note that there is another clock involved. It's the one driving the FPGA or PC. How much would it help if there was an A/D on each input channel and the FPGA could capture a dozen samples on each signal around the time that it latches a copy the counters? -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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] Of rubidium life and piggy-bank anemia....
Hal Murray wrote: >> So use a gate array to implement a multichannel time stamp device. >> > > FPGA development boards are readily available and some people consider the > price within range. > > Would digital inputs be good enough? Suppose you feed several 10 MHz signals > into a FPGA and program it so each input signal drives a counter. Ignoring > implementation details like synchronization, is that good enough to be > interesting? I'm assuming you have a PC that grabs all the counters every N > ticks/seconds/hours/whatever. > > Note that there is another clock involved. It's the one driving the FPGA or > PC. > > How much would it help if there was an A/D on each input channel and the FPGA > could capture a dozen samples on each signal around the time that it latches > a copy the counters? > > > Hal Use a mixer for each input frequency source together with an common offset source not an FPGA if you really want high resolution. However you will need to use low phase noise distribution amplifiers with crosstalk and reverse isolation better than 120dB. Feeding several different clocks into the same FPGA is somewhat counterproductive as they will all interact to produce rather high jitter. Using an A/D can be somewhat futile unless it has noise and resolution of an ideal 24bit (or more) ADC. If you want to use an ADC then its best to use a technique employed by the 5120. However a well designed dual/multiple mixer system will outperform this instrument. A well designed zero crossing detector can easily exceed the resolution of virtually any available ADC. 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] Of rubidium life and piggy-bank anemia....
In message <[EMAIL PROTECTED]>, Hal Murr ay writes: >Would digital inputs be good enough? Suppose you feed several 10 MHz signals >into a FPGA and program it so each input signal drives a counter. Ignoring >implementation details like synchronization, is that good enough to be >interesting? I'm assuming you have a PC that grabs all the counters every N >ticks/seconds/hours/whatever. I did this 10 years ago and there are good and bad ways to do it. (http://phk.freebsd.dk/pubs/timecounter.pdf) "ignoring implementation details like synchronization" is like shipping & handling: it will get you both ways. What you want to do is this: A master counter 26-32 bits, running off your chosen frequency source. (mine ran 26 bit at 100 MHz in an XC6200) For each signal, a latch that latches the master counter and can be read out, somehow. One pseudo-signal, that you trigger from the computer, so that you can synchronize the computer clock with the master latch: t1 = getnanotime(); tickle latch; t2 = getnanotime(); read latch; t3 = getnanotime(); do math of your choice. If a source is low frequency (power-grid, 1PPS etc), just put three latches in sequence on the signal, clocked by the master frequency, that takes care of meta-stability. If a source is high frequency, put an async prescaler/divider in front of the anti-meta-stability latches. If you are doing this on a PCI board, things are a lot simpler if your "chosen frequency source" is the PCI clock. But that means that you will have to build a more elaborate mathematical model, since you have a unstable transfer frequency. Input noise resulted in about +/- 2LSB noise in my case, with very rube goldberg-esque input circuits, spend some time on that. Metastability will always get you +/- 1LSB noise, but it may not be distributed evenly over that interval, so averaging is not a perfect solution. (Most of the assymetry is polarity based, so you could feed the same signal to two latches on opposite polarities and see if you can eliminate it that way). By all means: go for it, its a very fun project. And if you do it as a PCI card, please share the source :-) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Of rubidium life and piggy-bank anemia....
Whilst it is difficult to achieve a jitter of 100ps or less when an FPGA has multiple clocks, achieving a jitter of less than a few nanosec is relatively easy. When time stamping the zero crossings of the beat waveform in a dual (or multiple ) mixer system with an offset source a resolution of 10ns or so is adequate as long as the beat frequency is around 10Hz or less. To achieve the same system resolution with higher beat frequencies such as 1kHz requires timestamp resolutions of a few tens of picosec, whilst possible, it is complex and expensive to implement. High beat frequencies like 1kHz also require either a custom low noise offset OCXO or a complex offset generator. Beat frequency of up to 10Hz or so can be easily achieved by mechanically tuning a 10811 or similar OCXO. With a 10MHz mixer input frequency (RF and LO ports), 10Hz beat frequency and 10ns time stamp resolution a system resolution of around 1E-14/tau is achievable provided the mixer, RF cables and distribution amplifier temperatures are held constant to 0.01C or better. Otherwise mixer phase drift (a few ps/C) distribution amplifier phase drift (1 -100ps/C or more depending on the implementation) and RF cable phase shift tempcos will limit the achievable performance for longer averaging times. Using higher ft lower capacitance devices in the distribution amplifiers will reduce the phase shift tempco as will using higher mixer input frequencies and tuning the mixer input matching ciruitry to reduce the mixer input VSWR. Both the mixer RF and LO ports should be driven into saturation to maximise the system maximum SNR. NIST produced a dual mixer system in 1976 that had a resolution of about 1E-13/tau for small tau. 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] Of rubidium life and piggy-bank anemia....
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Hal Murr > ay writes: > > >> Would digital inputs be good enough? Suppose you feed several 10 MHz >> signals >> into a FPGA and program it so each input signal drives a counter. Ignoring >> implementation details like synchronization, is that good enough to be >> interesting? I'm assuming you have a PC that grabs all the counters every N >> ticks/seconds/hours/whatever. >> > > I did this 10 years ago and there are good and bad ways to do it. > (http://phk.freebsd.dk/pubs/timecounter.pdf) > > "ignoring implementation details like synchronization" is like > shipping & handling: it will get you both ways. > > What you want to do is this: > > A master counter 26-32 bits, running off your chosen frequency source. > (mine ran 26 bit at 100 MHz in an XC6200) > > For each signal, a latch that latches the master counter and can be > read out, somehow. > > One pseudo-signal, that you trigger from the computer, so that you > can synchronize the computer clock with the master latch: > > t1 = getnanotime(); > tickle latch; > t2 = getnanotime(); > read latch; > t3 = getnanotime(); > do math of your choice. > > If a source is low frequency (power-grid, 1PPS etc), just put three > latches in sequence on the signal, clocked by the master frequency, > that takes care of meta-stability. > > If a source is high frequency, put an async prescaler/divider in > front of the anti-meta-stability latches. > > If you are doing this on a PCI board, things are a lot simpler if > your "chosen frequency source" is the PCI clock. But that means > that you will have to build a more elaborate mathematical model, > since you have a unstable transfer frequency. > > Input noise resulted in about +/- 2LSB noise in my case, with > very rube goldberg-esque input circuits, spend some time on > that. > > Metastability will always get you +/- 1LSB noise, but it may > not be distributed evenly over that interval, so averaging is > not a perfect solution. (Most of the assymetry is polarity > based, so you could feed the same signal to two latches on > opposite polarities and see if you can eliminate it that way). > > By all means: go for it, its a very fun project. > > And if you do it as a PCI card, please share the source :-) > > Poul-Henning > > You don't actually require a latch for each input as long as flag bits (one per input channel) are used to denote which transitions occurred at the latched count. The flag bits should be latched along with the count. Using a PCI card is perhaps a recipe for planned obsolescence. If the input transition rates are relatively low (eg with PPS inputs) then an onboard microprocessor with a serial port has more than sufficient bandwidth to keep up. Alternatively just embed the microprocessor and its memory in the gate array as this simplifies the PCB layout considerably. Just ensure the counter length is great enough to ensure that it cant rollover more than once between successive input transitions. 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] Of rubidium life and piggy-bank anemia....
In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >You don't actually require a latch for each input as long as flag bits >(one per input channel) are used to denote which transitions occurred at >the latched count. >The flag bits should be latched along with the count. The latches are for resolving meta-stability issues between the two clock domains. >Using a PCI card is perhaps a recipe for planned obsolescence. >If the input transition rates are relatively low (eg with PPS inputs) >then an onboard microprocessor with a serial port has more than >sufficient bandwidth to keep up. Yes, but using a PCI card makes it possible to use the setup as timebase for your computer as well :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Of rubidium life and piggy-bank anemia....
If you need higher resolution than achievable with a gate array but lower than that achievable with a dual mixer system then, a pipeline ADC (per channel) and a low pass filter can be used to achieve a resolution of 100ps or better. Just low pass filter the input transitions so that the transition times (rise and fall) are about 3 or 4 ADC sampling clock periods. Then by processing the ADC samples the transition can be timestamped with a resolution of better than 1/100 of the ADC clock period. Just count the ADC samples that aren't close to the transition and process a small number around the transition to perform the interpolation. One method is to subtract the ADC sample taken say 4 clocks ago from the current one transforming the transition to a pulse and calculate the location of the pulse centroid. Do this for all ADC samples (in hardware using a gate array or a suitable DSP) if the difference is too small just count the samples. If the ~ 8 sample differences of interest are logged along with the sample count corresponding to the first sample difference then the PC can be used to calculate the centroid position. With a 100MHz ADC sampling clock a resolution of a few tens (20-30) psec should be achievable. The low pass filter need not be more elaborate than either an RC filter, or an LC filter, using low tempco components. 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] Of rubidium life and piggy-bank anemia....
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: > > >> You don't actually require a latch for each input as long as flag bits >> (one per input channel) are used to denote which transitions occurred at >> the latched count. >> The flag bits should be latched along with the count. >> > > The latches are for resolving meta-stability issues between the two > clock domains. > > You still dont need a dedicated time count latch for each channel. A pair of time count latches should suffice (one for each counter/synchroniser clock transition polarity) plus a flag bit for each channel. Latch the flag bits and the count in both sets of latches. >> Using a PCI card is perhaps a recipe for planned obsolescence. >> If the input transition rates are relatively low (eg with PPS inputs) >> then an onboard microprocessor with a serial port has more than >> sufficient bandwidth to keep up. >> > > Yes, but using a PCI card makes it possible to use the setup as > timebase for your computer as well :-) > > It can also add considerable ground noise potentially corrupting otherwise clean signals. 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] Of rubidium life and piggy-bank anemia....
In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >Poul-Henning Kamp wrote: >You still dont need a dedicated time count latch for each channel. >A pair of time count latches should suffice (one for each >counter/synchroniser clock transition polarity) plus a flag bit for each >channel. >Latch the flag bits and the count in both sets of latches. Nice theory, but if you try to compare say, to GPS receivers which are very good, that doesn't work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Of rubidium life and piggy-bank anemia....
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: > >> Poul-Henning Kamp wrote: >> > > >> You still dont need a dedicated time count latch for each channel. >> A pair of time count latches should suffice (one for each >> counter/synchroniser clock transition polarity) plus a flag bit for each >> channel. >> Latch the flag bits and the count in both sets of latches. >> > > Nice theory, but if you try to compare say, to GPS receivers which > are very good, that doesn't work. > > Please explain why this doesnt work. You surely have stored exactly the same information just in a different format. If you use 2 synchronisers, one clocked by the negative slope transition of the counter clock and the other by the positive slope transition of the counter clock, then the output of one synchroniser will be accurate /reliable, the problem is deciding which to use for any given sycnhroniser input transition. If one uses an interpolator then the correct synchroniser output can be determined (this has been done successfully), however this just offloads the problem to the interpolator. In any case with a well designed synchroniser the failure rate can be extremely low (Once in a billion years or longer with a PPS signal and a 100MHz clock). 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] Of rubidium life and piggy-bank anemia....
In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >Poul-Henning Kamp wrote: >Please explain why this doesnt work. I tried it :-) Read up on meta-stability in FPGAs somewhere on the web. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Of rubidium life and piggy-bank anemia....
Magne, I had thrown in my claim over the TCH more to continue this funny thread. But now that you take it seriously I must confess that I have been thinking in the last weeks and months about a multi-input time tagging event counter. With todays fpgas it should not be too difficult to design a SOC (System On Chip) that includes 1) a number of inputs, say 8 or so that can accept 1pps signals or frequencies between 1 HZ and say 50 MHz with programmable dividers to make 1 pps signals out of the extrenally applied frequencies. Naturally the inputs would need logic levels which are easily given with 1 pps. For applying sinusoidal signals an external clock shaper as published by Bruce would be needed. 2) One input for the reference frequency of 10 MHz. Using the onchip dcm availbale in the fpga today, an internal frequency of 200-250 Mhz phase locked to the reference can be generated giving a coarse time resolution of 4-5 ns. This clock is expected to have a jitter of 40-60 ps and is applied to a 64 bit counter to make the "coarse" part of the time tag. 3) For each 1 pps signal there is a interpolator of its own. The interpolator is a tapped delay line made out of fast logic elements. On the positive slope of the 1pps the contents of the main reference counter is latched into a 64 bit latch of its own. In addition the interpolator is triggered to make a "photograph" of what the main clock signal was like in terms of time delay against the triggering slope. I intend to make the delay line that long that several periods of the main clock are to be seen within the delay line. This will allow not only an in situ calibration of the delay line (we need to know the average delay per logic element) but also to use not only ONE positive slope of the clock but a number, say 3 or 4. This, in conjunction with the dither introduced by the clock jitter, should give a an overall averaged "fine" result with an resolution better than 100 ps. 4) Since some form of intelligence is needed to handle everything the device features a 32 bit risc controller. This contoller receives an interrupt whenever one of the 1 pps takes place. It will then read out the coarse and the fine result for this pps, compute around a bit with the values and spit out an result in MJD over a rs232 line. This controller will also listen to control commands coming over the rs232 that set the divider ratio for the inputs, initialize the MJD setting and perhaps some other things. Everthing described above can be realized today in a chip that sells for 30.00 US $ in single quantity. Now comes the bad news: The ram for the built in risc controller must be realized externally. That also applies to the controller's code which must be stored non-volatile. The fpga needs an configuration chip. The fpga needs at least 3 very clean supply voltages. That all makes it NOT a real SOC system but to a system out of 4-5 chips partly in nasty 208 pin flat packs. The whole thing cannot be built without having a precision pcb for it. That makes the whole project much more complex and elaborate to just handle it along the way. For that reason I have decided to buy me this smart device and experiment with it: http://www.enterpoint.co.uk/moelbryn/darnaw1.html This one does include everything that is needed and some more and will allow to breadboard the rest of the circuit. Will keep the group informed about any progress of that project. Best regards Ulrich Bangert > -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Magne Mahre > Gesendet: Freitag, 30. November 2007 14:55 > An: Discussion of precise time and frequency measurement > Betreff: Re: [time-nuts] Of rubidium life and piggy-bank anemia > > > Ulrich Bangert wrote: > > Use the three-cornered-hat method to rank your clocks! > > The literature seems to say that you need to do the > measurements simultanously to get good results from the TCH > method. I guess most of us have only one TIC at home, so I > wonder how the results will be affected by taking them one at a time ? > > --Magne > > ___ > 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] Of rubidium life and piggy-bank anemia....
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: > >> Poul-Henning Kamp wrote: >> > > >> Please explain why this doesnt work. >> > > I tried it :-) > Not very effectively. > Read up on meta-stability in FPGAs somewhere on the web. > Explain why?? If you mean that the asymmetry depends on the input signal transition slope then you still dont need a dedicated pair of count latches for each input. Just a set of flags to indicate from with which channels and slopes the latched count is associated with. 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] Of rubidium life and piggy-bank anemia....
In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >Explain why?? The signal you are trying to measure, for instance a 1PPS may transistion right at the same time the FPGA clock does, that means that the latch-bit may or may not make up it's mind about the state, but usually, it will oscillate for some period. The standard prescription for this, is to feed the input signal through a sequence of three latch-bits, clocked by the master clock, in order to get it synchronized to the master clock. Once it's synchronized, you can use it to latch the counter value without any trouble. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Of rubidium life and piggy-bank anemia....
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: > > >> Explain why?? >> > > The signal you are trying to measure, for instance a 1PPS may > transistion right at the same time the FPGA clock does, that means > that the latch-bit may or may not make up it's mind about the > state, but usually, it will oscillate for some period. > > The standard prescription for this, is to feed the input signal > through a sequence of three latch-bits, clocked by the master clock, > in order to get it synchronized to the master clock. > > Once it's synchronized, you can use it to latch the counter value > without any trouble. > > Poul As I suspected we had our wires crossed, I was talking about the counter value latches not the synchroniser latches /D-flipflops. 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] Of rubidium life and piggy-bank anemia....
Didier Juges said the following on 12/01/2007 12:56 AM: > Maybe quasi-simultaneously is adequate, using a switch to sample the 3 pairs > in rotation. > > The HP59307A can be used for that under GPIB control. If anybody's interested, I have a perl script (running under Linux, using the linux-gpib tools) that controls a 59307A and HP 5334A to do long-term logging of four PPS sources against each other. It takes a 100 second average of each PPS source sequentially; I end up with six log files, each with a tau of 600 seconds: CS1-GPS, CS2-GPS, RB1-GPS, CS1-CS2, CS1-RB1, and CS2-RB1. If anyone's interested, I'd be happy to make that program available, though it's not polished up for distribution. The data files from this program are the basis for phase and adev plots at http://www.febo.com/plots/ which are updated hourly. The software that generates those plots is called stable-stats and is available for download at http://www.febo.com/time-freq/tools/. (Unfortunately, at the moment the plots are out of date as we had a power failure last week and I don't have the clocks reset yet; that's a project for this weekend.) John ___ 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] Of rubidium life and piggy-bank anemia....
John, I knew we had that conversation before, you gave me your scripts when I was writing my Visual Basic program to do the same thing under Windows. This program is in a perpetual state of being messed with to reach ever changing objectives, but I have been using it for various logging experiments. I bought my HP 59307A for something like $10 on eBay. Didier > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Ackermann N8UR > Sent: Saturday, December 01, 2007 7:35 AM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia > > Didier Juges said the following on 12/01/2007 12:56 AM: > > Maybe quasi-simultaneously is adequate, using a switch to > sample the 3 > > pairs in rotation. > > > > The HP59307A can be used for that under GPIB control. > > If anybody's interested, I have a perl script (running under > Linux, using the linux-gpib tools) that controls a 59307A and > HP 5334A to do long-term logging of four PPS sources against > each other. > > It takes a 100 second average of each PPS source > sequentially; I end up with six log files, each with a tau of > 600 seconds: CS1-GPS, CS2-GPS, RB1-GPS, CS1-CS2, CS1-RB1, and CS2-RB1. > > If anyone's interested, I'd be happy to make that program > available, though it's not polished up for distribution. > > The data files from this program are the basis for phase and > adev plots at http://www.febo.com/plots/ which are updated > hourly. The software that generates those plots is called > stable-stats and is available for download at > http://www.febo.com/time-freq/tools/. (Unfortunately, at the > moment the plots are out of date as we had a power failure > last week and I don't have the clocks reset yet; that's a > project for this weekend.) > > John > > ___ > 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] Of rubidium life and piggy-bank anemia....
From: Bruce Griffiths <[EMAIL PROTECTED]> Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia Date: Sun, 02 Dec 2007 01:01:53 +1300 Message-ID: <[EMAIL PROTECTED]> > Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: > > > >> Poul-Henning Kamp wrote: > >> > > > > > >> Please explain why this doesnt work. > >> > > > > I tried it :-) > > > Not very effectively. > > Read up on meta-stability in FPGAs somewhere on the web. > > > Explain why?? > > If you mean that the asymmetry depends on the input signal transition > slope then you still dont need a dedicated pair of count latches for > each input. > Just a set of flags to indicate from with which channels and slopes the > latched count is associated with. It is well established that for FPGAs you want to clock the signal through two DFFs before using it whenever you handle asynchronous signals or signals from another clock domain. It is common practice and we also every now and then see that we indeed get problems when we have missed to use that common practice. Xilinx Application Note 94 "Metastable Recovery in Virtex-II Pro FPGAs" by Peter Alfke covers the issue: http://www.xilinx.com/support/documentation/application_notes/xapp094.pdf You can get away without a double DFF if you consider then next level FF as the second DFF. Routing delay must be tighter thought. If you are not running at higher clockrates you can also cheat. However, inside a modern FPGA for the kind of application we are talking, not adding a second DFF is just plain foolishness. It should be noted that the DFFs of FPGAs should not be considered as straight replacements of their separate CMOS, TTL or ECL sibblings as they have been designed for a mostly synchronous world. I would not dream of doing a design without double DFFs for asynchronous signals unless I was making cleaver use of other DFFs. 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.
Re: [time-nuts] Of rubidium life and piggy-bank anemia....
Bruce, I think there may still be a problem if you only have one counter latch and a tag to indicate which input's data is in the latch, aside from metastability issues. If two of the signals you want to compare are very close in timing, there may not be enough time for the processing logic to collect the data from the first pulse before the second one comes along. As Poul pointed out, if you compare two GPSDOs that are a few nS apart (or less), that puts a new strain on the logic collecting data. If each input has its own counter latch and you are measuring PPS signals, you have a whole second to process the data. I guess there could be an issue with multiple counter latches that propagation time within the device may not be the same for all inputs, and calibration (and possibly temperature compensation of that delay spread) might become necessary? Didier > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Griffiths > Sent: Saturday, December 01, 2007 6:40 AM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia > > Poul > > As I suspected we had our wires crossed, I was talking about > the counter value latches not the synchroniser latches /D-flipflops. > > 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] Of rubidium life and piggy-bank anemia....
From: "Didier Juges" <[EMAIL PROTECTED]> Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia Date: Sat, 1 Dec 2007 08:18:44 -0600 Message-ID: <[EMAIL PROTECTED]> > Bruce, > > I think there may still be a problem if you only have one counter latch and > a tag to indicate which input's data is in the latch, aside from > metastability issues. If two of the signals you want to compare are very > close in timing, there may not be enough time for the processing logic to > collect the data from the first pulse before the second one comes along. When you have two slow signals beating against each other, you can expect the runs of "very close" to be quite lengthy in time, so will also the time when they are "very far". Whatever time-stamping system you set up, you must be able to handle these cases equally well. The system where a single time-stamp value and a vector of time-stamped channels needs to handle case of lengthy time of full event rate for totally independent phases (i.e. resulting in separate event phases) and thus there is no real gain in reduction of event rate. If memory is an issue, then you can reduce the N-bit vector to a log(N)-bit vector by storing the channel number never the less. Such a system must be able to handle the burst event when there is a lengthy run of same or near timings. Different strategies can be used to acheive this, including small FIFOs per channel of time-stamp data or using the vector form as initial "wide" format for a common FIFO and then cut down on it. Considering the needed event rate needed usually the problem is not the aggregate event rate of N channels, but the burst rate at which they may come. Keeping separate event time latches per channel comes at a very low cost in modern FPGAs. 8 to 16 channels is not a real concern with even modest FPGAs. Since we are considering beat frequencies of 1 to 100 Hz or so, we are still talking a meager 1600 events per second. For the 100 Hz beat we can expect that the next event is at least 1 ms away and assuing an event timer at 100 MHz we have an event-tick of 10 ns. Collecting data from 16 channels into a common buffer memory one at a time then takes 160 ns, with alot of time twiddeling the thumbs until the next event. Thus a single event time per channel should suffice to keep worst-case burst among 16 channels from loosing data. It assumes that propper signal handling has been performed so that no bursts of events occurs on each channel. Poor through-zero gain comes to mind. 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.
Re: [time-nuts] Of rubidium life and piggy-bank anemia....
> You don't actually require a latch for each input as long as flag bits > (one per input channel) are used to denote which transitions occurred > at the latched count. A handful of 64 bit counters is not a big deal in modern FPGAs. > I think there may still be a problem if you only have one counter > latch and a tag to indicate which input's data is in the latch, aside > from metastability issues. If two of the signals you want to compare > are very close in timing, there may not be enough time for the > processing logic to collect the data from the first pulse before the > second one comes along. The standard solution for that sort of problem is a small buffer. The worst case is that all the input signals tick in sequential cycles so the PC doesn't have a chance to grab any of the data. For that, you need one slot in the buffer for each input signal. Consider the alternative of a counter per input signal. It also needs a buffer slot per input signal so you can grab all of the counters at the same time. I don't see how to use RAM as a buffer, but fortunately, modern FPGAs have lots of FFs. (The Spartan 3 -200 has 3940.) -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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] Of rubidium life and piggy-bank anemia....
Didier Juges wrote: > Bruce, > > I think there may still be a problem if you only have one counter latch and > a tag to indicate which input's data is in the latch, aside from > metastability issues. If two of the signals you want to compare are very > close in timing, there may not be enough time for the processing logic to > collect the data from the first pulse before the second one comes along. > > As Poul pointed out, if you compare two GPSDOs that are a few nS apart (or > less), that puts a new strain on the logic collecting data. If each input > has its own counter latch and you are measuring PPS signals, you have a > whole second to process the data. > > I guess there could be an issue with multiple counter latches that > propagation time within the device may not be the same for all inputs, and > calibration (and possibly temperature compensation of that delay spread) > might become necessary? > > Didier > Didier I forgot to mention a couple of salient points (it was rather late): 1) All the flags mentioned are synchronous being derived from the synchroniser outputs (one per channel). 2) The register is actually a synchronous FIFO. The depth of the FIFO (or shift register) can easily be made sufficient to allow one or more count values per channel to occur before the processor has to deal with them. Using a FIFO structure like this means that only one address needs to be read which can save time. Propagation delay tempco shouldnt be a significant issue as the resolution is the resolution is at best 1 counter clock period. 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] Of rubidium life and piggy-bank anemia....
Didier Juges wrote: > John, > > I knew we had that conversation before, you gave me your scripts when I was > writing my Visual Basic program to do the same thing under Windows. This > program is in a perpetual state of being messed with to reach ever changing > objectives, but I have been using it for various logging experiments. > > I bought my HP 59307A for something like $10 on eBay. > > Didier > > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of John Ackermann N8UR >> Sent: Saturday, December 01, 2007 7:35 AM >> To: Discussion of precise time and frequency measurement >> Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia >> >> Didier Juges said the following on 12/01/2007 12:56 AM: >> >>> Maybe quasi-simultaneously is adequate, using a switch to >>> >> sample the 3 >> >>> pairs in rotation. >>> >>> The HP59307A can be used for that under GPIB control. >>> >> If anybody's interested, I have a perl script (running under >> Linux, using the linux-gpib tools) that controls a 59307A and >> HP 5334A to do long-term logging of four PPS sources against >> each other. >> >> It takes a 100 second average of each PPS source >> sequentially; I end up with six log files, each with a tau of >> 600 seconds: CS1-GPS, CS2-GPS, RB1-GPS, CS1-CS2, CS1-RB1, and CS2-RB1. >> >> If anyone's interested, I'd be happy to make that program >> available, though it's not polished up for distribution. >> >> The data files from this program are the basis for phase and >> adev plots at http://www.febo.com/plots/ which are updated >> hourly. The software that generates those plots is called >> stable-stats and is available for download at >> http://www.febo.com/time-freq/tools/. (Unfortunately, at the >> moment the plots are out of date as we had a power failure >> last week and I don't have the clocks reset yet; that's a >> project for this weekend.) >> >> John >> >> ___ >> This technique creates the issue of how to correct for the effects of deadtime. 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] Of rubidium life and piggy-bank anemia....
Hal Murray wrote: >> You don't actually require a latch for each input as long as flag bits >> (one per input channel) are used to denote which transitions occurred >> at the latched count. >> > > A handful of 64 bit counters is not a big deal in modern FPGAs. > > > Bad idea, you should only be using a single counter with perhaps multiple registers to save the count. However a using a single address and a FIFO can save significant time when using a microprocessor to read/process the stored counter samples. > >> I think there may still be a problem if you only have one counter >> latch and a tag to indicate which input's data is in the latch, aside >> from metastability issues. If two of the signals you want to compare >> are very close in timing, there may not be enough time for the >> processing logic to collect the data from the first pulse before the >> second one comes along. >> > > The standard solution for that sort of problem is a small buffer. > > The worst case is that all the input signals tick in sequential cycles so the > PC doesn't have a chance to grab any of the data. For that, you need one > slot in the buffer for each input signal. > > Consider the alternative of a counter per input signal. It also needs a > buffer slot per input signal so you can grab all of the counters at the same > time. I don't see how to use RAM as a buffer, but fortunately, modern FPGAs > have lots of FFs. (The Spartan 3 -200 has 3940.) > > Such a solution adds the problem of ensuring all counters are synchronised or at least a means of determining their offsets. Much better to use a single counter with multiple count latches (or a FIFO wide enough to include channel event flags). 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] Of rubidium life and piggy-bank anemia....
From: Bruce Griffiths <[EMAIL PROTECTED]> Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia Date: Sun, 02 Dec 2007 09:36:14 +1300 Message-ID: <[EMAIL PROTECTED]> > This technique creates the issue of how to correct for the effects of > deadtime. If you only switches among the sources, then you don't have a dead time as such, it is just the time between the samples. You can make measures between N sources in a repeatable fashion with a normal 2-input TIC such that you get measures between all sources. For instance, if you have 5 sources, it takes 10 measures to measure all sources against all others. You can set up them such that you access each source so that you shift from one source to another and then stay with that for the next measure. In the case of 5 sources each source would be selected and de-selected twice in each cycle. If you use RF relays or ECL muxes is a choice. For a PPS rate dividing down 5 or 10 MHz sources to 20 Hz would allow for smart edge-selection to ensure an in-window edge even with slow drift relative the others. Such a setup would give you PPS rate updates for TIC values between all sources as straight measures (i.e. not indirect relative some other source, which would only consume 4 measures for 5 sources). No dead-time. When a slip from one 20 Hz cycle to another due to phase drift occurs, it can be handled in the software post-processing. The access-pattern would make the measures not perfectly fit as well as if you had multiple TICs on the task, but it would mostly be an issue for taus near tau0. 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.
Re: [time-nuts] Of rubidium life and piggy-bank anemia....
In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: You guys could save a lot of time if you read my paper where all this is described in detail: http://phk.freebsd.dk/pubs/timecounter.pdf -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Of rubidium life and piggy-bank anemia....
Bruce Griffiths said the following on 12/01/2007 03:36 PM: >>> It takes a 100 second average of each PPS source >>> sequentially; I end up with six log files, each with a tau of >>> 600 seconds: CS1-GPS, CS2-GPS, RB1-GPS, CS1-CS2, CS1-RB1, and CS2-RB1. > This technique creates the issue of how to correct for the effects of > deadtime. I've pondered this question, and I don't think there is a deadtime issue. I log one phase comparison every 600 seconds. It just happens that the one comparison is the average of 100 individual readings taken once per second; I'm not sure how that's any different (in terms of deadtime) than simply logging a single PPS-to-PPS comparison every 600 seconds. The actual time between comparisons is equal to the tau; it's not as though I'm getting one reading every two tau (as might be the case if reading a nominal 1 second phase difference every second). Even in generating the average, there's no dead time if the time interval is small in comparison to the repetition rate -- reading a phase of nominally 10 microseconds once per second leaves plenty of time for the counter to catch its breath. I use the 100 second average for two reasons: first, it results in a somewhat better resolution than the 2ns native of the HP-5334A TIC, which may or may not be meaningful in the ADEV calculation given the PPS noise. Second, it smooths the peak-to-peak noise, particularly from the GPS, and makes for smoother phase plots, particularly when one of the sources is GPS (I realize that 100 seconds isn't long enough to integrated out the GPS noise; when I do my long-term plots, I further reduce the data to tau = 1 hour and even tau = 1 day which is more meaningful). Am I missing something? John ___ 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] Of rubidium life and piggy-bank anemia....
John Ackermann N8UR said the following on 12/01/2007 04:07 PM: > I use the 100 second average for two reasons: first, it results in a > somewhat better resolution than the 2ns native of the HP-5334A TIC, > which may or may not be meaningful in the ADEV calculation given the PPS > noise. Second, it smooths the peak-to-peak noise, particularly from the > GPS, and makes for smoother phase plots, particularly when one of the > sources is GPS (I realize that 100 seconds isn't long enough to > integrated out the GPS noise; when I do my long-term plots, I further > reduce the data to tau = 1 hour and even tau = 1 day which is more > meaningful). By the way -- another reason I linger on each PPS pair for 100 seconds is to slow down the wear rate on the relays in the 59503A switch! They're good for millions of cycles, but why switch every 1 or 10 seconds when there isn't any measurement gain from doing so? And, if I'm going to sit in one place for 100 seconds, I may as well take 100 readings instead of just 1. :-) John ___ 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] Of rubidium life and piggy-bank anemia....
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: > > You guys could save a lot of time if you read my paper where all > this is described in detail: > > http://phk.freebsd.dk/pubs/timecounter.pdf > > Poul This paper addresses virtually none of the hardware design issues at all. If you actually use "latches" as shown in the diagram on page 8 where the latch sampling is enabled by the synchroniser output transition this is usually considered to be an example of bad design practice. The accepted technique would employ gated D flipflop registers where the synchroniser output transition is converted to a single clock cycle pulse employed as the enable for the gated D register which is continuously clocked by the counter (and synchroniser) clock. 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] Of rubidium life and piggy-bank anemia....
In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >> >> You guys could save a lot of time if you read my paper where all >> this is described in detail: >> >> http://phk.freebsd.dk/pubs/timecounter.pdf > >This paper addresses virtually none of the hardware design issues at all. That was not the main focus. The signals were indeed clocked through 3 D flipflops clocked on the global clock, to handle metastability, before they latched the count latches. I probably still have the VHDL somewhere... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Of rubidium life and piggy-bank anemia....
John Ackermann N8UR wrote: > John Ackermann N8UR said the following on 12/01/2007 04:07 PM: > > >> I use the 100 second average for two reasons: first, it results in a >> somewhat better resolution than the 2ns native of the HP-5334A TIC, >> which may or may not be meaningful in the ADEV calculation given the PPS >> noise. Second, it smooths the peak-to-peak noise, particularly from the >> GPS, and makes for smoother phase plots, particularly when one of the >> sources is GPS (I realize that 100 seconds isn't long enough to >> integrated out the GPS noise; when I do my long-term plots, I further >> reduce the data to tau = 1 hour and even tau = 1 day which is more >> meaningful). >> > > By the way -- another reason I linger on each PPS pair for 100 seconds > is to slow down the wear rate on the relays in the 59503A switch! > They're good for millions of cycles, but why switch every 1 or 10 > seconds when there isn't any measurement gain from doing so? And, if > I'm going to sit in one place for 100 seconds, I may as well take 100 > readings instead of just 1. :-) > > John > > John Deadtime issues only arise if one combines successive 100 second measurements separated by (N-1)x100 seconds. Finite relay lifetime is an issue if one is logging for months or years on end. 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] Of rubidium life and piggy-bank anemia....
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: > >> Poul-Henning Kamp wrote: >> >>> In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >>> >>> You guys could save a lot of time if you read my paper where all >>> this is described in detail: >>> >>> http://phk.freebsd.dk/pubs/timecounter.pdf >>> >> This paper addresses virtually none of the hardware design issues at all. >> > > That was not the main focus. > > The signals were indeed clocked through 3 D flipflops clocked on the > global clock, to handle metastability, before they latched the count > latches. > > I probably still have the VHDL somewhere... > > The point is that actually using latches in this way is considered poor design practice when crossing clock domains. 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] Of rubidium life and piggy-bank anemia....
In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >Poul-Henning Kamp wrote: >The point is that actually using latches in this way is considered poor >design practice when crossing clock domains. The latches do NOT span clock domains, they are in the same domain as the counter. The signals that make captures the counter value in the latch is synchronized to the global clock using 3 D flip-flops. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Of rubidium life and piggy-bank anemia....
The thorny issues of avoiding the noisy environment of a PC and its unstable PCI clock whilst still allowing a PC to be synchronised to an external timebase may perhaps be adressed by: Producing a simple PCI (or PCIe, or even ISA bus card - still widely used in industry) board that has a counter clocked by the PCI clock together with suitable registers used to time tag PCI bus reads etc as required by the PC software. If the counter rollover occurs at an approximately 1Hz rate then an optical (or equivalent isolation technique) can be used to produce an output isolated from the PC which can be used by an external multichannel high resolution time tagging instrument to time tag the counter rollover with a stable low noise timebase. This avoids compromising the high the performance of the resolution time tag instrument with the high noise PC environment and its relatively unstable PCI bus clock whilst still allowing the PC to be synchronised to a stable and accurate external timebase. With such a simple board plugged into the PCI (or PCIe , ISA) bus it should be easy and relatively inexpensive to produce a new one when moving to PCIe or its successors. The same external timestamping instrument can then be retained for years as PC buses come and go. The potential issue of obsolete communication standards is best addressed by using a separate board to implement the interface (LAN, USB, RS232 etc) which can be updated if and when required. Optical (serial port) or transformer (LAN) isolation can be used to isolate the timetag device from the noisy PC ground system whilst permitting communication between the PC and the instrument. 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] Of rubidium life and piggy-bank anemia....
In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >Poul-Henning Kamp wrote: >You are missing, the point using latches latched by the output of a >synchroniser is considered bad design practice you should use gated D >flipflops instead. I used what was available on the XC6200, that's all I had access to :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Of rubidium life and piggy-bank anemia....
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: > >> Poul-Henning Kamp wrote: >> > > > >> The point is that actually using latches in this way is considered poor >> design practice when crossing clock domains. >> > > The latches do NOT span clock domains, they are in the same domain > as the counter. > > The signals that make captures the counter value in the latch is > synchronized to the global clock using 3 D flip-flops. > > You are missing, the point using latches latched by the output of a synchroniser is considered bad design practice you should use gated D flipflops instead. 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] Of rubidium life and piggy-bank anemia....
In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >The thorny issues of avoiding the noisy environment of a PC and its >unstable PCI clock whilst still allowing a PC to be synchronised to an >external timebase may perhaps be adressed by: > >Producing a simple PCI (or PCIe, or even ISA bus card - still widely >used in industry) You don't need that. If you have an external timestamping device you can just generate any relevant signal from the PC (I prefer parallel ports, but they're going out of vogue) and time that relative to whatever clock your OS uses, then read back from your timestamping device (via USB ?) and calibrate accordingly. Modules cable-length and slope of your generating signal (EMI filtering), there is no difference in the resulting precision. BTW: I belive the NI PCI-66xx series of cards can be used also, but I've never actually tried, I only read the low-level doc. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Of rubidium life and piggy-bank anemia....
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: > > >> The thorny issues of avoiding the noisy environment of a PC and its >> unstable PCI clock whilst still allowing a PC to be synchronised to an >> external timebase may perhaps be adressed by: >> >> Producing a simple PCI (or PCIe, or even ISA bus card - still widely >> used in industry) >> > > You don't need that. > > If you have an external timestamping device you can just generate > any relevant signal from the PC (I prefer parallel ports, but they're > going out of vogue) and time that relative to whatever clock your > OS uses, then read back from your timestamping device (via USB ?) > and calibrate accordingly. > > Modules cable-length and slope of your generating signal (EMI > filtering), there is no difference in the resulting precision. > > BTW: I belive the NI PCI-66xx series of cards can be used also, > but I've never actually tried, I only read the low-level doc. > > That certainly sidesteps the PC bus obsolescence issue until suitable interfaces such as parallel ports and serial ports vanish never to be replaced. It would be relatively easy to include an optically isolated (or functional equivalent such as the Analog Devices chip scale transformer isolators) port on the external time stamp device for such an application. Since USB and Firewire ports may persist a little longer, is it possible to use similar techniques with these interfaces? Do you mean that the PCI66XX boards could be used to implement the multichannel timestamp function? If so then most of the issues associated with PC noise may be addressed by using a small external board that incorporates RF transformers and to break LF ground loops and has clock conditioning circuity to produce logic level clocks for the PCI66XX board from sinewave inputs. 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] Of rubidium life and piggy-bank anemia....
In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >Poul-Henning Kamp wrote: >Since USB and Firewire ports may persist a little longer, is it possible >to use similar techniques with these interfaces? For talking to the timestamping device: certainly. For signalling the computers time-edge: no way, they're serial protocols. >Do you mean that the PCI66XX boards could be used to implement the >multichannel timestamp function? Yes, they have counter and latches that I belive a suitable for at least two signals, but I'm not sure there were any usable prescalers. It was a long time ago. I'm not sure what kind of flanks plastic fibers (as used for instance from CD-players) have, I might go that route to get complete electrical separation. I saw a HP eval kit with 3' of plastic fiber and transmitter and receiver that would work great. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Of rubidium life and piggy-bank anemia....
Bruce Griffiths wrote: > Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: >> >> >> >>> The thorny issues of avoiding the noisy environment of a PC and its >>> unstable PCI clock whilst still allowing a PC to be synchronised to an >>> external timebase may perhaps be adressed by: >>> >>> Producing a simple PCI (or PCIe, or even ISA bus card - still widely >>> used in industry) >>> >>> >> You don't need that. >> >> If you have an external timestamping device you can just generate >> any relevant signal from the PC (I prefer parallel ports, but they're >> going out of vogue) and time that relative to whatever clock your >> OS uses, then read back from your timestamping device (via USB ?) >> and calibrate accordingly. >> >> Modules cable-length and slope of your generating signal (EMI >> filtering), there is no difference in the resulting precision. >> >> BTW: I belive the NI PCI-66xx series of cards can be used also, >> but I've never actually tried, I only read the low-level doc. >> >> >> > That certainly sidesteps the PC bus obsolescence issue until suitable > interfaces such as parallel ports and serial ports vanish never to be > replaced. > It would be relatively easy to include an optically isolated (or > functional equivalent such as the Analog Devices chip scale transformer > isolators) port on the external time stamp device for such an application. > > Since USB and Firewire ports may persist a little longer, is it possible > to use similar techniques with these interfaces? > > Do you mean that the PCI66XX boards could be used to implement the > multichannel timestamp function? > If so then most of the issues associated with PC noise may be addressed > by using a small external board that incorporates RF transformers and to > break LF ground loops and has clock conditioning circuity to produce > logic level clocks for the PCI66XX board from sinewave inputs. > > Bruce > After reading the PCI 66xx datasheets, it would appear that the external board should also include a synchronous programmable PPS divider for each channel. Since the number of available clocks is limited in an FPGA it may be best to use a single FPGA per channel, this also avoids crosstalk between channels allowing the dividers to be used effectively with higher resolution time stamp instruments when this is useful. 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] Of rubidium life and piggy-bank anemia....
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: > >> Poul-Henning Kamp wrote: >> > > >> Since USB and Firewire ports may persist a little longer, is it possible >> to use similar techniques with these interfaces? >> > > For talking to the timestamping device: certainly. For signalling > the computers time-edge: no way, they're serial protocols. > > >> Do you mean that the PCI66XX boards could be used to implement the >> multichannel timestamp function? >> > > Yes, they have counter and latches that I belive a suitable for > at least two signals, but I'm not sure there were any usable > prescalers. It was a long time ago. > > My understanding is that the prescalers are only useful for dividing the clock frequency down to a frequency that is sufficiently low for the counters. These boards are now available in 2, 4 and 8 channel versions. Their industrial counter timer boards have a maximum external clock frequency of 400Khz and a minimum pulse width of 1us, so thes may be less suitable. > I'm not sure what kind of flanks plastic fibers (as used for instance > from CD-players) have, I might go that route to get complete > electrical separation. > > I have 3 HP (now Avago technologies) 5 Mbaud glass fibre transmitter/receiver evaluation kits, I must get around to measuring their jitter and delay tempcos. However for low resolution time stamping (10ns resolution) they (and their plastic fibre cousins) should be perfectly adequate. Jitter may be a little high (for some purposes) when the timestamp resolution is 100ps or so. > I saw a HP eval kit with 3' of plastic fiber and transmitter and > receiver that would work great. > > > 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] Of rubidium life and piggy-bank anemia....
> Bad idea, you should only be using a single counter with perhaps > multiple registers to save the count. However a using a single address > and a FIFO can save significant time when using a microprocessor to > read/process the stored counter samples. I think we may be looking at two different problems. Your approach makes sense when looking at PPS signals. I was thinking of looking at several 10 MHz signals. It would be easy to convert 10 MHz to a PPS signal with a big divider. (Some other scale factor may be more convenient.) I was just going to count cycles. No good reason, but it seemed easy to do and I thought/hoped it had enough information to be useful. I was assuming the FPGA had a 100 MHz clock - anything significantly faster than the signal you are looking at. First run the 10 MHz signals through a synchronizer. Then bump a counter on each rising edge. Another signal would grab copies of all the counters. That could be either a poke from a PC or something handy like a PPS signal. The PC would then read the counters. If the PC does the poke, there are no timing requirements. If the PC is slow you may not get what you wanted, but the data within each sample will be consistent. If you do the poke with a PPS, you probably want another register that counts pokes. The PC can then read it at the beginning and end of grabbing the data. If the two copies are different you had timing troubles. Dump that sample. Comparing the poke-count between samples tells you when you missed some samples. I was thinking of "grab" as PCI reads. You could also send the samples out over RS232. (A checksum on the line seems like a good idea.) -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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] Of rubidium life and piggy-bank anemia....
Hal Murray wrote: >> Bad idea, you should only be using a single counter with perhaps >> multiple registers to save the count. However a using a single address >> and a FIFO can save significant time when using a microprocessor to >> read/process the stored counter samples. >> > > I think we may be looking at two different problems. > > Your approach makes sense when looking at PPS signals. > > I was thinking of looking at several 10 MHz signals. > > It would be easy to convert 10 MHz to a PPS signal with a big divider. (Some > other scale factor may be more convenient.) > > I was just going to count cycles. No good reason, but it seemed easy to do > and I thought/hoped it had enough information to be useful. > > > I was assuming the FPGA had a 100 MHz clock - anything significantly faster > than the signal you are looking at. First run the 10 MHz signals through a > synchronizer. Then bump a counter on each rising edge. > > Another signal would grab copies of all the counters. That could be either a > poke from a PC or something handy like a PPS signal. The PC would then read > the counters. > > If the PC does the poke, there are no timing requirements. If the PC is slow > you may not get what you wanted, but the data within each sample will be > consistent. > > If you do the poke with a PPS, you probably want another register that counts > pokes. The PC can then read it at the beginning and end of grabbing the > data. If the two copies are different you had timing troubles. Dump that > sample. Comparing the poke-count between samples tells you when you missed > some samples. > > I was thinking of "grab" as PCI reads. You could also send the samples out > over RS232. (A checksum on the line seems like a good idea.) > > > > > > There seems to be little point to this approach, neither NIST nor JPL use anything like this. This technique also has the undesirable side effect of increasing the synchroniser failure rate significantly. In most cases sampling the 10Mhz source phase every second or so (at the output of a PPS divider) is more than adequate for evaluating its stability over time intervals of 1 s or more. Your technique will not allow the phase variations of the 10MHz signals to be easily determined. The conventional approach adopted by NIST is to divide each frequency to be measured down to 1 PPS, then timestamp the PPS transitions for each channel as well as the PPS transitions from a GPS timing receiver. By using the same setup at NIST with their frequency standards most of the noise due to ionospheric delay variations is a common to both systems and is eliminated on subtraction. 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] Of rubidium life and piggy-bank anemia....
In message: <[EMAIL PROTECTED]> Bruce Griffiths <[EMAIL PROTECTED]> writes: : The conventional approach adopted by NIST is to divide each frequency to : be measured down to 1 PPS, then timestamp the PPS transitions for each : channel as well as the PPS transitions from a GPS timing receiver. By : using the same setup at NIST with their frequency standards most of the : noise due to ionospheric delay variations is a common to both systems : and is eliminated on subtraction. NIST has gone to an approach where the signal under test is heterodyned with a signal that's ~10Hz low. Since one cycle in the test frequency is one cycle in the heterdyned frequency, you can get measurements of signal down to the noise floor of your hardware (since even a simple 32MHz counter gives one several order of magnitude better than the noise in the zcds). At 10MHz, the heterodyne factor is 1e9. This means you can measure the phase difference of the signal to 31.5e-18 (assuming a 32MHz clock). Since the noise in the 32MHz oscillator is at 1e-13, we can measure the 10MHz down to a few parts 1e-13 (since the noise dominates over the resolution of the measurement). With a better oscillator, one can hit the noise floor of the ZCDs that we used in the project with a more stable 32MHz oscillator (down to 1e-14 or 5e-15 or so in some of the tests I ran in the lab). The 32MHz oscillator is a relatively cheap OCXO. The design of the system is such that almost all of the 32MHz noise subtracts out... The noise is such that switching to 100Hz gives a factor of 3 better noise floor. But any faster than that doesn't help much. A 2Hz signal is 5x worse noise floor because the 32MHz noise starts to dominate. With a good quality TIC, one is doing good to get PPS measurements in the picosecond level (1e-12). But that's a lot more expensive than the above device. At least that's what NIST is using to measure the cesiums in its clock ensemble. Warner ___ 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] Of rubidium life and piggy-bank anemia....
M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Bruce Griffiths <[EMAIL PROTECTED]> writes: > : The conventional approach adopted by NIST is to divide each frequency to > : be measured down to 1 PPS, then timestamp the PPS transitions for each > : channel as well as the PPS transitions from a GPS timing receiver. By > : using the same setup at NIST with their frequency standards most of the > : noise due to ionospheric delay variations is a common to both systems > : and is eliminated on subtraction. > > NIST has gone to an approach where the signal under test is > heterodyned with a signal that's ~10Hz low. Since one cycle in the > test frequency is one cycle in the heterdyned frequency, you can get > measurements of signal down to the noise floor of your hardware (since > even a simple 32MHz counter gives one several order of magnitude > better than the noise in the zcds). > > At 10MHz, the heterodyne factor is 1e9. This means you can measure > the phase difference of the signal to 31.5e-18 (assuming a 32MHz > clock). Since the noise in the 32MHz oscillator is at 1e-13, we can > measure the 10MHz down to a few parts 1e-13 (since the noise dominates > over the resolution of the measurement). With a better oscillator, > one can hit the noise floor of the ZCDs that we used in the project > with a more stable 32MHz oscillator (down to 1e-14 or 5e-15 or so in > some of the tests I ran in the lab). The 32MHz oscillator is a > relatively cheap OCXO. The design of the system is such that almost > all of the 32MHz noise subtracts out... The noise is such that > switching to 100Hz gives a factor of 3 better noise floor. But any > faster than that doesn't help much. A 2Hz signal is 5x worse noise > floor because the 32MHz noise starts to dominate. > > With a good quality TIC, one is doing good to get PPS measurements in > the picosecond level (1e-12). But that's a lot more expensive than > the above device. > > At least that's what NIST is using to measure the cesiums in its clock > ensemble. > > Warner > > Warner I was describing the approach adopted by NIST in their frequency measurement systems used to monitor OCXO frequencies at remote sites. The performance of this system is comparable to what one can achieve with a TIC having 100ps resolution and a good GPS receiver. The heterodyne factor is actually 1E6 with a 10Hz offset and a 10MHz mixer input frequency. So the resolution is around 3.125E-14/tau for a 32Mhz clock. JPL use an interpolation technique to reduce the noise contribution of the offset source when the corresponding mixer beat frequency output transitions for all channels are widely separated in time. However they are forced to use a magic 123 Hz beat frequency to get the best out of the commercial synthesizer they use for an offset source. A well designed ZCD can achieve a noise floor (due to mixer and ZCD noise) of less than 10ns even with an a 10Hz beat frequency. Most of the published ZCDs are far from optimal designs. The seminal paper on optimum ZCD design was published by Oliver Collins in an obscure publication (at least for the precision frequency measurement community). The principal limitations to the achievable system noise floor for large tau is the tempco of the mixer and isolation amplifier phase shifts. Interconnecting RF cable phase shifts may also be significant. The NIST 1976 dual mixer system used 10MHz inputs and a 10Hz offset system noise level was about 1E-13/tau, at least for small tau Currently 100MHz mixer input frequencies are favoured as the mixer phase shift (measured in ps/C) tempco is significantly lower with higher frequency inputs. Minimising the mixer LO and RF port VSWR also lowers the mixer phase shift tempco. Mixer IF port output noise is significantly reduced with capacitive rather than resistive termination. 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] Of rubidium life and piggy-bank anemia....
Paul, you may be surprised to hear that I had read your article before and yes, everything evolving from The Weinheim Tagung has usually a high s/n level as has your article! After I had read about the XILINX dcms about a year or so I had made me the same plan as you but never realized it. However, at that time I was in search for a TIC that would reach ns resolution or a bit below for use in a GPSDO to measure time differences with enough resolution so that the sawtooth error correction value of a modern GPS receiver makes really sense to apply. In this case I am interested in how far one can go with a modern fpga. I have alrady made me an delay line interpolator with a ALTERA chip using the very fast logic interconnections that the chip features for carry transport of adders. This one reached a resolution of 110 ps but the chip itself had many limitations. BTW: The way that I plan to use the dcms the jitter will be my friend and not my enemy because I hope that I can make use of it as kind of "dither". Your explanation of how the 5370 works is perfect and I wish I had read it some years before I managed to understnd the working principle by means of an old HP journal article written by Chu. 73 and my best regards Ulrich, DF6JB > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Paul Boven > Gesendet: Samstag, 1. Dezember 2007 22:55 > An: Discussion of precise time and frequency measurement > Betreff: Re: [time-nuts] Of rubidium life and piggy-bank anemia > > > Hi Ulrich, > > You might find the approach I used a few years a go > interesting, please > see attached paper. I hope you find the last pages > interesting. By the way, don't forget that DCM's cause jitter > themselves. > > Yours sincerely, Paul Boven. > > > ___ 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] Of rubidium life and piggy-bank anemia....
From: Bruce Griffiths <[EMAIL PROTECTED]> Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia Date: Sun, 02 Dec 2007 10:56:34 +1300 Message-ID: <[EMAIL PROTECTED]> > Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Bruce Griffiths writes: > > > >> Poul-Henning Kamp wrote: > >> > > > > > > > >> The point is that actually using latches in this way is considered poor > >> design practice when crossing clock domains. > >> > > > > The latches do NOT span clock domains, they are in the same domain > > as the counter. > > > > The signals that make captures the counter value in the latch is > > synchronized to the global clock using 3 D flip-flops. > > > > > You are missing, the point using latches latched by the output of a > synchroniser is considered bad design practice you should use gated D > flipflops instead. The problem is that he calles the DFFs latches. The problem with the term latches is that they sound like a good generic term, but really isn't. He would not be able to synthesize the design if there where a single latch in it. However, it is full of DFFs! 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.
Re: [time-nuts] Of rubidium life and piggy-bank anemia....
On Sun Dec 2 17:59 , Magnus Danielson <[EMAIL PROTECTED]> sent: >The problem is that he calls the DFFs latches. The problem with the term >latches is that they sound like a good generic term, but really isn't. At the risk of showing my ignorance, could I ask you to explain the difference please? > In message [EMAIL PROTECTED]>, Bruce Griffiths writes: > > The latches do NOT span clock domains, they are in the same domain > as the counter. Sorry again, could you briefly explain what is meant by "clock domains"? Thanks for your patience, Peter Vince ___ 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] Of rubidium life and piggy-bank anemia....
From: Peter Vince <[EMAIL PROTECTED]> Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia Date: Sun, 02 Dec 2007 19:26:46 + Message-ID: <[EMAIL PROTECTED]> > > On Sun Dec 2 17:59 , Magnus Danielson <[EMAIL PROTECTED]> sent: > > >The problem is that he calls the DFFs latches. The problem with the term > >latches is that they sound like a good generic term, but really isn't. > > At the risk of showing my ignorance, could I ask you to explain the difference > please? A latch is a device in which the enable input allows data to flow freely through the latch, much as a buffer, when the enable input is active. As the enable goes inactive, it retains the last input level (or what it perceived as the last input level considering metastability). A D flip-flop updates its output on the rising (or falling) edge of the clock input. > > In message [EMAIL PROTECTED]>, Bruce Griffiths writes: > > > > The latches do NOT span clock domains, they are in the same domain > > as the counter. > > Sorry again, could you briefly explain what is meant by "clock domains"? A clock domain is a group of logic and DFFs clocked by a common clock source. Within the clock-domain all logic transitions occur synchronously to the clock of the clock domain. For modern ASIC and FPGA designs this allows for a much simplified analysis when combined with the ban of latches, since all logic signals, gate delays and routing delays can be statically analyzed and this allows for powerfull automatic placement and routing mechanisms. The respecting the setup time prior to the clock edge avoids metastability, and the term slack refers to the margin to the setup time. Between clock domains we assume asynchronous aspects, meaning that we risc metastability cause upset of values. By having an asynchronous signal being clocked into the clock domain using two DFFs clocked with the clock domain clock, the metastability issue becomes virtually removed. When designing ASICs and FPGAs you specifically divide the design into clock domains and sometimes one chooses to clock signals into a higher clocks in order to avoid many different clock domains. For FPGAs you have a limited amount of clock networks, but for very small clock domains you can handle it through a local clock domain setup, but it is a bit trickier to handle. 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.
Re: [time-nuts] Of rubidium life and piggy-bank anemia....
Hi Magnus, Thanks for the explanations - it makes much more sense now. TTFN, Peter ___ 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.
