Re: [time-nuts] Performance verification for time counters
kb...@n1k.org said: > The gotcha with a DDS in this case are the sawtooth spurs. To get them down > to the 5 ps level, you would need a DDS with a clock that is well into the > 100âs of GHz. I think that assumes you want to be able to generate an arbitrary frequency. Suppose I start with 10 MHz. It's easy to get a clean 1 MHz or 5 MHz, but not so easy to get 3 MHz. But if I start with 9 MHz, I can get a clean 3 MHz. How do I figure out how many crystals I need? How good are PLLs relative to 5 ps? Can I use them to make pseduo-crystals? What's the term for PLLs where I divide the output by M and the reference by N? As M and N get bigger I get more possible output frequencies but the output of the phase comparator gets lower in frequency and hence harder to filter. How low can I go before 5 ps gets interesting? (Is that a reasonable question?) If I have an array of crystals and PLLs, I can get some more flexibility if the crystals are VXOs. -- These are my opinions. 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] Performance verification for time counters
Hi That’s certainly part of the issue. The fact that you are measuring a transfer function in the phase domain is another issue. Before this gets to nutty, there is indeed a “peaking” spec on things like a stratum 1 through 4 device. That also gets carried into the OCx domains as well. Since (as was pointed out at the start) you are worried about large groups of (possibly identical) units, the peaking numbers need to be mighty small. It only takes one question of the form “that’s a nice paper analysis … can you demonstrate it?” to head you off to (do me) silly testing programs. Bob > On Nov 29, 2017, at 9:08 PM, Tim Shoppa wrote: > > At that low a frequency aren’t you actually testing the temperature and time > stability of the gain controlling components? > > Tim N3QE > >> On Nov 29, 2017, at 9:04 PM, jimlux wrote: >> >>> On 11/29/17 5:53 PM, Bob kb8tq wrote: >>> HI On Nov 29, 2017, at 8:41 PM, jimlux wrote: On 11/29/17 3:41 PM, Bob kb8tq wrote: > Hi > Needless to say *demonstrating* this 0.001 db sort of gain flatness on a > repeater > out to crazy low frequencies is a bit involved. It *is* a great gig if > you happen to be > a consultant … > Bob demonstrating 0.001 dB (or would that really be 0.1 mB or 100 microBels) precision in *any* application is a bit involved. That's 0.03% >>> Yup, now do it at some silly low frequency ( 0.(some number of zeros)1 Hz >>> …. great way to waste a lot of time. >> >> >> That's a volt meter >> >> It's the "do it at 1 Hz and 10 MHz and every 1 Hz in between" that is the >> challenge. >> ___ >> 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] Performance verification for time counters
At that low a frequency aren’t you actually testing the temperature and time stability of the gain controlling components? Tim N3QE > On Nov 29, 2017, at 9:04 PM, jimlux wrote: > >> On 11/29/17 5:53 PM, Bob kb8tq wrote: >> HI >>> On Nov 29, 2017, at 8:41 PM, jimlux wrote: >>> >>> On 11/29/17 3:41 PM, Bob kb8tq wrote: Hi Needless to say *demonstrating* this 0.001 db sort of gain flatness on a repeater out to crazy low frequencies is a bit involved. It *is* a great gig if you happen to be a consultant … Bob >>> >>> >>> >>> demonstrating 0.001 dB (or would that really be 0.1 mB or 100 microBels) >>> precision in *any* application is a bit involved. That's 0.03% >>> >> Yup, now do it at some silly low frequency ( 0.(some number of zeros)1 Hz …. >> great way to waste a lot of time. > > > That's a volt meter > > It's the "do it at 1 Hz and 10 MHz and every 1 Hz in between" that is the > challenge. > ___ > 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] Performance verification for time counters
On 11/29/17 5:53 PM, Bob kb8tq wrote: HI On Nov 29, 2017, at 8:41 PM, jimlux wrote: On 11/29/17 3:41 PM, Bob kb8tq wrote: Hi Needless to say *demonstrating* this 0.001 db sort of gain flatness on a repeater out to crazy low frequencies is a bit involved. It *is* a great gig if you happen to be a consultant … Bob demonstrating 0.001 dB (or would that really be 0.1 mB or 100 microBels) precision in *any* application is a bit involved. That's 0.03% Yup, now do it at some silly low frequency ( 0.(some number of zeros)1 Hz …. great way to waste a lot of time. That's a volt meter It's the "do it at 1 Hz and 10 MHz and every 1 Hz in between" that is the challenge. ___ 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] Performance verification for time counters
HI > On Nov 29, 2017, at 8:41 PM, jimlux wrote: > > On 11/29/17 3:41 PM, Bob kb8tq wrote: >> Hi >> Needless to say *demonstrating* this 0.001 db sort of gain flatness on a >> repeater >> out to crazy low frequencies is a bit involved. It *is* a great gig if you >> happen to be >> a consultant … >> Bob > > > > demonstrating 0.001 dB (or would that really be 0.1 mB or 100 microBels) > precision in *any* application is a bit involved. That's 0.03% > Yup, now do it at some silly low frequency ( 0.(some number of zeros)1 Hz …. great way to waste a lot of time. Bob > > ___ > 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] Performance verification for time counters
On 11/29/17 3:41 PM, Bob kb8tq wrote: Hi Needless to say *demonstrating* this 0.001 db sort of gain flatness on a repeater out to crazy low frequencies is a bit involved. It *is* a great gig if you happen to be a consultant … Bob demonstrating 0.001 dB (or would that really be 0.1 mB or 100 microBels) precision in *any* application is a bit involved. That's 0.03% ___ 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] Wenzel VHF PLO Oscillators Off Frequency
With help from an number of people who responded, I have gotten the Wenzel oscillators to work and provide a frequency locked external clock to a Perseus SDR radio. I had to add an external clock input to the Perseus and describe it at: https://sites.google.com/site/perseusmods/ Mark W7MLG ___ 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] Performance verification for time counters
Hi The key point here is the term “demonstrating”. When you get to 0.001 Hz it takes more than just a little time. Not very compatible with a production line. Yes you *might* ask “would anybody ever want that demonstrated ? “. The answer is yes, there are people out the that need it demonstrated. It’s not cheap to do. Bob > On Nov 29, 2017, at 6:47 PM, Poul-Henning Kamp wrote: > > > In message <9793f6fa-cb78-4bf1-bc80-6b1a593fc...@n1k.org>, Bob kb8tq writes: > >> Needless to say *demonstrating* this 0.001 db sort of gain flatness on a >> repeater >> out to crazy low frequencies is a bit involved. It *is* a great gig if you >> happen to be >> a consultant ... > > No consultants were involved, they did it in mass production at WE. > > Remember, they needed thousands of repeaters per *coax* and there were > handfulls of coax'es in each cable. > > This is the relevant article about the amplitude: > > https://archive.org/details/bstj53-10-1935 > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | 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] Performance verification for time counters
In message <9793f6fa-cb78-4bf1-bc80-6b1a593fc...@n1k.org>, Bob kb8tq writes: >Needless to say *demonstrating* this 0.001 db sort of gain flatness on a >repeater >out to crazy low frequencies is a bit involved. It *is* a great gig if you >happen to be >a consultant ... No consultants were involved, they did it in mass production at WE. Remember, they needed thousands of repeaters per *coax* and there were handfulls of coax'es in each cable. This is the relevant article about the amplitude: https://archive.org/details/bstj53-10-1935 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | 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] Performance verification for time counters
Hi Needless to say *demonstrating* this 0.001 db sort of gain flatness on a repeater out to crazy low frequencies is a bit involved. It *is* a great gig if you happen to be a consultant … Bob > On Nov 29, 2017, at 6:36 PM, Poul-Henning Kamp wrote: > > > In message <409346f4-60e1-4cae-8602-84fb1c061...@n1k.org>, Bob kb8tq writes: > The HP3336 with its outstanding level-control is a much overlooked bargain for this kind of stuff. >>> >>> I looked for the manual, and it seems to have ROM feeding values to a DAC. >>> Is that not DDS? > > That is for the level control, not for generating the signal. > > The level control has a custom HP-chip with two matched thermal > converters, so you can compare the power of two signals with it. > > One signal is the RF output, the other comes from a DAC. > > The 3336 is as far as I know one of the the most precise instruments > when it comes to amplitude, and it was built specifically for the > last two generations of the Carrier Frequency Coax telephone network > (L4 and L5) where up to 10.800 4kHz telefone channels were stacked > over each other in a single coax cable. > > Because the top frequency were near 70 MHz, they needed a repeater > for every mile of cable which is up to 4000 repeaters for a call > across the US. > > If every one of those repeaters had a systematic dip of 0.01dB at > the same frequency, That would amount to 40dB attenuation in total, > so the amplitude tolerances were almost insane, in order to keep > the amount of equalizing manageable. > > Google: bstj53-10 site:archive.org > > It's an amazing story... > > The HP3336 and the HP3586 level meter go together to measure these > lines: The 3586 measures the received signal and when it is done > it tells the 3336 to step 4kHz up to the next channel. The crucial > trick is that the 3336 produces the exact same output level for all > 10800 channels. > > See: HPJ May 1980. > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | 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] Performance verification for time counters
In message <409346f4-60e1-4cae-8602-84fb1c061...@n1k.org>, Bob kb8tq writes: >>> The HP3336 with its outstanding level-control is a much >>> overlooked bargain for this kind of stuff. >> >> I looked for the manual, and it seems to have ROM feeding values to a DAC. >> Is that not DDS? That is for the level control, not for generating the signal. The level control has a custom HP-chip with two matched thermal converters, so you can compare the power of two signals with it. One signal is the RF output, the other comes from a DAC. The 3336 is as far as I know one of the the most precise instruments when it comes to amplitude, and it was built specifically for the last two generations of the Carrier Frequency Coax telephone network (L4 and L5) where up to 10.800 4kHz telefone channels were stacked over each other in a single coax cable. Because the top frequency were near 70 MHz, they needed a repeater for every mile of cable which is up to 4000 repeaters for a call across the US. If every one of those repeaters had a systematic dip of 0.01dB at the same frequency, That would amount to 40dB attenuation in total, so the amplitude tolerances were almost insane, in order to keep the amount of equalizing manageable. Google: bstj53-10 site:archive.org It's an amazing story... The HP3336 and the HP3586 level meter go together to measure these lines: The 3586 measures the received signal and when it is done it tells the 3336 to step 4kHz up to the next channel. The crucial trick is that the 3336 produces the exact same output level for all 10800 channels. See: HPJ May 1980. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | 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] Performance verification for time counters
In message <5e3f68620fdb8f2e5d62e9907a44c6eb.squir...@email.powweb.com>, "Chris Caudle" writes: >On Wed, November 29, 2017 3:51 pm, Poul-Henning Kamp wrote: >> While it is tempting and probably easiest to use a DDS style >> generator, I recommend a synthesized one instead, to avoid >> trouble with numeric spurs. > >Can you describe the distinction you are making between a synthesized >generator, and a direct-digital synthesized generator? I do not >understand what would be meant by a synthesizer which is not DDS. What used to be called a "Synthesized Signal Generator" was a almost or even entirely analog beast, which means almost all distortion is harmonic (2f, 3f, 4f, ...) This is a good place to start, in particular the App-note at the bottom: http://hpmemoryproject.org/news/5100/hp5100_page_00.htm DDS is "Direct Digital Synthesis" where you basically generate the desired signal with a computer and D/A converter. Because this discrete rather than continuous in time, there are all sorts of "weird" distortion products, and aliasing artifacts. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | 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] Performance verification for time counters
Hi There are a number of ways to build a synthesizer that do not involve a modern DDS architecture. The gotcha with a DDS in this case are the sawtooth spurs. To get them down to the 5 ps level, you would need a DDS with a clock that is well into the 100’s of GHz. Bob > On Nov 29, 2017, at 5:47 PM, Chris Caudle wrote: > > On Wed, November 29, 2017 3:51 pm, Poul-Henning Kamp wrote: >> While it is tempting and probably easiest to use a DDS style >> generator, I recommend a synthesized one instead, to avoid >> trouble with numeric spurs. > > Can you describe the distinction you are making between a synthesized > generator, and a direct-digital synthesized generator? I do not > understand what would be meant by a synthesizer which is not DDS. > >> The HP3336 with its outstanding level-control is a much >> overlooked bargain for this kind of stuff. > > I looked for the manual, and it seems to have ROM feeding values to a DAC. > Is that not DDS? > > -- > Chris Caudle > > > ___ > 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] Performance verification for time counters
On Wed, November 29, 2017 3:51 pm, Poul-Henning Kamp wrote: > While it is tempting and probably easiest to use a DDS style > generator, I recommend a synthesized one instead, to avoid > trouble with numeric spurs. Can you describe the distinction you are making between a synthesized generator, and a direct-digital synthesized generator? I do not understand what would be meant by a synthesizer which is not DDS. > The HP3336 with its outstanding level-control is a much > overlooked bargain for this kind of stuff. I looked for the manual, and it seems to have ROM feeding values to a DAC. Is that not DDS? -- Chris Caudle ___ 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] Performance verification for time counters
In message , Andy ZL3AG via time-nuts writes: >HP 5359A Time Synthesiser? If we're only talking 1PPS timestamping and nothing better and more flexible is available, then yes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | 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] Performance verification for time counters
Hi > On Nov 29, 2017, at 5:16 PM, Andy ZL3AG via time-nuts > wrote: > > > HP 5359A Time Synthesiser? 100 to 200 ps jitter …. he’s after <5 ps Bob > > > On 30/11/2017, at 10:24 AM, Leo Bodnar wrote: > >> I am looking for an established and widely accepted procedure for verifying >> performance of high resolution time counters. >> >> I have designed a time stamping counter for qualifying 1PPS signal >> performance against external reference (e.g. 10MHz master clock.) >> >> Simple design verification check I am doing at the moment is gating random >> selection of master clock edges back into device's signal input and letting >> the device measure this test signal offset against its reference clock - >> which, for ideal design, should result in zero offset (modulo 100ns.) My >> results are roughly in line with what I expect to see >> http://leobodnar.com/balloons/NTP/time-sampler-test1.png >> >> Now, what would be recognised procedure for sweeping external input pulse >> delay over few hundred ns in a controlled, measurable and repeatable way? >> >> I can see few naïve approaches: >> 1) Using selectively gated (or divided) reference clock followed by >> adjustable delay line. E.g. something like mechanically adjusted delay >> lines used in HP test sets. Or, perhaps, calibrated rigid coax sections? >> 2) Slightly offset another master clock (e.g. second Rb oscillator) gated in >> a similar way but without delay line, followed by statistical data analysis >> 3) Trusted pulse generator with high resolution delay adjustment fed from >> the same master clock as the counter >> >> I am looking for something with ~10ps accuracy, 100ns+ range, and reasonably >> low jitter (~5ps or better.) >> It is possible that the range needs to be split up (e.g. fixed rigid coax >> delay line followed by a mechanically adjust section.) >> >> This is a low budget fun project so something simple and common sense is >> preferred to "price on application" NIST traceable equipment. >> >> Thanks! >> Leo >> ___ >> 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] Performance verification for time counters
HP 5359A Time Synthesiser? On 30/11/2017, at 10:24 AM, Leo Bodnar wrote: > I am looking for an established and widely accepted procedure for verifying > performance of high resolution time counters. > > I have designed a time stamping counter for qualifying 1PPS signal > performance against external reference (e.g. 10MHz master clock.) > > Simple design verification check I am doing at the moment is gating random > selection of master clock edges back into device's signal input and letting > the device measure this test signal offset against its reference clock - > which, for ideal design, should result in zero offset (modulo 100ns.) My > results are roughly in line with what I expect to see > http://leobodnar.com/balloons/NTP/time-sampler-test1.png > > Now, what would be recognised procedure for sweeping external input pulse > delay over few hundred ns in a controlled, measurable and repeatable way? > > I can see few naïve approaches: > 1) Using selectively gated (or divided) reference clock followed by > adjustable delay line. E.g. something like mechanically adjusted delay lines > used in HP test sets. Or, perhaps, calibrated rigid coax sections? > 2) Slightly offset another master clock (e.g. second Rb oscillator) gated in > a similar way but without delay line, followed by statistical data analysis > 3) Trusted pulse generator with high resolution delay adjustment fed from the > same master clock as the counter > > I am looking for something with ~10ps accuracy, 100ns+ range, and reasonably > low jitter (~5ps or better.) > It is possible that the range needs to be split up (e.g. fixed rigid coax > delay line followed by a mechanically adjust section.) > > This is a low budget fun project so something simple and common sense is > preferred to "price on application" NIST traceable equipment. > > Thanks! > Leo > ___ > 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] Performance verification for time counters
l...@leobodnar.com said: > Now, what would be recognised procedure for sweeping external input pulse > delay over few hundred ns in a controlled, measurable and repeatable way? How about using another crystal at a slightly different frequency? Suppose you start with 10.01 MHz and divide by 1000. That will slowly sweep a pulse. All you have to do is reset the counter at the right time to get it started at the right phase. I think you can do something similar with a DDS type generator starting from an arbitrary frequency. It won't sweep in a simple ramp but will be a sawtooth pattern where the points on each tooth are at slightly different offsets that will fill in the whole space if you merge them together. -- These are my opinions. 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] Performance verification for time counters
Hi The “simple / easy / quick” approach is a pps generated by source with a small frequency offset. If your objective is 5 ps, both your reference and your offset source will need to do better than that. While that sounds like it’s specific to this technique, it’s actually a more general constraint. Just how hard this is depends a bit on your definition of jitter. Since you are looking at 1 second, ADEV with a tau = 1 second *might* be a reasonable measure. If it is, then you need two sources that are well below 5x10^-12 at one second. That eliminates most signal generators and many atomic standards. This gets you to using things like Masers or some pretty good OCXO’s. Tuning a Maser for a low offset is doable. Tuning an OCXO … maybe not so much. Bob > On Nov 29, 2017, at 4:24 PM, Leo Bodnar wrote: > > I am looking for an established and widely accepted procedure for verifying > performance of high resolution time counters. > > I have designed a time stamping counter for qualifying 1PPS signal > performance against external reference (e.g. 10MHz master clock.) > > Simple design verification check I am doing at the moment is gating random > selection of master clock edges back into device's signal input and letting > the device measure this test signal offset against its reference clock - > which, for ideal design, should result in zero offset (modulo 100ns.) My > results are roughly in line with what I expect to see > http://leobodnar.com/balloons/NTP/time-sampler-test1.png > > Now, what would be recognised procedure for sweeping external input pulse > delay over few hundred ns in a controlled, measurable and repeatable way? > > I can see few naïve approaches: > 1) Using selectively gated (or divided) reference clock followed by > adjustable delay line. E.g. something like mechanically adjusted delay lines > used in HP test sets. Or, perhaps, calibrated rigid coax sections? > 2) Slightly offset another master clock (e.g. second Rb oscillator) gated in > a similar way but without delay line, followed by statistical data analysis > 3) Trusted pulse generator with high resolution delay adjustment fed from the > same master clock as the counter > > I am looking for something with ~10ps accuracy, 100ns+ range, and reasonably > low jitter (~5ps or better.) > It is possible that the range needs to be split up (e.g. fixed rigid coax > delay line followed by a mechanically adjust section.) > > This is a low budget fun project so something simple and common sense is > preferred to "price on application" NIST traceable equipment. > > Thanks! > Leo > ___ > 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] Performance verification for time counters
In message <5602c647-1251-4d78-b82e-798bfcd8b...@leobodnar.com>, Leo Bodnar writes: >Now, what would be recognised procedure for sweeping external input pulse >delay over few hundred ns in a controlled, measurable and repeatable way? When I did this (20 years ago :-), I used a signal generator. Lock it to the same frequency as your reference signal, but set it for pure sine output slightly offset in frequency (10.10/9.90 MHz), so that your know your TI sweeps the entire window. Until you get a god "box" distribution, there is no need to do anything more complicated. Be aware that flaws in the box shape can come from either the sig-gen or your counter: This is basically a "vernier" style of measurement, and very few sources hold up to that kind of scrutiny. Next run as high a sampling rate as your device supports and look for samples which "leap-frog" each other, in theory you should have none. Next, siggen=ref frequency, but adjust the phase (relative to the common clock reference) and the amplitude, and see if the zero-crossings behave the way you expect. In particular check if the noise (= stddev) is even throughout the window. Finally you can use PM/AM/FM modulation with different shapes (triangle, square, sine etc) and idicies of modulation, in each case you can calculate what distribution to expect. While it is tempting and probably easiest to use a DDS style generator, I recommend a synthesized one instead, to avoid trouble with numeric spurs. The HP3336 with its outstanding level-control is a much overlooked bargain for this kind of stuff. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | 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] Performance verification for time counters
Hi Leo, On 11/29/2017 10:24 PM, Leo Bodnar wrote: I am looking for an established and widely accepted procedure for verifying performance of high resolution time counters. Now, what would be recognised procedure for sweeping external input pulse delay over few hundred ns in a controlled, measurable and repeatable way? I can see few naïve approaches: 1) Using selectively gated (or divided) reference clock followed by adjustable delay line. E.g. something like mechanically adjusted delay lines used in HP test sets. Or, perhaps, calibrated rigid coax sections? This is not very useful in practice, except for certain tests. 2) Slightly offset another master clock (e.g. second Rb oscillator) gated in a similar way but without delay line, followed by statistical data analysis Using an oscillator to syntesize a somewhat offset frequency works very well and is established. If you have a frequency synthesizer that you can lock to 10 MHz you should be just fine. If you set it to 9,999 MHz the period will be 100,010 ns, that is 10 ps larger than the 10 MHz. While you may not trigger on each occurrence, the time difference sweeps through the full range of time relationships within 1 ms and then it re-occurs. By collecting lots of samples, you can histogram in 10 ps bins and make analysis. It is also trivial to measure RMS performance. Set the synthesis for 9, MHz for 1 ps sweep. Proven in battle. You can use relatively cheap equipment for this. Some relatively cheap DDS-board may pull this off too. 3) Trusted pulse generator with high resolution delay adjustment fed from the same master clock as the counter This works too. I think it may be hard to push it very deeply down. I have 50 ps and 5 ps resolution versions for this purpose. May be a complementary solution to the offset generator above. I am looking for something with ~10ps accuracy, 100ns+ range, and reasonably low jitter (~5ps or better.) It is possible that the range needs to be split up (e.g. fixed rigid coax delay line followed by a mechanically adjust section.) This is a low budget fun project so something simple and common sense is preferred to "price on application" NIST traceable equipment. I hope that you can feel inspired to quickly locate the equipment needed. Good luck and report back on your progress! Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Performance verification for time counters
I am looking for an established and widely accepted procedure for verifying performance of high resolution time counters. I have designed a time stamping counter for qualifying 1PPS signal performance against external reference (e.g. 10MHz master clock.) Simple design verification check I am doing at the moment is gating random selection of master clock edges back into device's signal input and letting the device measure this test signal offset against its reference clock - which, for ideal design, should result in zero offset (modulo 100ns.) My results are roughly in line with what I expect to see http://leobodnar.com/balloons/NTP/time-sampler-test1.png Now, what would be recognised procedure for sweeping external input pulse delay over few hundred ns in a controlled, measurable and repeatable way? I can see few naïve approaches: 1) Using selectively gated (or divided) reference clock followed by adjustable delay line. E.g. something like mechanically adjusted delay lines used in HP test sets. Or, perhaps, calibrated rigid coax sections? 2) Slightly offset another master clock (e.g. second Rb oscillator) gated in a similar way but without delay line, followed by statistical data analysis 3) Trusted pulse generator with high resolution delay adjustment fed from the same master clock as the counter I am looking for something with ~10ps accuracy, 100ns+ range, and reasonably low jitter (~5ps or better.) It is possible that the range needs to be split up (e.g. fixed rigid coax delay line followed by a mechanically adjust section.) This is a low budget fun project so something simple and common sense is preferred to "price on application" NIST traceable equipment. Thanks! Leo ___ 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] Designing an embedded precision GPS time server
Hi Nick, I've got a project along those lines that I've been hacking on for the past three years or so, and always meaning to do a thorough writeup on. I'm more of a software than hardware guy, so the heart of it is a Taijiuino Due (a weird Chinese clone of the Arduino Due, so an 84MHz ATSAM3X8E, with the difference from the official board being that it brings out the SAM's Ethernet pins to a header that you can perch a PHY module on). It then talks to a GPS (Resolution-SMT) and Rb (SA.22c, digitally controlled), multiplied up 25/8 times by a TAPR Clock-Block to get 32ns granularity (more or less). Apart from some of the low-level MAC code which is from Atmel it's all my code for GPS decoding, timekeeping, NTP, etc, and has some basic support for health monitoring and holdover. As a NTP server it's pretty good when it's behaving -- I've got a particularly-stable Linux machine on the same Ethernet segment polling it at 16s interval and chrony reports a 500ns - 1us stdev for it, so you can take that as a jitter figure. It outperforms the old Spectracom NetClock 9183 (w/OCXO option) I've got, in any case. I'd be interested in comparing notes, and also interested in any possibility of designing a PCB to replace the rat's nest of wires I've got going on -- as I mentioned, I'm not "really" a hardware guy and EDA isn't a skill I've picked up at this point. I've always wanted to derive the micro's clock from the Rb (and PLL it up on the chip) rather than having to live with the restrictions of an externally-clocked timer... but making that happen is beyond my abilities :) On Wed, Oct 25, 2017 at 8:53 PM, Nick Sayer via time-nuts < time-nuts@febo.com> wrote: > I’ve just completed a project (off topic) with the ATSAMS70 chip and > learned a lot in a relatively short time, and I really like the result. > > I am considering a new project based on its cousin, the ATSAME70. The E70 > has an Ethernet 10/100 MAC built in as well as the rest of the stuff the > S70 has (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), > and Atmel Start (the software development framework I’ve been using) > purports to have a ready-to-use IP stack (alas, no IPv6, but it’s a > starting point at least). > > Where I am going with this is I am considering designing a precision > embedded NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got > piles of up to a GPIO and USART and the Ethernet port would provide > NTP/PTP. The idea behind making it an embedded system would be to try and > make it as accurate as it reasonably can be with the hope that (at least on > the local segment) it would wind up being more accurate than a Pi Zero > doing the same thing. At the very least, you’d expect such a thing to be a > whole lot less hassle to set up, given decent firmware. > > This may be a fool’s errand, certainly, but looking at it from here, I > would think that such a design might offer accuracy in the microsecond > range, but that’s just a tremendously uninformed guess at this point (and > what does that accuracy mean to a peer that might itself be incapable of > better than 2 orders of magnitude coarser?). > > Anybody have any ideas or suggestions along these lines? > ___ > 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.
