ADEV query Timelab and TICC
Yesterday I used one of John's excellent TICC modules for the first time
and initially set up a quick test using the 10MHz output from a Thunderbolt
as the frequency reference to measure the 1PPS from an Oscilloquartz Star4
GPSDO, with the TICC output feeding a USB3 port on a Windows 10 PC running
the 64 bit version of Timelab 1.29.
I'll attach a copy of the test plots I'm referring to but just in case
this doesn't get through I've also uploaded it to....
https://www.mediafire.com/?9bue90yp1e8ueu6
Using the basic settings as described in the TICC manual the first run was
for 1 hour and seemed fine so I decided to extend the run time to 6 hours.
The first 6 hour test started to follow the 1 hour plot as expected and I
watched this on and off and can confirm it did so up to somewhere between
the 100s and 1000s points on the x-axis, but some time after that the
complete plot shifted upwards and then continued to completion to produce the
magenta trace.
I wasn't watching when it shifted so don't know if it was a jump or a
gradual shift but did see it continue until completion. When I repeated the 6
hour test, again without changing anything, and hoping to observe the effect
as it happened, it produced the green trace which was what I'd been
expecting to start with. Since then I've made other test runs and again all seems
to be as expected.
I'm probably missing something obvious but don't understand what's
happened here so any suggestions would be welcome.
Throughout the tests I have been simultaneously streaming data from the
Star4 to Lady Heather via a "proper" serial port on the same PC so did wonder
if there might be some form of data conflict but it doesn't seem to have
shown up as any obvious form of corruption and hasn't repeated itself.
Nigel, GM8PZR
I'm probably missing something obvious but don't understand what's
happened here so any suggestions would be welcome.
Hi Nigel,
Your setup sounds fine. Off-list, send me the TIM files and I'll see what happened.
I know we all love ADEV but in general always look at the phase, phase residual, and frequency plots first before you bother with ADEV. These strip chart plots better show your raw data and measurement. Even a single glitch will be visible. Only if these plots are "clean" should you go ahead and use ADEV. Another trick is using the TimeLab "Trace" feature which splits the data into N segments and computes ADEV for each one independently.
But in this particular case where you are comparing two GPSDO a phase difference plot will likely be more informative than an ADEV plot anyway. You may also want to play around with the averaging value (command 'g').
/tvb
----- Original Message -----
From: "GandalfG8--- via time-nuts" time-nuts@febo.com
To: time-nuts@febo.com
Sent: Sunday, March 19, 2017 9:08 AM
Subject: [time-nuts] ADEV query Timelab and TICC
Yesterday I used one of John's excellent TICC modules for the first time
and initially set up a quick test using the 10MHz output from a Thunderbolt
as the frequency reference to measure the 1PPS from an Oscilloquartz Star4
GPSDO, with the TICC output feeding a USB3 port on a Windows 10 PC running
the 64 bit version of Timelab 1.29.
I'll attach a copy of the test plots I'm referring to but just in case
this doesn't get through I've also uploaded it to....
https://www.mediafire.com/?9bue90yp1e8ueu6
Using the basic settings as described in the TICC manual the first run was
for 1 hour and seemed fine so I decided to extend the run time to 6 hours.
The first 6 hour test started to follow the 1 hour plot as expected and I
watched this on and off and can confirm it did so up to somewhere between
the 100s and 1000s points on the x-axis, but some time after that the
complete plot shifted upwards and then continued to completion to produce the
magenta trace.
I wasn't watching when it shifted so don't know if it was a jump or a
gradual shift but did see it continue until completion. When I repeated the 6
hour test, again without changing anything, and hoping to observe the effect
as it happened, it produced the green trace which was what I'd been
expecting to start with. Since then I've made other test runs and again all seems
to be as expected.
Throughout the tests I have been simultaneously streaming data from the
Star4 to Lady Heather via a "proper" serial port on the same PC so did wonder
if there might be some form of data conflict but it doesn't seem to have
shown up as any obvious form of corruption and hasn't repeated itself.
Nigel, GM8PZR
I've seen similar with my TICC when observing a PPS - can't remember
whether the PPS was from the Thunderbolt or LTE Lite.
There was a distinct glitch on the frequency plot when it happened and it
was pretty easy in timelab to expand the trace around the glitch to take a
better look.
I did not see any such problem when dividing the 10MHz to 1PPS with a
PICDIV so I figured it was due to the GPSDO steering the PPS signal as
satellites appear/disappear - my antenna location is far from optimal.
On Sun, Mar 19, 2017 at 12:57 PM, Tom Van Baak tvb@leapsecond.com wrote:
I'm probably missing something obvious but don't understand what's
happened here so any suggestions would be welcome.
Hi Nigel,
Your setup sounds fine. Off-list, send me the TIM files and I'll see what
happened.
I know we all love ADEV but in general always look at the phase, phase
residual, and frequency plots first before you bother with ADEV. These
strip chart plots better show your raw data and measurement. Even a single
glitch will be visible. Only if these plots are "clean" should you go ahead
and use ADEV. Another trick is using the TimeLab "Trace" feature which
splits the data into N segments and computes ADEV for each one
independently.
But in this particular case where you are comparing two GPSDO a phase
difference plot will likely be more informative than an ADEV plot anyway.
You may also want to play around with the averaging value (command 'g').
/tvb
----- Original Message -----
From: "GandalfG8--- via time-nuts" time-nuts@febo.com
To: time-nuts@febo.com
Sent: Sunday, March 19, 2017 9:08 AM
Subject: [time-nuts] ADEV query Timelab and TICC
Yesterday I used one of John's excellent TICC modules for the first time
and initially set up a quick test using the 10MHz output from a
Thunderbolt
as the frequency reference to measure the 1PPS from an Oscilloquartz
Star4
GPSDO, with the TICC output feeding a USB3 port on a Windows 10 PC
running
the 64 bit version of Timelab 1.29.
I'll attach a copy of the test plots I'm referring to but just in case
this doesn't get through I've also uploaded it to....
https://www.mediafire.com/?9bue90yp1e8ueu6
Using the basic settings as described in the TICC manual the first run
was
for 1 hour and seemed fine so I decided to extend the run time to 6
hours.
The first 6 hour test started to follow the 1 hour plot as expected and I
watched this on and off and can confirm it did so up to somewhere between
the 100s and 1000s points on the x-axis, but some time after that the
complete plot shifted upwards and then continued to completion to
produce the
magenta trace.
I wasn't watching when it shifted so don't know if it was a jump or a
gradual shift but did see it continue until completion. When I repeated
the 6
hour test, again without changing anything, and hoping to observe the
effect
as it happened, it produced the green trace which was what I'd been
expecting to start with. Since then I've made other test runs and again
all seems
to be as expected.
Throughout the tests I have been simultaneously streaming data from the
Star4 to Lady Heather via a "proper" serial port on the same PC so did
wonder
if there might be some form of data conflict but it doesn't seem to have
shown up as any obvious form of corruption and hasn't repeated itself.
Nigel, GM8PZR
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.
Hi
It’s a pretty good bet that the “upper” trace has a noise pop in it. One of the wonderful things about ADEV is that a single
noise event can impact the whole curve. That is a bit non-intuitive. It is indeed how the math works and how the testing
comes out in the real world.
Bob
On Mar 19, 2017, at 12:08 PM, GandalfG8--- via time-nuts time-nuts@febo.com wrote:
Yesterday I used one of John's excellent TICC modules for the first time
and initially set up a quick test using the 10MHz output from a Thunderbolt
as the frequency reference to measure the 1PPS from an Oscilloquartz Star4
GPSDO, with the TICC output feeding a USB3 port on a Windows 10 PC running
the 64 bit version of Timelab 1.29.
I'll attach a copy of the test plots I'm referring to but just in case
this doesn't get through I've also uploaded it to....
https://www.mediafire.com/?9bue90yp1e8ueu6
Using the basic settings as described in the TICC manual the first run was
for 1 hour and seemed fine so I decided to extend the run time to 6 hours.
The first 6 hour test started to follow the 1 hour plot as expected and I
watched this on and off and can confirm it did so up to somewhere between
the 100s and 1000s points on the x-axis, but some time after that the
complete plot shifted upwards and then continued to completion to produce the
magenta trace.
I wasn't watching when it shifted so don't know if it was a jump or a
gradual shift but did see it continue until completion. When I repeated the 6
hour test, again without changing anything, and hoping to observe the effect
as it happened, it produced the green trace which was what I'd been
expecting to start with. Since then I've made other test runs and again all seems
to be as expected.
I'm probably missing something obvious but don't understand what's
happened here so any suggestions would be welcome.
Throughout the tests I have been simultaneously streaming data from the
Star4 to Lady Heather via a "proper" serial port on the same PC so did wonder
if there might be some form of data conflict but it doesn't seem to have
shown up as any obvious form of corruption and hasn't repeated itself.
Nigel, GM8PZR <Star4+ 170318.png>_______________________________________________
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 had this happen this morning. (Running Windows 10). Had 7 hours of good
data
running overnight, (good ADEV, Freq Diff plots).
Then There was a big pop' in the frequency difference trace. ADEV messed up
suddenly.
It happened coincident with starting up Microsoft Edge (which had not been
run
since the start of the data run). My guess is that perhaps Windows got too
busy
and USB samples were dropped.
-- Tom, N5EG
I've seen similar with my TICC when observing a PPS - can't remember
whether the PPS was from the Thunderbolt or LTE Lite.
There was a distinct glitch on the frequency plot when it happened and it
was pretty easy in timelab to expand the trace around the glitch to take a
better look.
Orin -- Thanks for that report. If you still have the TIM file, can you send it to me?
Everyone -- If you do see any anomalies with the new TICC please let me know, on- or off-list. A copy of the TIM file (if you use TimeLab) would be useful to me. Or if you're just logging the raw ascii output that's fine too. Once we collect enough examples we can update the user manual, or FAQ or even the firmware.
Anytime you work with an instrument that can measure down to 60 ps (single-shot) or down to 1 ps (with sufficient over-sampling or averaging) you may see things you normally don't see. This includes walking, closing doors, sneezing, touching cables or connectors. HVAC, FedEx trucks, sunlight, kids, pets, wife are also known to affect measurements at the ps level.
I'm currently running a TICC in TI (Time Interval) mode, in parallel with a hp 53132 counter in TI mode, in parallel with a TimePod. So it's really easy to see when one or the other or both have an issue. For use as a headless time interval counter, John's TICC is living up to its goal of an inexpensive alternative to a 53131A/53132A.
/tvb
On Sun, Mar 19, 2017 at 3:00 PM, Tom Van Baak tvb@leapsecond.com wrote:
I've seen similar with my TICC when observing a PPS - can't remember
whether the PPS was from the Thunderbolt or LTE Lite.
There was a distinct glitch on the frequency plot when it happened and it
was pretty easy in timelab to expand the trace around the glitch to take
a
better look.
Orin -- Thanks for that report. If you still have the TIM file, can you
send it to me?
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.
USB is not tied to anything specific so that could well be the case.
Another interest of mine is CNC machining (mill conversion and looking at a
Chinese laser) using MACH3 software. People have tried everything to get the
motors to run from a USB connection as machines with parallel ports are
getting rare. No success at all. A couple of companies are using an Ethernet
connection from the host computer to their own CPU board
(https://www.poscope.com/) - this works great. USB no.
Dave
-----Original Message-----
From: time-nuts [mailto:time-nuts-bounces@febo.com] On Behalf
Of Tom McDermott
Sent: Sunday, March 19, 2017 15:00
To: Discussion of precise time and frequency measurement
Cc: GandalfG8@aol.com
Subject: Re: [time-nuts] ADEV query Timelab and TICC
I had this happen this morning. (Running Windows 10). Had 7
hours of good
data
running overnight, (good ADEV, Freq Diff plots).
Then There was a big pop' in the frequency difference trace.
ADEV messed up
suddenly.
It happened coincident with starting up Microsoft Edge (which
had not been
run
since the start of the data run). My guess is that perhaps
Windows got too
busy
and USB samples were dropped.
-- Tom, N5EG
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 saw a similar higher-than-expected ADEV from another user who was measuring GPSDO PPS vs. 10 MHz from the same GPSDO. Using a T2-Mini from the 10 MHz yields the expected results.
I suspect that the GPSDO PPS in that unit is derived from GPS PPS rather than the OCXO, and thus is noisier in the short term than might otherwise be expected.
John
PS -- we just got into our new house and still don't have internet access, so I've not been on line as much as usual. another few days and things should!D be getting back to normal.
On Mar 19, 2017, 8:01 PM, at 8:01 PM, Orin Eman orin.eman@gmail.com wrote:
On Sun, Mar 19, 2017 at 3:00 PM, Tom Van Baak tvb@leapsecond.com
wrote:
I've seen similar with my TICC when observing a PPS - can't
remember
whether the PPS was from the Thunderbolt or LTE Lite.
There was a distinct glitch on the frequency plot when it happened
and it
was pretty easy in timelab to expand the trace around the glitch to
take
a
better look.
Orin -- Thanks for that report. If you still have the TIM file, can
you
send it to me?
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.
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 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
