Re: [time-nuts] Performance verification for time counters
Hi, On 12/02/2017 11:05 AM, Attila Kinali wrote: On Fri, 1 Dec 2017 21:10:55 + Leo Bodnar wrote: As promised, I started setting up dual asynchronous sources experiment and performed a quick sanity check. What I have [unsurprisingly] found is that at this level controlled environment is a problem in itself. For example, undoing input signal SMA connector by one turn shifted my results by around 3.5ps - close to expected figure but still inconvenient. I'll have to plan the setup before I build and validate it, otherwise the results are not trustworthy. 3.5ps is pretty much what I'd expect in additional delay, when undoing an SMA connector by one turn. One turn is about 0.7mm, assuming a VF of 0.6 you get to ~3.5ps. There is a reason that one should use SMA momentum keys for repeatability. I am quite impressed that you could measure it this accurately. A VNA should not have a problem measuring that at RF frequencies. 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] Performance verification for time counters
On Fri, 1 Dec 2017 21:10:55 + Leo Bodnar wrote: > As promised, I started setting up dual asynchronous sources experiment > and performed a quick sanity check. What I have [unsurprisingly] found > is that at this level controlled environment is a problem in itself. > For example, undoing input signal SMA connector by one turn shifted my > results by around 3.5ps - close to expected figure but still inconvenient. > I'll have to plan the setup before I build and validate it, otherwise the > results are not trustworthy. 3.5ps is pretty much what I'd expect in additional delay, when undoing an SMA connector by one turn. One turn is about 0.7mm, assuming a VF of 0.6 you get to ~3.5ps. I am quite impressed that you could measure it this accurately. What measurement technique do you use? Attila Kinali -- The bad part of Zurich is where the degenerates throw DARK chocolate at you. ___ 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
Poul-Henning, Magnus, et al. thanks for your suggestions - they were not in vain. As promised, I started setting up dual asynchronous sources experiment and performed a quick sanity check. What I have [unsurprisingly] found is that at this level controlled environment is a problem in itself. For example, undoing input signal SMA connector by one turn shifted my results by around 3.5ps - close to expected figure but still inconvenient. I'll have to plan the setup before I build and validate it, otherwise the results are not trustworthy. I hope this message makes it to the list - my previous one didn't. I am staying off the list for now. Thanks Leo P.S. I do know about torque wrenches. On 29 Nov 2017, at 21:51, Poul-Henning Kamp wrote: > 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. ___ 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 <20171130181024.832c6adfd3cea0658ba43...@kinali.ch>, Attila Kinali w rites: >What puzzles me here is, the reason why someone would care >about sub-1Hz frequencies in a telephone system? IIRC POTS >did cut off somewhere areound 100-300Hz anyways. They did not. Most carrier frequency facilities had bottom frequencies in the 50kHz area or higher. Bob brought up the sub-Hz stuff, I pressume he knows what it is used for. -- 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 They aren’t looking at voice signals, they are looking at the distribution of timing signals. The filters cut off well below voice frequencies. The issue (as originally mentioned) is peaking in very long chains of repeaters. Since the cutoff can be *very* low (just like with a GPSDO), the frequencies involved in a full amplitude and phase sweep are very low as well. If you want very tight db accuracy, that pretty much implies that you have a good number for “zero” frequency …… that puts you into silly season if somebody decides it must be “tested in”. Bob > On Nov 30, 2017, at 12:10 PM, Attila Kinali wrote: > > On Thu, 30 Nov 2017 09:39:59 -0500 > Bob kb8tq wrote: > >> That last decade ( 0.01 Hz period to 0.001 Hz) > > What puzzles me here is, the reason why someone would care > about sub-1Hz frequencies in a telephone system? IIRC POTS > did cut off somewhere areound 100-300Hz anyways. > > Attila Kinali > -- > It is upon moral qualities that a society is ultimately founded. All > the prosperity and technological sophistication in the world is of no > use without that foundation. > -- Miss Matheson, The Diamond Age, Neil Stephenson > ___ > 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 Thu, 30 Nov 2017 09:39:59 -0500 Bob kb8tq wrote: > That last decade ( 0.01 Hz period to 0.001 Hz) What puzzles me here is, the reason why someone would care about sub-1Hz frequencies in a telephone system? IIRC POTS did cut off somewhere areound 100-300Hz anyways. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson ___ 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 Sweep the transfer function from 100 Hz down to 0.001 Hz at 50 points per decade. Spend enough time at each point to get to 0.001 db sort of accuracy. The first decade goes pretty fast. That last decade ( 0.01 Hz period to 0.001 Hz) …. not so much. The request always has both the silly frequency and the nonsense db fraction in it …. Bob > On Nov 30, 2017, at 3:29 AM, Poul-Henning Kamp wrote: > > > In message <42a2f881-1631-402c-8ed6-2c863f6fe...@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 … >>> >>> 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. > > Sorry, I don't see the challenge: HP3458A in sampling mode, careful cabling, > done. > > At RF frequencies where you have to think about impedance however... > > > -- > 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
Thank you for great suggestions, I will try to set something up next week involving detuned clock or sinewave source. 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] Performance verification for time counters
In message <42a2f881-1631-402c-8ed6-2c863f6fe...@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 … >> >> 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. Sorry, I don't see the challenge: HP3458A in sampling mode, careful cabling, done. At RF frequencies where you have to think about impedance however... -- 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
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] 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.