Re: [time-nuts] Performance verification for time counters

[Hal Murray]

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

[Bob kb8tq]

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

[Tim Shoppa]

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

[jimlux]

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

[Bob kb8tq]

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

[jimlux]

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

[Mark Goldberg]

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

[Bob kb8tq]

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

[Poul-Henning Kamp]

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

[Bob kb8tq]

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

[Poul-Henning Kamp]

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

[Poul-Henning Kamp]

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

[Bob kb8tq]

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

[Chris Caudle]

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

[Poul-Henning Kamp]

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

[Bob kb8tq]

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

[Andy ZL3AG via time-nuts]

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

[Hal Murray]

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

[Bob kb8tq]

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

[Poul-Henning Kamp]

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

[Magnus Danielson]

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

[Leo Bodnar]

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

[Andrew Rodland]

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.