Re: [time-nuts] ADEV query Timelab and TICC

[bg]

Look at ICD-GPS-060.
10V into 50ohm, sub 50ns risetime and 20us pulse lenght is specified in figure 
3-2.
--     Björn


Sent from my smartphone.
 Original message From: Hal Murray <hmur...@megapathdsl.net> 
Date: 21/03/2017  19:18  (GMT+01:00) To: Tom Van Baak <t...@leapsecond.com>, 
Discussion of precise time and frequency measurement <time-nuts@febo.com> Cc: 
hmur...@megapathdsl.net Subject: Re: [time-nuts] ADEV query Timelab and TICC 

t...@leapsecond.com said:
> The TAPR dividers tend not to have "this problem" because they output at
> wimpy TTL/CMOS levels.

Modern CMOS drivers have fast rise times.  As long as the rise time is short 
relative to the cable length, it gets doubled if the end of the cable is an 
open circuit.

> 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. 

There is a big difference across logic families.  Many can drive 50 ohms.

RS-232 drivers are explicitly limited to reduce EMI.


-- 
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.
___
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] ADEV query Timelab and TICC

[Hal Murray]

t...@leapsecond.com said:
> The TAPR dividers tend not to have "this problem" because they output at
> wimpy TTL/CMOS levels.

Modern CMOS drivers have fast rise times.  As long as the rise time is short 
relative to the cable length, it gets doubled if the end of the cable is an 
open circuit.

> 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. 

There is a big difference across logic families.  Many can drive 50 ohms.

RS-232 drivers are explicitly limited to reduce EMI.


-- 
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] ADEV query Timelab and TICC

[timeok]

   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-boun...@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" <tim...@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-boun...@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 thin

Re: [time-nuts] ADEV query Timelab and TICc

[ed briggs]

The 1 PPS signal is derived from an 81 MHz clock (12 ns) on the GPS chip 
according to the  Skytraq manual.  So that would mean n * 12ns.

From: time-nuts-requ...@febo.com<mailto:time-nuts-requ...@febo.com>
Sent: ‎3/‎20/‎2017 9:00 AM
To: time-nuts@febo.com<mailto:time-nuts@febo.com>
Subject: time-nuts Digest, Vol 152, Issue 32

Send time-nuts mailing list submissions to
time-nuts@febo.com

To subscribe or unsubscribe via the World Wide Web, visit
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
or, via email, send a message with subject or body 'help' to
time-nuts-requ...@febo.com

You can reach the person managing the list at
time-nuts-ow...@febo.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of time-nuts digest..."


Today's Topics:

   1. Re: ADEV query Timelab and TICC (Orin Eman)
   2. ADEV query Timelab and TICC (Mark Sims)
   3. Re: ADEV query Timelab and TICC (gandal...@aol.com)
   4. Re: ADEV query Timelab and TICC (Dave Martindale)


--

Message: 1
Date: Sun, 19 Mar 2017 22:09:57 -0700
From: Orin Eman <orin.e...@gmail.com>
To: Tom Van Baak <t...@leapsecond.com>,  Discussion of precise time and
frequency measurement <time-nuts@febo.com>
Subject: Re: [time-nuts] ADEV query Timelab and TICC
Message-ID:

Re: [time-nuts] ADEV query Timelab and TICC

[Tom Van Baak]

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" <tim...@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-boun...@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.

[time-nuts] ADEV query Timelab and TICC

[Mark Sims]

That doesn't make much sense if you are using the PICDIV properly... the TAPR 
dividers use the PICDIV chip to do the dividing.  The only difference between 
using a TAPR divider and a bare PICDIV is that the TAPR dividers have an input 
squarer circuit and output buffer.   If you are feeding the PICDIV with a clean 
TTL level input (and decent power) and the output from the PICDIV is not being 
abused/overloaded/improperly terminated the results should be the same.

---
>   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.
___
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] ADEV query Timelab and TICC

[John Ackermann N8UR]

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 <tim...@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-boun...@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.
___
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] ADEV query Timelab and TICC

[timeok]

   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-boun...@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.

Re: [time-nuts] ADEV query Timelab and TICC

[Dave Martindale]

The LTE-Lite User Manual (version 1.3) says:

2.3.7 1 PPS Module outputs
The LTE-Lite SMT Module provides GPS raw 1 PPS CMOS pulse on pin 15 with
sawtooth present, and a clean TCXO-generated, sawtooth-removed, UTC(GPS)
phase-locked 1PPS output on pin 4.

It is the pin 4 output that connects to the 1PPS-OUT jack on the eval
board.  So it is supposed to be cleanly divided down from the TCXO.  (But I
don't think Jackson Labs has published any of the circuitry on the LTE-Lite
module itself).

- Dave

On Mon, Mar 20, 2017 at 2:07 AM, Mark Sims  wrote:

>
> It is also interesting that the LTE GPSDO 1PPS has such a wide range of
> TIE.   A Tbolt / Z38xx GPSDO typically has a TIE in the 1PPS signal of
> around 1 nsec.   The LTE TIE spans over 40 nanoseconds (not including the
> spikes).  It seems like the LTE 1PPS may be from the GPS and not derived
> from dividing down the disciplined oscillator output.
> ___
>
___
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] ADEV query Timelab and TICC

[GandalfG8--- via time-nuts]

Many thanks for the replies on this, what was initially intended as a quick 
 "Hello World" test seems to have become far more interesting:-)
 
I'll forward my results to Tom as requested and see where we go from  there.
 
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.

Re: [time-nuts] ADEV query Timelab and TICC

[Orin Eman]

On Sun, Mar 19, 2017 at 8:03 PM, Tom Van Baak  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]
___
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] ADEV query Timelab and TICC

[Mark Sims]

Yes,  programs like Timelab and Stable32 are definitely the way to go for 
post-processing and analyzing your data in depth.   Lady Heather is more of a 
real-time monitoring and data acquisition program.   

The sensitivity of ADEV to data hiccups can be a good thing.  If your ADEV data 
goes to crap you know you have a problem and need to examine the data in more 
depth to find out why.   You can go in and remove / fixup the outliers to get a 
better understanding of the typical device performance  but leaving in the 
"zingers" tells you what the device is truly doing.

--

> 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.
___
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] ADEV query Timelab and TICC

[Mark Sims]

Orin sent me his data files and I ran them through Lady Heather.  Attached is a 
screen dump showing the Time Interval Error (TIE) plot of the 1PPS signal.  
This is the deviation of the 1PPS signal from the expected 1 second interval.   

Three of the bad points are flagged (1, 2, and 3 at the top of the plot area).  
 It is interesting that these discontinuities are not simple spikes in the 1PPS 
signal (a couple of his bad points are simple spikes) but are followed by a 
"recovery" period of 30 seconds to a minute.

It is also interesting that the LTE GPSDO 1PPS has such a wide range of TIE.   
A Tbolt / Z38xx GPSDO typically has a TIE in the 1PPS signal of around 1 nsec.  
 The LTE TIE spans over 40 nanoseconds (not including the spikes).  It seems 
like the LTE 1PPS may be from the GPS and not derived from dividing down the 
disciplined oscillator output.___
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] ADEV query Timelab and TICC

[Tom Van Baak]

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___
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] ADEV query Timelab and TICC

[Bob Stewart]

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 <t...@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.

   
___
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] ADEV query Timelab and TICC

[Tom Van Baak]

> 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.

Re: [time-nuts] ADEV query Timelab and TICC

[DaveH]

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-boun...@febo.com] On Behalf 
> Of Tom McDermott
> Sent: Sunday, March 19, 2017 15:00
> To: Discussion of precise time and frequency measurement
> Cc: gandal...@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.

___
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] ADEV query Timelab and TICC

[John Ackermann N8UR]

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  wrote:
>On Sun, Mar 19, 2017 at 3:00 PM, Tom Van Baak 
>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.
___
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] ADEV query Timelab and TICC

[Orin Eman]

On Sun, Mar 19, 2017 at 3:00 PM, Tom Van Baak  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.

Re: [time-nuts] ADEV query Timelab and TICC

[Tom McDermott]

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.

Re: [time-nuts] ADEV query Timelab and TICC

[Tom Van Baak]

> 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
___
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] ADEV query Timelab and TICC

[Bob kb8tq]

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  
> 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  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.

___
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] ADEV query Timelab and TICC

[Orin Eman]

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 <t...@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.
>
___
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] ADEV query Timelab and TICC

[Tom Van Baak]

> 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.

[time-nuts] ADEV query Timelab and TICC

[GandalfG8--- via time-nuts]

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
Description: Binary data
___
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.