time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

ADEV query Timelab and TICC

BS
Bob Stewart
Mon, Mar 20, 2017 3:30 AM

These look a lot like the 25ns pops I was getting when I first started generating the 1PPS output from the PIC.  In my case, the PIC uses a PLL to multiply the external clock from 10MHz to 80MHz, which is then  divided to 40MHz and used as an instruction clock.  This gave an occasional early or late pulse, which was off by 25ns.  I wound up fixing my problem by arranging it so that the timer used to generate the 1PPS was offset by 2 instructions  (so that the timer fired between two successive 100ns pulses from the OCXO) and then gating the generated pulse with the OCXO so that the OCXO was the thing generating the actual 1PPS output.  Of course, this could be something entirely different:  For example, the quantization error on the 1PPS from the GPSDO as Tom mentions.  But, in that case, it seems like there should be a lot more of them.
Bob 

  From: Tom Van Baak <tvb@LeapSecond.com>

To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Sunday, March 19, 2017 10:04 PM
Subject: Re: [time-nuts] ADEV query Timelab and TICC

I have sent a couple of files to Tom.  They were taken simultaneously from
an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to
1Hz.  The glitches were on the PPS trace, but not on the PicDiv trace, so
I'm fairly confident the TICC was working correctly.

Orin.

Hi Orin,

Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). Everything looks fine with the exception of 8 glitches. These are sometimes obvious jumps in phase, which cause massive spikes in frequency. Two plots attached.

Almost every data point is within a few ns of each other. This is good. The standard deviation is a fraction of 1 ns. But once in a while there is a relatively massive phase jump. This is bad. Interestingly these 8 phase jumps all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list is (ns units):

24.575
24.724
24.831
25.047
25.087
25.549
25.589
49.623

25 * N ns is not random. So I think this is not a Windows problem, not a USB problem, not a TimeLab problem, not a TICC problem either.

It makes me wonder if this is a LTE-Lite problem. If Said or Keith from Jackson Labs is around -- is there anything on the LTE-Lite board that's close to 20 or 40 or 80 MHz? At this point I kind of trust Orin's data and I kind of trust the TICC. So when I see monster 25 ns phase jumps it makes me think there's a problem with the GSPDO board itself.

(Please realize that only on time-nuts may we can use the words "monster" and "25 ns" in the same sentence; the rest of the world has larger problems)

/tvb_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

These look a lot like the 25ns pops I was getting when I first started generating the 1PPS output from the PIC.  In my case, the PIC uses a PLL to multiply the external clock from 10MHz to 80MHz, which is then  divided to 40MHz and used as an instruction clock.  This gave an occasional early or late pulse, which was off by 25ns.  I wound up fixing my problem by arranging it so that the timer used to generate the 1PPS was offset by 2 instructions  (so that the timer fired between two successive 100ns pulses from the OCXO) and then gating the generated pulse with the OCXO so that the OCXO was the thing generating the actual 1PPS output.  Of course, this could be something entirely different:  For example, the quantization error on the 1PPS from the GPSDO as Tom mentions.  But, in that case, it seems like there should be a lot more of them. Bob  From: Tom Van Baak <tvb@LeapSecond.com> To: Discussion of precise time and frequency measurement <time-nuts@febo.com> Sent: Sunday, March 19, 2017 10:04 PM Subject: Re: [time-nuts] ADEV query Timelab and TICC > I have sent a couple of files to Tom.  They were taken simultaneously from > an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to > 1Hz.  The glitches were on the PPS trace, but not on the PicDiv trace, so > I'm fairly confident the TICC was working correctly. > > Orin. Hi Orin, Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). Everything looks fine with the exception of 8 glitches. These are sometimes obvious jumps in phase, which cause massive spikes in frequency. Two plots attached. Almost every data point is within a few ns of each other. This is good. The standard deviation is a fraction of 1 ns. But once in a while there is a relatively massive phase jump. This is bad. Interestingly these 8 phase jumps all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list is (ns units): 24.575 24.724 24.831 25.047 25.087 25.549 25.589 49.623 25 * N ns is not random. So I think this is not a Windows problem, not a USB problem, not a TimeLab problem, not a TICC problem either. It makes me wonder if this is a LTE-Lite problem. If Said or Keith from Jackson Labs is around -- is there anything on the LTE-Lite board that's close to 20 or 40 or 80 MHz? At this point I kind of trust Orin's data and I kind of trust the TICC. So when I see monster 25 ns phase jumps it makes me think there's a problem with the GSPDO board itself. (Please realize that only on time-nuts may we can use the words "monster" and "25 ns" in the same sentence; the rest of the world has larger problems) /tvb_______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
TV
Tom Van Baak
Mon, Mar 20, 2017 4:00 AM

Hi Orin,

More info... If you try to manually remove the 25 ns glitches you get a data set that looks much better. Attached are the ADEV plots for (1) your raw data and (2) your data minus those 8 glitches. You can see the dramatic difference that just 8 points make. Blue is raw data, red is data without those 8 glitches.

Now, this is not likely your fault. Also, I'm not saying we know yet what causes the glitches. This posting is merely to show how 8 bad points out of 8,000 points can totally mess up an ADEV plot.

And without preaching too much, this is why I recommend no one does statistical work (e.g., ADEV) without first looking at the raw phase and frequency data. A doubting Thomas attitude and the human eye are valuable tools in science. Both Stable32 and TimeLab make it easy to display phase and frequency, not just ADEV. This is not by accident.

Maybe we have hyped ADEV too much on this list. This rant is especially addressed at several LH and NTP authors who think analyzing clock data and making ADEV plots is just something you blindly code or script or automate, as if working with clock measurement data was as pure as mathematics.

/tvb

Hi Orin, More info... If you try to manually remove the 25 ns glitches you get a data set that looks much better. Attached are the ADEV plots for (1) your raw data and (2) your data minus those 8 glitches. You can see the dramatic difference that just 8 points make. Blue is raw data, red is data without those 8 glitches. Now, this is not likely your fault. Also, I'm not saying we know yet what causes the glitches. This posting is merely to show how 8 bad points out of 8,000 points can totally mess up an ADEV plot. And without preaching too much, this is why I recommend no one does statistical work (e.g., ADEV) without first looking at the raw phase and frequency data. A doubting Thomas attitude and the human eye are valuable tools in science. Both Stable32 and TimeLab make it easy to display phase and frequency, not just ADEV. This is not by accident. Maybe we have hyped ADEV too much on this list. This rant is especially addressed at several LH and NTP authors who think analyzing clock data and making ADEV plots is just something you blindly code or script or automate, as if working with clock measurement data was as pure as mathematics. /tvb
OE
Orin Eman
Mon, Mar 20, 2017 5:09 AM

On Sun, Mar 19, 2017 at 8:03 PM, Tom Van Baak tvb@leapsecond.com wrote:

Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219
points). Everything looks fine with the exception of 8 glitches. These are
sometimes obvious jumps in phase, which cause massive spikes in frequency.
Two plots attached.

First, thanks to Tom for taking a look at these files.

Almost every data point is within a few ns of each other. This is good.
The standard deviation is a fraction of 1 ns. But once in a while there is
a relatively massive phase jump. This is bad. Interestingly these 8 phase
jumps all appear to be about 25 ns or a multiple of 25 ns in magnitude. The
full list is (ns units):

24.575
24.724
24.831
25.047
25.087
25.549
25.589
49.623

25 * N ns is not random. So I think this is not a Windows problem, not a
USB problem, not a TimeLab problem, not a TICC problem either.

Personally, I didn't think it was any of the the above either.  The PicDiv
trace showed no such glitches, so I was fairly confident that the TICC was
working well.  But just to verify that, I connected the LTE-Lite PPS to the
5370A and let it run for a few hours.  The 5370A captures similar
glitches.  I have sent the file on to Tom.

For entertainment value, I have attached the current Lady Heather
screenshot for the LTE-Lite.  It has little relationship to the .tim files
I sent to Tom since I generated those a few weeks ago.  FWIW, it shows an
off by two error writing some text, for example: "PDTDT".  This seems to
happen if you go to some other screen (I think it was help in this case)
then returning.

Orin.

[image: Inline image 3]

On Sun, Mar 19, 2017 at 8:03 PM, Tom Van Baak <tvb@leapsecond.com> wrote: > > Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 > points). Everything looks fine with the exception of 8 glitches. These are > sometimes obvious jumps in phase, which cause massive spikes in frequency. > Two plots attached. > First, thanks to Tom for taking a look at these files. > Almost every data point is within a few ns of each other. This is good. > The standard deviation is a fraction of 1 ns. But once in a while there is > a relatively massive phase jump. This is bad. Interestingly these 8 phase > jumps all appear to be about 25 ns or a multiple of 25 ns in magnitude. The > full list is (ns units): > > 24.575 > 24.724 > 24.831 > 25.047 > 25.087 > 25.549 > 25.589 > 49.623 > > 25 * N ns is not random. So I think this is not a Windows problem, not a > USB problem, not a TimeLab problem, not a TICC problem either. > Personally, I didn't think it was any of the the above either. The PicDiv trace showed no such glitches, so I was fairly confident that the TICC was working well. But just to verify that, I connected the LTE-Lite PPS to the 5370A and let it run for a few hours. The 5370A captures similar glitches. I have sent the file on to Tom. For entertainment value, I have attached the current Lady Heather screenshot for the LTE-Lite. It has little relationship to the .tim files I sent to Tom since I generated those a few weeks ago. FWIW, it shows an off by two error writing some text, for example: "PDTDT". This seems to happen if you go to some other screen (I think it was help in this case) then returning. Orin. [image: Inline image 3]
T
timeok
Mon, Mar 20, 2017 7:56 AM

All,
the similar problem I have verified using the HP5065A and HP5061B 1PPS output, the dividers are pratically unusable for ADEV measurements. The 5/10MHz output of the same instruments using the TAPR divider are ok, so these dividers have some spike noise problems. It can be seen even using other TIC as The HP53132A.
Luciano
www.timeok.it

Da "time-nuts" time-nuts-bounces@febo.com
A "Discussion of precise time and frequency measurement" time-nuts@febo.com
Cc
Data Sun, 19 Mar 2017 20:03:29 -0700
Oggetto Re: [time-nuts] ADEV query Timelab and TICC

I have sent a couple of files to Tom. They were taken simultaneously from
an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to
1Hz. The glitches were on the PPS trace, but not on the PicDiv trace, so
I'm fairly confident the TICC was working correctly.

Orin.

Hi Orin,

Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). Everything looks fine with the exception of 8 glitches. These are sometimes obvious jumps in phase, which cause massive spikes in frequency. Two plots attached.

Almost every data point is within a few ns of each other. This is good. The standard deviation is a fraction of 1 ns. But once in a while there is a relatively massive phase jump. This is bad. Interestingly these 8 phase jumps all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list is (ns units):

24.575
24.724
24.831
25.047
25.087
25.549
25.589
49.623

25 * N ns is not random. So I think this is not a Windows problem, not a USB problem, not a TimeLab problem, not a TICC problem either.

It makes me wonder if this is a LTE-Lite problem. If Said or Keith from Jackson Labs is around -- is there anything on the LTE-Lite board that's close to 20 or 40 or 80 MHz? At this point I kind of trust Orin's data and I kind of trust the TICC. So when I see monster 25 ns phase jumps it makes me think there's a problem with the GSPDO board itself.

(Please realize that only on time-nuts may we can use the words "monster" and "25 ns" in the same sentence; the rest of the world has larger problems)

/tvb

All, the similar problem I have verified using the HP5065A and HP5061B 1PPS output, the dividers are pratically unusable for ADEV measurements. The 5/10MHz output of the same instruments using the TAPR divider are ok, so these dividers have some spike noise problems. It can be seen even using other TIC as The HP53132A. Luciano www.timeok.it Da "time-nuts" time-nuts-bounces@febo.com A "Discussion of precise time and frequency measurement" time-nuts@febo.com Cc Data Sun, 19 Mar 2017 20:03:29 -0700 Oggetto Re: [time-nuts] ADEV query Timelab and TICC > I have sent a couple of files to Tom. They were taken simultaneously from > an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to > 1Hz. The glitches were on the PPS trace, but not on the PicDiv trace, so > I'm fairly confident the TICC was working correctly. > > Orin. Hi Orin, Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). Everything looks fine with the exception of 8 glitches. These are sometimes obvious jumps in phase, which cause massive spikes in frequency. Two plots attached. Almost every data point is within a few ns of each other. This is good. The standard deviation is a fraction of 1 ns. But once in a while there is a relatively massive phase jump. This is bad. Interestingly these 8 phase jumps all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list is (ns units): 24.575 24.724 24.831 25.047 25.087 25.549 25.589 49.623 25 * N ns is not random. So I think this is not a Windows problem, not a USB problem, not a TimeLab problem, not a TICC problem either. It makes me wonder if this is a LTE-Lite problem. If Said or Keith from Jackson Labs is around -- is there anything on the LTE-Lite board that's close to 20 or 40 or 80 MHz? At this point I kind of trust Orin's data and I kind of trust the TICC. So when I see monster 25 ns phase jumps it makes me think there's a problem with the GSPDO board itself. (Please realize that only on time-nuts may we can use the words "monster" and "25 ns" in the same sentence; the rest of the world has larger problems) /tvb
JA
John Ackermann N8UR
Mon, Mar 20, 2017 4:16 PM

I noticed with the TICC that the very high peak voltage on the 5061, 5065, etc. PPS causes trigger errors.  Putting a 50 ohm load at the TICC channel input helped a lot, or an attenuator might even be better.

These HP units have a very short pulse width that peaks at something like 20v into a high impedance.  It doesn't​ seem to hurt the TICC input circuit, but causes ringing that results in perceived jitter.  Knocking that down to TTL level solves the problem.

On Mar 20, 2017, 12:01 PM, at 12:01 PM, timeok timeok@timeok.it wrote:

All,
the similar problem I have verified using the HP5065A and HP5061B 1PPS
output, the dividers are pratically unusable for ADEV measurements. The
5/10MHz output of the same instruments using the TAPR divider are ok,
so these dividers have some spike noise problems. It can be seen even
using other TIC as The HP53132A.
Luciano
www.timeok.it

Da "time-nuts" time-nuts-bounces@febo.com
A "Discussion of precise time and frequency measurement"
time-nuts@febo.com
Cc
Data Sun, 19 Mar 2017 20:03:29 -0700
Oggetto Re: [time-nuts] ADEV query Timelab and TICC

I have sent a couple of files to Tom. They were taken simultaneously

from

an LTE Lite - one from the PPS and one from a PicDiv dividing the

10MHz to

1Hz. The glitches were on the PPS trace, but not on the PicDiv trace,

so

I'm fairly confident the TICC was working correctly.

Orin.

Hi Orin,

Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219
points). Everything looks fine with the exception of 8 glitches. These
are sometimes obvious jumps in phase, which cause massive spikes in
frequency. Two plots attached.

Almost every data point is within a few ns of each other. This is good.
The standard deviation is a fraction of 1 ns. But once in a while there
is a relatively massive phase jump. This is bad. Interestingly these 8
phase jumps all appear to be about 25 ns or a multiple of 25 ns in
magnitude. The full list is (ns units):

24.575
24.724
24.831
25.047
25.087
25.549
25.589
49.623

25 * N ns is not random. So I think this is not a Windows problem, not
a USB problem, not a TimeLab problem, not a TICC problem either.

It makes me wonder if this is a LTE-Lite problem. If Said or Keith from
Jackson Labs is around -- is there anything on the LTE-Lite board
that's close to 20 or 40 or 80 MHz? At this point I kind of trust
Orin's data and I kind of trust the TICC. So when I see monster 25 ns
phase jumps it makes me think there's a problem with the GSPDO board
itself.

(Please realize that only on time-nuts may we can use the words
"monster" and "25 ns" in the same sentence; the rest of the world has
larger problems)

/tvb


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

I noticed with the TICC that the very high peak voltage on the 5061, 5065, etc. PPS causes trigger errors.  Putting a 50 ohm load at the TICC channel input helped a lot, or an attenuator might even be better. These HP units have a very short pulse width that peaks at something like 20v into a high impedance.  It doesn't​ seem to hurt the TICC input circuit, but causes ringing that results in perceived jitter.  Knocking that down to TTL level solves the problem. On Mar 20, 2017, 12:01 PM, at 12:01 PM, timeok <timeok@timeok.it> wrote: > > All, >the similar problem I have verified using the HP5065A and HP5061B 1PPS >output, the dividers are pratically unusable for ADEV measurements. The >5/10MHz output of the same instruments using the TAPR divider are ok, >so these dividers have some spike noise problems. It can be seen even >using other TIC as The HP53132A. > Luciano > www.timeok.it > > > Da "time-nuts" time-nuts-bounces@febo.com >A "Discussion of precise time and frequency measurement" >time-nuts@febo.com > Cc > Data Sun, 19 Mar 2017 20:03:29 -0700 > Oggetto Re: [time-nuts] ADEV query Timelab and TICC >> I have sent a couple of files to Tom. They were taken simultaneously >from >> an LTE Lite - one from the PPS and one from a PicDiv dividing the >10MHz to >> 1Hz. The glitches were on the PPS trace, but not on the PicDiv trace, >so > > I'm fairly confident the TICC was working correctly. > > > > Orin. > > Hi Orin, > >Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 >points). Everything looks fine with the exception of 8 glitches. These >are sometimes obvious jumps in phase, which cause massive spikes in >frequency. Two plots attached. > >Almost every data point is within a few ns of each other. This is good. >The standard deviation is a fraction of 1 ns. But once in a while there >is a relatively massive phase jump. This is bad. Interestingly these 8 >phase jumps all appear to be about 25 ns or a multiple of 25 ns in >magnitude. The full list is (ns units): > > 24.575 > 24.724 > 24.831 > 25.047 > 25.087 > 25.549 > 25.589 > 49.623 > >25 * N ns is not random. So I think this is not a Windows problem, not >a USB problem, not a TimeLab problem, not a TICC problem either. > >It makes me wonder if this is a LTE-Lite problem. If Said or Keith from >Jackson Labs is around -- is there anything on the LTE-Lite board >that's close to 20 or 40 or 80 MHz? At this point I kind of trust >Orin's data and I kind of trust the TICC. So when I see monster 25 ns >phase jumps it makes me think there's a problem with the GSPDO board >itself. > >(Please realize that only on time-nuts may we can use the words >"monster" and "25 ns" in the same sentence; the rest of the world has >larger problems) > > /tvb >_______________________________________________ >time-nuts mailing list -- time-nuts@febo.com >To unsubscribe, go to >https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there.
TV
Tom Van Baak
Mon, Mar 20, 2017 4:48 PM

Luciano,

This should not happen with the hp 5065A or 5061B frequency standards. I'm glad you worked around it by using a TAPR divider, but let's see if we can figure out the actual problem.

One thing to know is that the 1PPS output level from the 5061 and 5065 is HUGE, even up to 10 volts. If you send this to most counters it will blow the inputs or cause other undesirable side-effects, like the bouncing and spikes that you speak of. So always check your output and input signal levels and waveforms using a 'scope. Do this in-circuit, with all cables attached. Use attenuators and termination as appropriate for your counter's input specs. Set your DC trigger level to best match the actual waveform seen by the counter (not the waveform sent by the frequency standard).

Yes, the usual way you find out about this is that your ADEV measurements don't look right. The good news is that you can often tell within seconds that something is wrong. It's almost always a signal conditioning or trigger level issue, not a flaw in the instrument itself.

The TAPR dividers tend not to have "this problem" because they output at wimpy TTL/CMOS levels.

Older equipment can have powerful outputs. 10V into 50R is, what, 1/5th of an amp? Logarithmically, that puts a 5061A 1PPS closer to an automobile starter motor or heart defibrillator compared to modern logic gates.

/tvb

----- Original Message -----
From: "timeok" timeok@timeok.it
To: time-nuts@febo.com
Sent: Monday, March 20, 2017 12:56 AM
Subject: Re: [time-nuts] ADEV query Timelab and TICC

All,
the similar problem I have verified using the HP5065A and HP5061B 1PPS output, the dividers are pratically unusable for ADEV measurements. The 5/10MHz output of the same instruments using the TAPR divider are ok, so these dividers have some spike noise problems. It can be seen even using other TIC as The HP53132A.
Luciano
www.timeok.it

Da "time-nuts" time-nuts-bounces@febo.com
A "Discussion of precise time and frequency measurement" time-nuts@febo.com
Cc
Data Sun, 19 Mar 2017 20:03:29 -0700
Oggetto Re: [time-nuts] ADEV query Timelab and TICC

I have sent a couple of files to Tom. They were taken simultaneously from
an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to
1Hz. The glitches were on the PPS trace, but not on the PicDiv trace, so
I'm fairly confident the TICC was working correctly.

Orin.

Hi Orin,

Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). Everything looks fine with the exception of 8 glitches. These are sometimes obvious jumps in phase, which cause massive spikes in frequency. Two plots attached.

Almost every data point is within a few ns of each other. This is good. The standard deviation is a fraction of 1 ns. But once in a while there is a relatively massive phase jump. This is bad. Interestingly these 8 phase jumps all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list is (ns units):

24.575
24.724
24.831
25.047
25.087
25.549
25.589
49.623

25 * N ns is not random. So I think this is not a Windows problem, not a USB problem, not a TimeLab problem, not a TICC problem either.

It makes me wonder if this is a LTE-Lite problem. If Said or Keith from Jackson Labs is around -- is there anything on the LTE-Lite board that's close to 20 or 40 or 80 MHz? At this point I kind of trust Orin's data and I kind of trust the TICC. So when I see monster 25 ns phase jumps it makes me think there's a problem with the GSPDO board itself.

(Please realize that only on time-nuts may we can use the words "monster" and "25 ns" in the same sentence; the rest of the world has larger problems)

/tvb

Luciano, This should not happen with the hp 5065A or 5061B frequency standards. I'm glad you worked around it by using a TAPR divider, but let's see if we can figure out the actual problem. One thing to know is that the 1PPS output level from the 5061 and 5065 is *HUGE*, even up to 10 volts. If you send this to most counters it will blow the inputs or cause other undesirable side-effects, like the bouncing and spikes that you speak of. So always check your output and input signal levels and waveforms using a 'scope. Do this in-circuit, with all cables attached. Use attenuators and termination as appropriate for your counter's input specs. Set your DC trigger level to best match the actual waveform seen by the counter (not the waveform sent by the frequency standard). Yes, the usual way you find out about this is that your ADEV measurements don't look right. The good news is that you can often tell within seconds that something is wrong. It's almost always a signal conditioning or trigger level issue, not a flaw in the instrument itself. The TAPR dividers tend not to have "this problem" because they output at wimpy TTL/CMOS levels. Older equipment can have powerful outputs. 10V into 50R is, what, 1/5th of an amp? Logarithmically, that puts a 5061A 1PPS closer to an automobile starter motor or heart defibrillator compared to modern logic gates. /tvb ----- Original Message ----- From: "timeok" <timeok@timeok.it> To: <time-nuts@febo.com> Sent: Monday, March 20, 2017 12:56 AM Subject: Re: [time-nuts] ADEV query Timelab and TICC > > All, > the similar problem I have verified using the HP5065A and HP5061B 1PPS output, the dividers are pratically unusable for ADEV measurements. The 5/10MHz output of the same instruments using the TAPR divider are ok, so these dividers have some spike noise problems. It can be seen even using other TIC as The HP53132A. > Luciano > www.timeok.it > > > Da "time-nuts" time-nuts-bounces@febo.com > A "Discussion of precise time and frequency measurement" time-nuts@febo.com > Cc > Data Sun, 19 Mar 2017 20:03:29 -0700 > Oggetto Re: [time-nuts] ADEV query Timelab and TICC > > I have sent a couple of files to Tom. They were taken simultaneously from > > an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to > > 1Hz. The glitches were on the PPS trace, but not on the PicDiv trace, so > > I'm fairly confident the TICC was working correctly. > > > > Orin. > > Hi Orin, > > Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). Everything looks fine with the exception of 8 glitches. These are sometimes obvious jumps in phase, which cause massive spikes in frequency. Two plots attached. > > Almost every data point is within a few ns of each other. This is good. The standard deviation is a fraction of 1 ns. But once in a while there is a relatively massive phase jump. This is bad. Interestingly these 8 phase jumps all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list is (ns units): > > 24.575 > 24.724 > 24.831 > 25.047 > 25.087 > 25.549 > 25.589 > 49.623 > > 25 * N ns is not random. So I think this is not a Windows problem, not a USB problem, not a TimeLab problem, not a TICC problem either. > > It makes me wonder if this is a LTE-Lite problem. If Said or Keith from Jackson Labs is around -- is there anything on the LTE-Lite board that's close to 20 or 40 or 80 MHz? At this point I kind of trust Orin's data and I kind of trust the TICC. So when I see monster 25 ns phase jumps it makes me think there's a problem with the GSPDO board itself. > > (Please realize that only on time-nuts may we can use the words "monster" and "25 ns" in the same sentence; the rest of the world has larger problems) > > /tvb
T
timeok
Tue, Mar 21, 2017 1:52 PM

I know the the open load output of some instrument is 10Vpp and I think this is right because if  we want to connect this output on a 50Ohm line is correct to close the cable with the proper load impedance.
I have found this level also on some trak System equipment.
All my test are done using a 50 Ohm load in parallel to the HP and Trak outputs. I have tested two HP5065A and one HP5061B with the 1PPS option installed with the same spikes problem. The Trak , instead, work correctly, so I suspect some design problems on the HP dividers. I remember the same problem on the HP, and only HP, appear using an HP53132A TIC.
To avoid any TAPR TICC input problem I am working on a small interface board with a 1M and 50Ohm input selection and a protection circuit for negative or non TTL signals.
Luciano
www.timeok.it

Da "time-nuts" time-nuts-bounces@febo.com
A "Discussion of precise time and frequency measurement" time-nuts@febo.com
Cc
Data Mon, 20 Mar 2017 09:48:24 -0700
Oggetto Re: [time-nuts] ADEV query Timelab and TICC
Luciano,

This should not happen with the hp 5065A or 5061B frequency standards. I'm glad you worked around it by using a TAPR divider, but let's see if we can figure out the actual problem.

One thing to know is that the 1PPS output level from the 5061 and 5065 is HUGE, even up to 10 volts. If you send this to most counters it will blow the inputs or cause other undesirable side-effects, like the bouncing and spikes that you speak of. So always check your output and input signal levels and waveforms using a 'scope. Do this in-circuit, with all cables attached. Use attenuators and termination as appropriate for your counter's input specs. Set your DC trigger level to best match the actual waveform seen by the counter (not the waveform sent by the frequency standard).

Yes, the usual way you find out about this is that your ADEV measurements don't look right. The good news is that you can often tell within seconds that something is wrong. It's almost always a signal conditioning or trigger level issue, not a flaw in the instrument itself.

The TAPR dividers tend not to have "this problem" because they output at wimpy TTL/CMOS levels.

Older equipment can have powerful outputs. 10V into 50R is, what, 1/5th of an amp? Logarithmically, that puts a 5061A 1PPS closer to an automobile starter motor or heart defibrillator compared to modern logic gates.

/tvb

----- Original Message -----
From: "timeok" timeok@timeok.it
To: time-nuts@febo.com
Sent: Monday, March 20, 2017 12:56 AM
Subject: Re: [time-nuts] ADEV query Timelab and TICC

All,
the similar problem I have verified using the HP5065A and HP5061B 1PPS output, the dividers are pratically unusable for ADEV measurements. The 5/10MHz output of the same instruments using the TAPR divider are ok, so these dividers have some spike noise problems. It can be seen even using other TIC as The HP53132A.
Luciano
www.timeok.it

Da "time-nuts" time-nuts-bounces@febo.com
A "Discussion of precise time and frequency measurement" time-nuts@febo.com
Cc
Data Sun, 19 Mar 2017 20:03:29 -0700
Oggetto Re: [time-nuts] ADEV query Timelab and TICC

I have sent a couple of files to Tom. They were taken simultaneously from
an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to
1Hz. The glitches were on the PPS trace, but not on the PicDiv trace, so
I'm fairly confident the TICC was working correctly.

Orin.

Hi Orin,

Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). Everything looks fine with the exception of 8 glitches. These are sometimes obvious jumps in phase, which cause massive spikes in frequency. Two plots attached.

Almost every data point is within a few ns of each other. This is good. The standard deviation is a fraction of 1 ns. But once in a while there is a relatively massive phase jump. This is bad. Interestingly these 8 phase jumps all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list is (ns units):

24.575
24.724
24.831
25.047
25.087
25.549
25.589
49.623

25 * N ns is not random. So I think this is not a Windows problem, not a USB problem, not a TimeLab problem, not a TICC problem either.

It makes me wonder if this is a LTE-Lite problem. If Said or Keith from Jackson Labs is around -- is there anything on the LTE-Lite board that's close to 20 or 40 or 80 MHz? At this point I kind of trust Orin's data and I kind of trust the TICC. So when I see monster 25 ns phase jumps it makes me think there's a problem with the GSPDO board itself.

(Please realize that only on time-nuts may we can use the words "monster" and "25 ns" in the same sentence; the rest of the world has larger problems)

/tvb


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

I know the the open load output of some instrument is 10Vpp and I think this is right because if we want to connect this output on a 50Ohm line is correct to close the cable with the proper load impedance. I have found this level also on some trak System equipment. All my test are done using a 50 Ohm load in parallel to the HP and Trak outputs. I have tested two HP5065A and one HP5061B with the 1PPS option installed with the same spikes problem. The Trak , instead, work correctly, so I suspect some design problems on the HP dividers. I remember the same problem on the HP, and only HP, appear using an HP53132A TIC. To avoid any TAPR TICC input problem I am working on a small interface board with a 1M and 50Ohm input selection and a protection circuit for negative or non TTL signals. Luciano www.timeok.it Da "time-nuts" time-nuts-bounces@febo.com A "Discussion of precise time and frequency measurement" time-nuts@febo.com Cc Data Mon, 20 Mar 2017 09:48:24 -0700 Oggetto Re: [time-nuts] ADEV query Timelab and TICC Luciano, This should not happen with the hp 5065A or 5061B frequency standards. I'm glad you worked around it by using a TAPR divider, but let's see if we can figure out the actual problem. One thing to know is that the 1PPS output level from the 5061 and 5065 is *HUGE*, even up to 10 volts. If you send this to most counters it will blow the inputs or cause other undesirable side-effects, like the bouncing and spikes that you speak of. So always check your output and input signal levels and waveforms using a 'scope. Do this in-circuit, with all cables attached. Use attenuators and termination as appropriate for your counter's input specs. Set your DC trigger level to best match the actual waveform seen by the counter (not the waveform sent by the frequency standard). Yes, the usual way you find out about this is that your ADEV measurements don't look right. The good news is that you can often tell within seconds that something is wrong. It's almost always a signal conditioning or trigger level issue, not a flaw in the instrument itself. The TAPR dividers tend not to have "this problem" because they output at wimpy TTL/CMOS levels. Older equipment can have powerful outputs. 10V into 50R is, what, 1/5th of an amp? Logarithmically, that puts a 5061A 1PPS closer to an automobile starter motor or heart defibrillator compared to modern logic gates. /tvb ----- Original Message ----- From: "timeok" <timeok@timeok.it> To: <time-nuts@febo.com> Sent: Monday, March 20, 2017 12:56 AM Subject: Re: [time-nuts] ADEV query Timelab and TICC > > All, > the similar problem I have verified using the HP5065A and HP5061B 1PPS output, the dividers are pratically unusable for ADEV measurements. The 5/10MHz output of the same instruments using the TAPR divider are ok, so these dividers have some spike noise problems. It can be seen even using other TIC as The HP53132A. > Luciano > www.timeok.it > > > Da "time-nuts" time-nuts-bounces@febo.com > A "Discussion of precise time and frequency measurement" time-nuts@febo.com > Cc > Data Sun, 19 Mar 2017 20:03:29 -0700 > Oggetto Re: [time-nuts] ADEV query Timelab and TICC > > I have sent a couple of files to Tom. They were taken simultaneously from > > an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to > > 1Hz. The glitches were on the PPS trace, but not on the PicDiv trace, so > > I'm fairly confident the TICC was working correctly. > > > > Orin. > > Hi Orin, > > Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). Everything looks fine with the exception of 8 glitches. These are sometimes obvious jumps in phase, which cause massive spikes in frequency. Two plots attached. > > Almost every data point is within a few ns of each other. This is good. The standard deviation is a fraction of 1 ns. But once in a while there is a relatively massive phase jump. This is bad. Interestingly these 8 phase jumps all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list is (ns units): > > 24.575 > 24.724 > 24.831 > 25.047 > 25.087 > 25.549 > 25.589 > 49.623 > > 25 * N ns is not random. So I think this is not a Windows problem, not a USB problem, not a TimeLab problem, not a TICC problem either. > > It makes me wonder if this is a LTE-Lite problem. If Said or Keith from Jackson Labs is around -- is there anything on the LTE-Lite board that's close to 20 or 40 or 80 MHz? At this point I kind of trust Orin's data and I kind of trust the TICC. So when I see monster 25 ns phase jumps it makes me think there's a problem with the GSPDO board itself. > > (Please realize that only on time-nuts may we can use the words "monster" and "25 ns" in the same sentence; the rest of the world has larger problems) > > /tvb _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.