[time-nuts] Lucent GPDSO TTI ps graph and efc is this sick?

Bob Camp kb8tq at n1k.org
Fri Nov 14 08:11:09 EST 2014


Need to drink my coffee first and type messages second.

The Time is doing a “LSB” change of some sort. It’s not sick, there’s either a problem with the string or something like that. The EFC is not moving at an alarming rate based on the plot. 

Simple things to do:

Unplug the software and fire up a terminal program. Run it into the Diag port just like the other stuff. Set it to 9600 8:N:1 and type the following:


that should give you a string identifying the unit properly and show that things are hooked up right.


That will show you a mega screen of everything that’s going on.The screen includes the time offset and predicted holdover numbers.


That will show you the EFC voltage in percent of range. It runs over a +/- 100% range.

Running things this way for a bit will let you eliminate any software issues from the mix. If things still look odd, do a:


That will show you any alarm outputs or odd things going thump in the night.


> On Nov 14, 2014, at 7:13 AM, ed briggs <edbriggs at outlook.com> wrote:
> The EFC is probably not sick, it is still in the middle of it's range, and has moved only a small amount.  I would let it run for another week and see if it starts to head back down.   As I mentioned in a previous post, I had to run my z3816a for several weeks before it settled down.  After that period of time, my Z3816 settled into the EFC range of 581240-581280 and a predicted uncertainty in the 100-200ns/24 range - but it took a month to get there)
> Important note: it seems that the Lucent *reports the PPS TI error differently* than previous units. This will make comparisons between this unit and the older unit difficult.   
> Another time-nut sent me the data file from Z38xx attached to a Lucent GPSDO, and I noticed that most of the values TI values had only zeros to the right of the decimal point.  (almost all but not all).  This made the data look like the TI jumped around in discrete steps of 1.0 * 10e-8 .  That is the reason you see the 'strata' and 'plateaus' in your plot that you don't see in previous z3801,3805,3816 plots.  The peaks in the +/- 40 ns range are the same as on my Z3816a (which uses the same GPS receiver).
> The data file also had quite a few 0.000000000 TI values, which bounced then to 1.0e-8 etc.  So somewhere in the data paths, someone is doing the equivalent of a floor(TI error). So if you calculate averages on this kind of data and compare it to averages or SD on previous units, the results will be misleading.
> It's possible that the program Z38xx is incorrectly parsing these values and 'stripping the digits to the right' performing a floor(TI).   I can't tell because I only have the data after Z38xx parsed it.  Somebody who has one of these units and Z38xx could open the debug screen and capture it to a file and see if the '1 PPS to TI ns relative to GPS" has zeros to the right of the decimal point most of the time, or the response to the :PTIM:TINT? is 'stepping' as I described above.
> BTW - what do you see as the predicted uncertainty.
> Regards
> Ed
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list