Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Hal Murray]

michael.c...@sfr.fr said:
> The relevant NTP leap-seconds-list file can be downloaded with anonymous ftp
> from the pub directory at time.nist.gov.  (The leap-seconds-list file is a
> symbolic link to the data file leap-seconds.3676924800 in the same
> directory. ) 

The NIST servers at that "host" don't work very well for FTP.  That host name 
rotates across their NTP servers and a lot of those sites don't have a FTP 
server on that machine.

Some of the sites work.
  ftp://utcnist.colorado.edu/pub/

The IETF has a copy, but it hasn't been updated yet.
  http://www.ietf.org/timezones/data/

USNO has a similar version:
  ftp://tycho.usno.navy.mil/pub/ntp/
Sometimes it doesn't work.  ??

Meinberg has a version:
  http://www.meinberg.de/download/ntp/leap-seconds.list


-- 
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] Trimble 63090/73090/65256

[Bryan _]

All:
Have seen these offered on Ebay, but was curious which model has the better 
specs and a overall better unit. Can't find much on the internet for 
datasheets. I assume the 73xxx is the later model?. Or maybe the boards are all 
the same and it's just the OCXO that has the different part numbers.
Cheers

-=Bryan=-
  
___
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] How does sawtooth compensation work?

[David]

On Mon, 18 Jul 2016 22:01:01 -0700, you wrote:

>> It would be interesting to look at the data to see if you can find the sort 
>
>Hi Hal,
>
>There's lots of examples of sawtooth patterns at: 
>http://leapsecond.com/pages/MG1613S/
>
>In particular there's this monster: 
>http://leapsecond.com/pages/MG1613S/tic-72-hour.gif
>
>It's simple for a microprocessor-based GPSDO with its TIC to realize when it's 
>getting too lost in a hanging bridge. There are a number of ways around the 
>problem. My favorite is gluing a resistor on top of the GPS chip and pumping a 
>few tens of mW through it when you want the bridge to stop.
>
>Here's the proof-of-concept: http://leapsecond.com/pages/vp/heater.htm
>
>/tvb

Universal timer/counters and equivalent time sampling DSOs can have
this problem when their timebase ends up synchronized with the signal
they are measuring.  Some carefully modulate their timebase to prevent
this.

When I was testing my Garmin 18x against my Racal-Dana 1992, I could
see it happen when the outside temperature was just right.
___
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] How does sawtooth compensation work?

[Tom Van Baak]

> It would be interesting to look at the data to see if you can find the sort 

Hi Hal,

There's lots of examples of sawtooth patterns at: 
http://leapsecond.com/pages/MG1613S/

In particular there's this monster: 
http://leapsecond.com/pages/MG1613S/tic-72-hour.gif

It's simple for a microprocessor-based GPSDO with its TIC to realize when it's 
getting too lost in a hanging bridge. There are a number of ways around the 
problem. My favorite is gluing a resistor on top of the GPS chip and pumping a 
few tens of mW through it when you want the bridge to stop.

Here's the proof-of-concept: http://leapsecond.com/pages/vp/heater.htm

/tvb


- Original Message - 
From: "Hal Murray" 
To: "Nick Sayer" 
Cc: "Discussion of precise time and frequency measurement" 
; "Hal Murray" 
Sent: Monday, July 18, 2016 9:41 PM
Subject: Re: [time-nuts] How does sawtooth compensation work?


> 
> nsa...@kfu.com said:
>> Yes, thatâ?Ts true. Given the facilities I have available with the present
>> hardware, I donâ?Tt believe I have much choice. I am not confident that I
>> could tell the difference between noise in the phase detection system and
>> PPS jitter variations that small. If the PA6H receiver gave sawtooth
>> corrections, Iâ?Td be able to do better. 
> 
> It would be interesting to look at the data to see if you can find the sort 
> of pattern that a sawtooth correction would help and where a hanging bridge 
> might cause confusion.
> 
> If the bridge isn't hanging, the data samples should be spread over a range 
> that is the clock period of the GPS unit.  Round that up to 100 ns.  I doubt 
> if you will see that with a PC.
> 
> On the other hand, you can get the same sort of pattern with a PPS over USB.  
> That would be a ms wide and easy for a PC to get time stamps much finer 
> grained than that.
> 
> 
> -- 
> 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] How does sawtooth compensation work?

[David]

On Mon, 18 Jul 2016 21:41:51 -0700, you wrote:

>> Or use the sawtooth compensation value  to control an external variable 
>> delay line circuit
>
>Hi Mark,
>
>Right, one example is https://datasheets.maximintegrated.com/en/ds/DS1020.pdf 
>or google for silicon delay line. Not sure they're in production still but you 
>can find them at the reseller sites.
>
>This delay line idea came up in the early Oncore-VP era gps mailing list (pre 
>time-nuts) by someone who first explored sawtooth correction and "hanging 
>bridges"; and it's the method that Rick then chose for his CNS Clock product 
>line. See: http://cnssys.com and http://gpstime.com for details.
>
>The advantage of the delay line method is that you don't need a nanosecond TIC 
>in the box; you correct for the sawtooth error live on the 1PPS. Very simple 
>and effective. The main GPS feed in my lab is a CNS Clock.
>
>This disadvantage is that if you already have a TIC connected to your 
>GPS/1PPS, there's not much point in pre-sawtooth correcting with a delay line. 
>The error is something that you're going to correct with arithmetic anyway so 
>there's no need to correct it in pulse phase. Rick's TAC32 software (that many 
>time nuts use) handles integration of serial TIC data (such as hp 53132) along 
>with GPS binary data to provide sawtooth corrected measurements. Several of 
>Rick's papers at the above sites explain this in fine detail.
>
>/tvb

Was their a specific reason to use an integrated variable delay line
for this versus a DAC, ramp generator, and comparator?

I ask because I have never seen a schematic for PPS jitter correction
which used the later.
___
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] GPS message jitter (was GPS for Nixie Clock)

[David]

The aged 16550 has various timeouts so an interrupt is triggered with
a partially full buffer even if it is below the interrupt threshold.
For implementations which do not do that, I assume they intend for the
UART to be polled regularly.

On Mon, 18 Jul 2016 23:42:34 -0400, you wrote:

>I can't speak for linux, but I have been bitten by FIFO watermark
>interrupts on micros before. If you set an interrupt for a 3/4 full FIFO,
>the last one or two characters will sit in the receive buffer and never
>trigger the RX interrupt. For a command -> response device which doesn't
>have a constant data-stream, It isn't until a PC application resends the
>command sequence that enough characters are in the FIFO to trigger the
>watermark interrupt. The easy fix was to interrupt on any single character
>being available, but would have been nice to have a timeout interrupt on a
>partially full FIFO.
___
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] How does sawtooth compensation work?

[Hal Murray]

nsa...@kfu.com said:
> Yes, that’s true. Given the facilities I have available with the present
> hardware, I don’t believe I have much choice. I am not confident that I
> could tell the difference between noise in the phase detection system and
> PPS jitter variations that small. If the PA6H receiver gave sawtooth
> corrections, I’d be able to do better. 

It would be interesting to look at the data to see if you can find the sort 
of pattern that a sawtooth correction would help and where a hanging bridge 
might cause confusion.

If the bridge isn't hanging, the data samples should be spread over a range 
that is the clock period of the GPS unit.  Round that up to 100 ns.  I doubt 
if you will see that with a PC.

On the other hand, you can get the same sort of pattern with a PPS over USB.  
That would be a ms wide and easy for a PC to get time stamps much finer 
grained than that.


-- 
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] How does sawtooth compensation work?

[Bob Stewart]

The LEA-6T is a good receiver, but it does have a sawtooth bug.  From time to 
time, when the sawtooth is approximately 10,299 (or is it 10,399?) ps, the sign 
of the sawtooth is wrong.  It's an easy fix:  Just check whether the sawtooth 
makes "this" corrected measurement worse than the previous corrected 
measurement.  I haven't checked the LEA-M8T for the bug, as I turned off the 
notice message when I corrected it.

Bob -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Mark Sims 
 To: "time-nuts@febo.com"  
 Sent: Monday, July 18, 2016 10:28 PM
 Subject: [time-nuts] How does sawtooth compensation work?
   
Or use the sawtooth compensation value  to control an external variable delay 
line circuit to move around the PPS signal from the receiver.  This can get 
interesting to implement if the receiver can output negative values for the 
sawtooth compensation (hint: add a bias to  the sawtooth value to make the 
compensation values always positive and adjust the antenna cable delay command 
to remove the bias value that you add.  Oh, and for some receivers you have to 
reverse the meaning of positive and negative sawtooth corrections and/or cable 
delay values).  It is even more interesting if the receiver outputs the 
sawtooth correction after the pulse it just generated... hint: get a different 
GPS receiver).


> A device that uses the sawtooth data shoves it into the control loop along 
> with the measured early / late information on the PPS. 

                         
___
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] How does sawtooth compensation work?

[Tom Van Baak]

> Or use the sawtooth compensation value  to control an external variable delay 
> line circuit

Hi Mark,

Right, one example is https://datasheets.maximintegrated.com/en/ds/DS1020.pdf 
or google for silicon delay line. Not sure they're in production still but you 
can find them at the reseller sites.

This delay line idea came up in the early Oncore-VP era gps mailing list (pre 
time-nuts) by someone who first explored sawtooth correction and "hanging 
bridges"; and it's the method that Rick then chose for his CNS Clock product 
line. See: http://cnssys.com and http://gpstime.com for details.

The advantage of the delay line method is that you don't need a nanosecond TIC 
in the box; you correct for the sawtooth error live on the 1PPS. Very simple 
and effective. The main GPS feed in my lab is a CNS Clock.

This disadvantage is that if you already have a TIC connected to your GPS/1PPS, 
there's not much point in pre-sawtooth correcting with a delay line. The error 
is something that you're going to correct with arithmetic anyway so there's no 
need to correct it in pulse phase. Rick's TAC32 software (that many time nuts 
use) handles integration of serial TIC data (such as hp 53132) along with GPS 
binary data to provide sawtooth corrected measurements. Several of Rick's 
papers at the above sites explain this in fine detail.

/tvb


- Original Message - 
From: "Mark Sims" 
To: 
Sent: Monday, July 18, 2016 8:28 PM
Subject: [time-nuts] How does sawtooth compensation work?


> Or use the sawtooth compensation value  to control an external variable delay 
> line circuit to move around the PPS signal from the receiver.  This can get 
> interesting to implement if the receiver can output negative values for the 
> sawtooth compensation (hint: add a bias to  the sawtooth value to make the 
> compensation values always positive and adjust the antenna cable delay 
> command to remove the bias value that you add.  Oh, and for some receivers 
> you have to reverse the meaning of positive and negative sawtooth corrections 
> and/or cable delay values).  It is even more interesting if the receiver 
> outputs the sawtooth correction after the pulse it just generated... hint: 
> get a different GPS receiver).
> 
> 
>> A device that uses the sawtooth data shoves it into the control loop along 
>> with the measured early / late information on the PPS. 
> 

___
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] Leap second to be introduced at midnight UTC December 31 this year

[Mike Cook]

As NTP comes up here quite a bit :

The IERS have recently issued a new Bulletin C  indicating that a Leap Second 
will be added at the end of December this year.
The Bulletin C can be seen at < 
https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat >
The relevant NTP leap-seconds-list file can be downloaded with anonymous ftp 
from the pub directory at time.nist.gov. 
(The leap-seconds-list file is a symbolic link to the data file 
leap-seconds.3676924800 in the same directory. )


"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
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] GPS message jitter (was GPS for Nixie Clock)

[Scott Stobbe]

Bob, Thanks for the nudge towards Ublox. USB was a bit of blue sky thinking.

I took a look at the LEA-M8F module which by default includes a VCTCXO.
Will also take care of disciplining an (VC)OCXO provided a DAC is included.
What was interesting to me is you can "exchange" time it, copied from the HW
Integration Manual


*1.6.3 FREQ_PHASE_IN0 / EXINT0, FREQ_PHASE_IN1 / EXTINT1 These two
frequency/phase inputs are provided for connecting an external source of
phase (pulse stream) or frequency reference into the module. The pulse
stream can be derived from a frequency reference or external
synchronization source. The module will measure and report the phase or
frequency offset of this input with respect to the current synchronization
source and optionally steer the related oscillator to bring the externally
derived pulses into alignment*


On Mon, Jul 18, 2016 at 7:28 PM, Bob Stewart  wrote:

> Interestingly enough, the Ublox LEA series of timing receivers has a USB
> port which you can connect directly to a USB cable.  Of course you want to
> use an ESD device, etc.
> Bob
>  -
> AE6RV.com
>
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>
>   From: jimlux 
>  To: time-nuts@febo.com
>  Sent: Monday, July 18, 2016 5:46 PM
>  Subject: Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)
>
> On 7/18/16 1:44 PM, Scott Stobbe wrote:
> > Well, I suppose in the case of USB, the host hardware (consumer PC) is
> not
> > going to have any special hardware. But, if a gps receiver implements a
> USB
> > interface, in addition to standard NEMA data, it could also report the
> > phase and frequency error of your USB clock (since it has to recover it
> > anyways to get the usb data).
>
> The USB interface timing is going to be buried deep, deep inside some
> microcontroller or ASIC. Imagine a FTDI part, for instance.  I can't
> imagine a GPS mfr caring enough about this to spend any money on trying
> to figure out how to do it.
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

[Scott Stobbe]

I can't speak for linux, but I have been bitten by FIFO watermark
interrupts on micros before. If you set an interrupt for a 3/4 full FIFO,
the last one or two characters will sit in the receive buffer and never
trigger the RX interrupt. For a command -> response device which doesn't
have a constant data-stream, It isn't until a PC application resends the
command sequence that enough characters are in the FIFO to trigger the
watermark interrupt. The easy fix was to interrupt on any single character
being available, but would have been nice to have a timeout interrupt on a
partially full FIFO.

On Mon, Jul 18, 2016 at 9:59 PM, Hal Murray  wrote:

>
> jim...@earthlink.net said:
> > except that virtually every UART in use today has some sort of buffering
> > (whether a FIFO or double buffering) between the CPU interface and the
> bits
> > on the wire, which completely desynchronizes the bits on the wire  from
> the
> > CPU interface.
>
> The idea was to reduce the CPU load processing interrupts by batching
> things
> up.
>
> Some of those chips generate an interrupt when the see a return or
> line-feed
> character.
>
> Most of them have an option to disable that batching.  On Linux the
> setserial
> command has a low_latency option.  I haven't measured the difference.  It
> would be a fun experiment.
>
>
> --
> 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.

[time-nuts] How does sawtooth compensation work?

[Mark Sims]

Or use the sawtooth compensation value  to control an external variable delay 
line circuit to move around the PPS signal from the receiver.  This can get 
interesting to implement if the receiver can output negative values for the 
sawtooth compensation (hint: add a bias to  the sawtooth value to make the 
compensation values always positive and adjust the antenna cable delay command 
to remove the bias value that you add.  Oh, and for some receivers you have to 
reverse the meaning of positive and negative sawtooth corrections and/or cable 
delay values).  It is even more interesting if the receiver outputs the 
sawtooth correction after the pulse it just generated... hint: get a different 
GPS receiver).


> A device that uses the sawtooth data shoves it into the control loop along 
> with the measured early / late information on the PPS. 

  
___
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] Lucent boxes

[Chris Waldrup]

Thanks Bill. 
I can use the RTFGm-XO by itself though, right?
I found a site with mods to extract the 10 MHz Signal rather than use the 15 
MHz. 

Chris

> On Jul 18, 2016, at 20:54, Bill Hawkins  wrote:
> 
> No, it does not work, unless you can reprogram the microprocessors. I
> speak from experience.
> 
> The older boxes used a GPS receiver that reported up to 6 satellites.
> The newer boxes report 8.
> 
> The messages that report satellite health have different lengths.
> 
> If the micro reports an error in the message, the box goes into
> "flywheel" mode (aka holdover).
> 
> The oscillators are undisciplined, wasting all of that GPS info.
> 
> An external PPS signal, if you could couple it in, would be ignored
> because the micro won't even try to use it.
> 
> Bill Hawkins
> 
> Note: I can't reprogram micros with unknown code.
> 
> 
> -Original Message-
> From: Douglas Baker
> Sent: Monday, July 18, 2016 4:39 PM
> 
> Chris,
> The RFTGm ("m" for miniature even though still a large box) is a later
> version of the RFTG line.  The XO unit houses the GPS receiver which is
> essential for disciplining.  Both boxes operate at 24 VDC and there is
> an interface cable drawing on line at KO4BB's web site. Never tried to
> hook them up together, but it might work.  Maybe others here may know.
> Good luck with it.
> 73's Doug
> On Jul 18, 2016 12:52 PM, "Chris Waldrup"  wrote:
> - snip 
> 
> ___
> 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] How does sawtooth compensation work?

[Nick Sayer via time-nuts]

> On Jul 18, 2016, at 3:55 PM, Hal Murray  wrote:
> 
>> The systems gravitate towards PLL time constants that average it all away. 
> 
> You are overlooking hanging bridges.

Yes, that’s true. Given the facilities I have available with the present 
hardware, I don’t believe I have much choice. I am not confident that I could 
tell the difference between noise in the phase detection system and PPS jitter 
variations that small. If the PA6H receiver gave sawtooth corrections, I’d be 
able to do better.
___
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] How does sawtooth compensation work?

[Nick Sayer via time-nuts]

> On Jul 18, 2016, at 4:20 PM, Bob Camp  wrote:
> 
> On a receiver with sawtooth correction, you have a manufacturer specific 
> message that gives
> you information on the state of the receiver. It is defined as either 
> applying to the next pps
> or to the pps that just came out. There is a field that may give you 
> picosecond resolution 
> (as opposed to accuracy) data on the proper location of the PPS edge. 
> Depending on how
> you evaluate the correction, it can get the jitter down below 1 ns (again, 
> jitter as opposed
> to accuracy). 
> 
> A device that uses the sawtooth data shoves it into the control loop along 
> with the measured 
> early / late information on the PPS. 

Thanks. That’s what I figured. Thanks to you and everyone for confirming that.


___
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] GPS message jitter (preliminary results)

[Mark Sims]

My LEA-6T board came out of one of those cheap Chinese drone pucks.  It has a 
ceramic patch antenna on board.   I have it sitting on the floor of the lower 
floor of a two-story, stucco over wire mesh house (not close to any windows).   
Same for some Sirf,  Venus, and standard Ublox receivers.   Real horrible 
signal quality, sat constellation changes every second,  total signal dropouts, 
 etc.  Yet they all provide excellent consistency  of their timing messages... 
ones gotta love what a modern GPS receiver can do... and some cost a whopping 
$5 (ok, three for $15, shipped from China) with antenna.
-
>  And, because I've seen it myself sometimes on some receivers, I will agree 
> that these NMEA timings are not necessarily consistent over long periods, 
> especially over episodes with significantly varying reception quality, 
> including loss and reacquisition of lock.

  
___
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] GPS message jitter (preliminary results)

[Mark Sims]

Yes,  turning on the display filter only gives an indication that one could 
gain some some benefit if they were to use the message arrival timing to 
implement some sort of NTP-ish algorithm to their 1PPS-less clock.

I have added some options to Lady Heather calculate the adevs of the message 
arrival time,  and also a flag to calculate the message times from the first 
byte of the message instead of the last byte.   That could be useful if you are 
dealing with variable length timing messages,  but a lot more difficult to make 
use of in a simple implementation of a clock.
Here the some xDEVs of the Z3801A :PTIM:TCOD? timing message arriving over a 
hardware serial port:
##  ADEV over 20292 points - sample period=1.0 secs#  1.000 tau  
4.5444e-001 (n=20290)#  2.000 tau  2.2716e-001 (n=20288)#  5.000 tau  
9.0872e-002 (n=20282)# 10.000 tau  4.5410e-002 (n=20272)# 20.000 tau  
2.2708e-002 (n=20252)# 50.000 tau  9.0837e-003 (n=20192)#100.000 tau  
4.5402e-003 (n=20092)#200.000 tau  2.2713e-003 (n=19892)#500.000 tau  
9.0882e-004 (n=19292)#   1000.000 tau  4.5393e-004 (n=18292)#   2000.000 tau  
2.2708e-004 (n=16292)#   5000.000 tau  9.0686e-005 (n=10292)#  1.000 tau  
4.5325e-005 (n=292)##  HDEV over 20292 points - sample period=1.0 secs#  
1.000 tau  4.7906e-001 (n=20289)#  2.000 tau  2.3946e-001 (n=20286)#  
5.000 tau  9.5752e-002 (n=20277)# 10.000 tau  4.7872e-002 (n=20262)# 
20.000 tau  2.3941e-002 (n=20232)# 50.000 tau  9.5741e-003 (n=20142)#
100.000 tau  4.7861e-003 (n=19992)#200.000 tau  2.3940e-003 (n=19692)#
500.000 tau  9.5769e-004 (n=18792)#   1000.000 tau  4.7845e-004 (n=17292)#
2000.000 tau  2.3930e-004 (n=14292)#   5000.000 tau  9.5558e-005 (n=5292)## 
 MDEV over 20292 points - sample period=1.0 secs#  1.000 tau  4.5444e-001 
(n=20290)#  2.000 tau  1.6062e-001 (n=20287)#  5.000 tau  4.0620e-002 
(n=20278)# 10.000 tau  1.4358e-002 (n=20263)# 20.000 tau  5.1625e-003 
(n=20233)# 50.000 tau  5.1755e-004 (n=20143)#100.000 tau  1.8317e-004 
(n=19993)#200.000 tau  6.5388e-005 (n=19693)#500.000 tau  9.3230e-006 
(n=18793)#   1000.000 tau  1.8958e-006 (n=17293)#   2000.000 tau  7.5843e-007 
(n=14293)#   5000.000 tau  1.0835e-007 (n=5293)##  TDEV over 20292 points - 
sample period=1.0 secs#  1.000 tau  2.6237e-001 (n=20290)#  2.000 tau  
1.8547e-001 (n=20287)#  5.000 tau  1.1726e-001 (n=20278)# 10.000 tau  
8.2898e-002 (n=20263)# 20.000 tau  5.9611e-002 (n=20233)# 50.000 tau  
1.4940e-002 (n=20143)#100.000 tau  1.0575e-002 (n=19993)#200.000 tau  
7.5503e-003 (n=19693)#500.000 tau  2.6913e-003 (n=18793)#
1000.000 tau  1.0945e-003 (n=17293)#   2000.000 tau  8.7576e-004 (n=14293)# 
  5000.000 tau  3.1279e-004 (n=5293)#
--
> At this point you're much better off not to use raw or filtered std dev at 
> all -- and just go with ADEV on the raw data, where the tau of the sigma is 
> explicit.
___
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] Allan Deviation recipe?

[Gary E. Miller]

Yo Tom!

On Mon, 18 Jul 2016 18:42:39 -0700
"Tom Van Baak"  wrote:

> Lots of ways to do it. There are GUI tools; command line tools, in C
> or Python or Matlab.

Got some C or Python?

> But to start with I highly recommend using John's TimeLab:
> http://www.ke5fx.com/timelab/readme.htm

I don't do Windows...  And I want this to auto-generate graphs for web
pages on RasPi's.  Lot's of RasPi's.  :-)

> Here's a sample 1PPS phase (time interval error) data file (from a hp
> 53132A): http://leapsecond.com/pages/MG1613S/log167.txt

Yeah, that looks sorta like what I have.

> Or here's the same file in a more standard format:
> http://leapsecond.com/pages/MG1613S/log167.dat

Just the facts there, i can do that.

> http://leapsecond.com/pages/MG1613S/log167-adev.gif

That's what I think I am looking for.

A bit of background.  Ntpd generates a number they call the Allan
Deviation, but the description looks like the Allan Variation, they
describe is as the minima in the Allan Deviation plot, when it has a U
shape.

They then use that number to set the PLL optimally.

Something looks fishy to me, so I want to visualize it, and help the
rest of the NTPsec team see it as well.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpSe9AaAM25o.pgp
Description: OpenPGP digital signature
___
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] GPS message jitter (was GPS for Nixie Clock)

[Hal Murray]

jim...@earthlink.net said:
> except that virtually every UART in use today has some sort of buffering
> (whether a FIFO or double buffering) between the CPU interface and the  bits
> on the wire, which completely desynchronizes the bits on the wire  from the
> CPU interface. 

The idea was to reduce the CPU load processing interrupts by batching things 
up.

Some of those chips generate an interrupt when the see a return or line-feed 
character.

Most of them have an option to disable that batching.  On Linux the setserial 
command has a low_latency option.  I haven't measured the difference.  It 
would be a fun experiment.


-- 
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] Lucent boxes

[Bill Hawkins]

No, it does not work, unless you can reprogram the microprocessors. I
speak from experience.

The older boxes used a GPS receiver that reported up to 6 satellites.
The newer boxes report 8.

The messages that report satellite health have different lengths.

If the micro reports an error in the message, the box goes into
"flywheel" mode (aka holdover).

The oscillators are undisciplined, wasting all of that GPS info.

An external PPS signal, if you could couple it in, would be ignored
because the micro won't even try to use it.

Bill Hawkins

Note: I can't reprogram micros with unknown code.


-Original Message-
From: Douglas Baker
Sent: Monday, July 18, 2016 4:39 PM

Chris,
The RFTGm ("m" for miniature even though still a large box) is a later
version of the RFTG line.  The XO unit houses the GPS receiver which is
essential for disciplining.  Both boxes operate at 24 VDC and there is
an interface cable drawing on line at KO4BB's web site. Never tried to
hook them up together, but it might work.  Maybe others here may know.
Good luck with it.
73's Doug
On Jul 18, 2016 12:52 PM, "Chris Waldrup"  wrote:
- snip 

___
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] Allan Deviation recipe?

[Tom Van Baak]

Gary,

Lots of ways to do it. There are GUI tools; command line tools, in C or Python 
or Matlab.

But to start with I highly recommend using John's TimeLab:
http://www.ke5fx.com/timelab/readme.htm

Here's a sample 1PPS phase (time interval error) data file (from a hp 53132A):
http://leapsecond.com/pages/MG1613S/log167.txt

Or here's the same file in a more standard format:
http://leapsecond.com/pages/MG1613S/log167.dat

Use TimeLab->File->Import ASCII. If you can't figure out the boxes let us know.
Then all you do is type p or f or a or t to cycle through phase, frequency, 
ADEV or TDEV plots.

You will see something like this:

http://leapsecond.com/pages/MG1613S/log167-phase.gif
http://leapsecond.com/pages/MG1613S/log167-freq.gif
http://leapsecond.com/pages/MG1613S/log167-adev.gif
http://leapsecond.com/pages/MG1613S/log167-tdev.gif

/tvb

- Original Message - 
From: "Gary E. Miller" 
To: "time-nuts" 
Sent: Monday, July 18, 2016 6:12 PM
Subject: [time-nuts] âo~Allan Deviation recipe?

Yo time-nuts!

I have a lot of logs of PPS offset data.  Basically system clock time
and PPS offset pairs.

Does it make sense to turn this data into an Allan Deviation plot?

If so, does anyone have a script or program to prepare the data
for gnuplot?

TIA.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
 g...@rellim.com  Tel:+1 541 382 8588

___
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] ✘Allan Deviation recipe?

[Gary E. Miller]

Yo time-nuts!

I have a lot of logs of PPS offset data.  Basically system clock time
and PPS offset pairs.

Does it make sense to turn this data into an Allan Deviation plot?

If so, does anyone have a script or program to prepare the data
for gnuplot?

TIA.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgp9xQ0N_ndx7.pgp
Description: OpenPGP digital signature
___
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] GPS message jitter (was GPS for Nixie Clock)

[Bob Stewart]

Interestingly enough, the Ublox LEA series of timing receivers has a USB port 
which you can connect directly to a USB cable.  Of course you want to use an 
ESD device, etc.
Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: jimlux 
 To: time-nuts@febo.com 
 Sent: Monday, July 18, 2016 5:46 PM
 Subject: Re: [time-nuts] GPS message jitter (was GPS for Nixie Clock)
   
On 7/18/16 1:44 PM, Scott Stobbe wrote:
> Well, I suppose in the case of USB, the host hardware (consumer PC) is not
> going to have any special hardware. But, if a gps receiver implements a USB
> interface, in addition to standard NEMA data, it could also report the
> phase and frequency error of your USB clock (since it has to recover it
> anyways to get the usb data).

The USB interface timing is going to be buried deep, deep inside some 
microcontroller or ASIC. Imagine a FTDI part, for instance.  I can't 
imagine a GPS mfr caring enough about this to spend any money on trying 
to figure out how to do it.

___
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] How does sawtooth compensation work?

[Tom Van Baak]

> I've read Tom's page about sawtooth PPS jitter and I believe I understand 
> where it comes from.

A GPS timing receiver solves a bunch of equations at least once a second and it 
ends up with a pretty good idea, numerically speaking, of what the time is 
internally, relative to its local oscillator.

It conveys this precise time to the user through a 1PPS signal. That pulse has 
to come from somewhere, and in practice the chip uses a gated edge of its LO 
clock to create the 1PPS edge. That means the 1PPS has some granularity. For 
example, if the LO is 25 MHz then the period is 40 ns which means the physical 
1PPS will be somewhere between -20 ns and +20 ns of the numerical ideal. 
Similarly, if a mythical GPS receiver had a 500 MHz LO, then the 1PPS could be 
+/- 1 ns of ideal.

So does that make sense so far? These GPS boards do not have a way to 
electronically generate an electrical pulse that has arbitrary sub-ns phase 
from a periodic clock edge. They just "cheat" and pick the closest LO clock 
edge and call that the 1PPS. Some receivers get 2x advantage by using either 
clock edge. So this is the jitter part of 1PPS.

Now the other factors are 1) the solutions of the equations tend to wander due 
to changing reception and changing SV positions. 2) the LO is likely not 
on-frequency or even deliberately off-frequency, so you get a modulus or 
beat-node effect, 3) the LO tends wander in frequency, especially since they 
are usually just cheap XO or TCXO. This is the wander part of 1PPS.

Combine all effects and you get a sawtooth pattern. It varies in look & feel 
quite a bit. I have some weird and wonderful plots at 
http://leapsecond.com/pages/MG1613S/ that show how the character of the 
sawtooth varies. The direction and pitch and

> What I'd like to understand is how sawtooth compensation works with receivers 
> that support it. Is it that I expect an NMEA sentence with a nanosecond 
> offset value that I add to 

The compensation is simple. The receiver knows the time internally. The 
receiver picks the closest edge that it can. It knows why it picked the edge it 
did and thus how far that edge is from the ideal. So it just outputs that 
number to the user in some binary message.

The user then, uses a TIC to compare the GPS/1PPS against the OCXO/1PPS, reads 
the binary quantization correction, and applies that to the TIC reading. With 
this scheme there is no need for the 1PPS to be *electrically* right as long as 
the GPS receiver also tells you *numerically* how far from right it is.

Does that help?

There are some tangents we could go down:
1) There are cases where the inherent dithering you get from sawtooth error is 
actually hugely beneficial to the design of a GPSDO.
2) One GPSDO design (Trimble Thunderbolt) is unique in that is has no sawtooth 
problem or TIC or XO or TCXO at all. Instead it directly uses the high-quality 
OCXO as the receiver's LO. They get away with this clean solution because they 
are a company that makes their own receiver h/w.
3) Carrier phase receivers with external clock input.

/tvb

- Original Message - 
From: "Nick Sayer via time-nuts" 
To: "Chris Arnold via time-nuts" 
Sent: Monday, July 18, 2016 3:31 PM
Subject: [time-nuts] How does sawtooth compensation work?


> I've read Tom's page about sawtooth PPS jitter and I believe I understand 
> where it comes from.My current GPSDOs ignore the phenomenon. Certainly at 
> the moment, I'm satisfied with that.  The systems gravitate towards PLL time 
> constants that average it all away. 
> 
> What I'd like to understand is how sawtooth compensation works with receivers 
> that support it. Is it that I expect an NMEA sentence with a nanosecond 
> offset value that I add to any phase difference observation that I get?
> 
> Sent from my iPhone

___
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] How does sawtooth compensation work?

[Bob Stewart]

Hi Nick,

Let's use the example of a Ublox timing receiver.  In the TIM-TP data package, 
there is a qErr value, which is the quantization error of the *next* PPS pulse 
output by the receiver.  At the next PPS, you would subtract that from the 
unwrapped phase measurement your GPSDO makes and that would give you the actual 
phase difference between your OCXO (or generated PPS) and what Tom has called 
"The PPS", which is the pulse occurring exactly at the top of the second --- 
give or take coax length, etc.
Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Nick Sayer via time-nuts 
 To: Chris Arnold via time-nuts  
 Sent: Monday, July 18, 2016 5:31 PM
 Subject: [time-nuts] How does sawtooth compensation work?
   
I've read Tom's page about sawtooth PPS jitter and I believe I understand where 
it comes from.    My current GPSDOs ignore the phenomenon. Certainly at the 
moment, I'm satisfied with that.  The systems gravitate towards PLL time 
constants that average it all away. 

What I'd like to understand is how sawtooth compensation works with receivers 
that support it. Is it that I expect an NMEA sentence with a nanosecond offset 
value that I add to any phase difference observation that I get?

Sent from my iPhone
___
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] How does sawtooth compensation work?

[Bob Camp]

Hi

The sawtooth process “picks” the closest clock edge and spits out the PPS based 
on it.

If the internal TCXO is off of a point that divides to 1Hz, the edge guess 
changes fairly often
and you can average it out. A drifting TCXO will (effectively) never be at a 
modulo 1 Hz 
frequency long enough to matter. 

If the TCXO happens to hit a modulo 1 Hz point *and* remain fairly stable, the 
pick process
will always pick the same edge of the clock. Now the averaging process stops 
working. The
edge guess is no longer bouncing back and forth. If you graph what happens, it 
is a parabolic 
looking structure in the data between two triangle waves. The normal term for 
this is a hanging 
bridge. 

The gotcha is that depending on the TCXO, the temperature, and the guess 
process, the bridge
can “hang in there” for quite a while. If it hangs on one edge of the clock for 
a few hundred seconds,
the offset will likely chug right through your filter. 

==

On a receiver with sawtooth correction, you have a manufacturer specific 
message that gives
you information on the state of the receiver. It is defined as either applying 
to the next pps
or to the pps that just came out. There is a field that may give you picosecond 
resolution 
(as opposed to accuracy) data on the proper location of the PPS edge. Depending 
on how
you evaluate the correction, it can get the jitter down below 1 ns (again, 
jitter as opposed
to accuracy). 

A device that uses the sawtooth data shoves it into the control loop along with 
the measured 
early / late information on the PPS. 

Bob


> On Jul 18, 2016, at 6:31 PM, Nick Sayer via time-nuts  
> wrote:
> 
> I've read Tom's page about sawtooth PPS jitter and I believe I understand 
> where it comes from.My current GPSDOs ignore the phenomenon. Certainly at 
> the moment, I'm satisfied with that.  The systems gravitate towards PLL time 
> constants that average it all away. 
> 
> What I'd like to understand is how sawtooth compensation works with receivers 
> that support it. Is it that I expect an NMEA sentence with a nanosecond 
> offset value that I add to any phase difference observation that I get?
> 
> Sent from my iPhone
> ___
> 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] How does sawtooth compensation work?

[Hal Murray]

> The systems gravitate towards PLL time constants that average it all away. 

You are overlooking hanging bridges.


-- 
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] GPS message jitter (was GPS for Nixie Clock)

[jimlux]

On 7/18/16 1:44 PM, Scott Stobbe wrote:

Well, I suppose in the case of USB, the host hardware (consumer PC) is not
going to have any special hardware. But, if a gps receiver implements a USB
interface, in addition to standard NEMA data, it could also report the
phase and frequency error of your USB clock (since it has to recover it
anyways to get the usb data).


The USB interface timing is going to be buried deep, deep inside some 
microcontroller or ASIC. Imagine a FTDI part, for instance.  I can't 
imagine a GPS mfr caring enough about this to spend any money on trying 
to figure out how to do it.


___
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] How does sawtooth compensation work?

[Nick Sayer via time-nuts]

I've read Tom's page about sawtooth PPS jitter and I believe I understand where 
it comes from.My current GPSDOs ignore the phenomenon. Certainly at the 
moment, I'm satisfied with that.  The systems gravitate towards PLL time 
constants that average it all away. 

What I'd like to understand is how sawtooth compensation works with receivers 
that support it. Is it that I expect an NMEA sentence with a nanosecond offset 
value that I add to any phase difference observation that I get?

Sent from my iPhone
___
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] GPS message jitter (preliminary results)

[Tom Van Baak]

> Most definitely... if I turn on Lady Hather's display filter (which does a 
> sliding average
> of "n" readings)  the standard deviation and jitter values drop dramatically. 
>   

Be careful here. We're using standard deviation here as a measure of the 
instability, or noise, or jitter of the NMEA edge. Adding a sliding average 
filter to the raw data is (an accidental) method to remove that noise; the very 
thing you were trying to measure. So claiming "jitter values drop dramatically" 
is not exactly a surprise. Effectively what's happening is that you are 
changing the "tau" of the std dev.

At this point you're much better off not to use raw or filtered std dev at all 
-- and just go with ADEV on the raw data, where the tau of the sigma is 
explicit.

/tvb

- Original Message - 
From: "Mark Sims" 
To: 
Sent: Monday, July 18, 2016 1:49 PM
Subject: [time-nuts] GPS message jitter (preliminary results)


> Most definitely... if I turn on Lady Hather's display filter (which does a 
> sliding average of "n" readings)  the standard deviation and jitter values 
> drop dramatically.   With a 60 second filter the deviation was down to around 
> .15 msecs and the peak-peak jitter below a millisecond.  Average and rms 
> values of the jitter was 2.4 microseconds.  I saw similar improvements with 
> the cheap NMEA receivers.
> 
> --
>>  Looking at the data by eyeball (maybe not the best way):  A 10 to 30 sample 
>> finite impulse average (boxcar) would do a lot for the result.  

___
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] Lucent boxes

[Douglas Baker]

Chris,
The RFTGm ("m" for miniature even though still a large box) is a later
version of the RFTG line.  The XO unit houses the GPS receiver which is
essential for disciplining.  Both boxes operate at 24 VDC and there is an
interface cable drawing on line at KO4BB's web site. Never tried to hook
them up together, but it might work.  Maybe others here may know.  Good
luck with it.
73's Doug
On Jul 18, 2016 12:52 PM, "Chris Waldrup"  wrote:

> Hi Everyone,
>
> I have two Lucent RFTG boxes in my workshop. The XO is a loaner.
> I'm curious if they will interface with each other or (most likely) they
> are a different series as the interface connectors on each have a different
> number of pins.
> One is marked RFTG-u REF 0
> The other is RFTGm-II-XO
>
> Thanks in advance.
>
> Chris
> KD4PBJ
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] GPS message jitter (preliminary results)

[Mark Sims]

Most definitely... if I turn on Lady Hather's display filter (which does a 
sliding average of "n" readings)  the standard deviation and jitter values drop 
dramatically.   With a 60 second filter the deviation was down to around .15 
msecs and the peak-peak jitter below a millisecond.  Average and rms values of 
the jitter was 2.4 microseconds.  I saw similar improvements with the cheap 
NMEA receivers.

--
>  Looking at the data by eyeball (maybe not the best way):  A 10 to 30 sample 
> finite impulse average (boxcar) would do a lot for the result.
>  
___
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] GPS message jitter (was GPS for Nixie Clock)

[jimlux]

On 7/18/16 12:35 PM, David wrote:

On Mon, 18 Jul 2016 11:43:32 -0700, you wrote:


except that virtually every UART in use today has some sort of buffering
(whether a FIFO or double buffering) between the CPU interface and the
bits on the wire, which completely desynchronizes the bits on the wire
from the CPU interface.

Determinism in UART timing between the CPU bus interface and the "bits
on the wire" has never been something that is specified.  You can go
back to venerable parts like the 8251, and there's no spec in the data
sheet.
( there's a tCR specified as 16 tCY for the read setup time from CTS*,
DSR* to READ* assert.  And tSRX (2 usec min) and tHRX (2 usec min) for
the setup and hold of the internal sampling pulse relative to RxD. And
20 tCY as a max from center of stop bit to RxRDY, and then whatever the
delay is from the internal RxRDY to the bus read)


Long ago I remember seeing a circuit design or application note using
an 8250 or similar where the UART start bit was gated so that the
leading edge could be used for precision synchronization.


And it probably depended on idiosyncratic behavior of the 8250 and 
fooling with the transmit clock input to the chip.   That is, a part 
that claimed "8250 emulation" may or may not work the same.  Sort of 
like Printer ports on IBM PCs.. they'd all work with a unidirectional 
Centronics printer, some would work as a bidirectional port, some wouldn't.


As soon as you get to parts that have the baudrate generator internally 
or which are highly integrated multiprotocol chips (like the Zilog do 
everything dual serial port) it gets much trickier.


I had a terrible time a couple years ago getting a synchronous RS422 
interface (1 pair with clock at symbol rate + 1 pair with data) that 
would easily interface to a PC.  Most of the "synchronous RS422" 
interfaces out there use one of the multiprotocol chips which support 
BiSync, HDLC, etc. and they try to find sync characters or stuff flags, 
etc. but not very many support "raw synchronous"










___
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] GPS message jitter (was GPS for Nixie Clock)

[Scott Stobbe]

Well, I suppose in the case of USB, the host hardware (consumer PC) is not
going to have any special hardware. But, if a gps receiver implements a USB
interface, in addition to standard NEMA data, it could also report the
phase and frequency error of your USB clock (since it has to recover it
anyways to get the usb data).

I don't have the answer here, but usb-audio ICs suffer similar problems in
clock distribution. The gist of it seems to be locking on the hosts SOF
packets. PROGRAMMABLE CLOCK GENERATION AND SYNCHRONIZATION FOR USB AUDIO
SYSTEMS 

On Mon, Jul 18, 2016 at 2:43 PM, jimlux  wrote:

> On 7/18/16 8:51 AM, Scott Stobbe wrote:
>
>> I suppose it is one of those cases where, the GPS designers decided you
>> shouldn't ever use the serial data for sub-second timing, and consequently
>> spent no effort on serial latency and jitter.
>>
>> Most UARTs I have come across have been synthesized with a 16x baud clock
>> and included flow control. It would not have been too much effort to spec
>> latency as some mu ±100 ns and jitter of ±1/(16*baud).
>>
>> For 9600 baud, the jitter on the start bit would be ±6.5 us.
>>
>> If CTS was resampled a 1 full bit time (9600 baud), the jitter would
>> be ±104 us.
>>
>>
>
> except that virtually every UART in use today has some sort of buffering
> (whether a FIFO or double buffering) between the CPU interface and the bits
> on the wire, which completely desynchronizes the bits on the wire from the
> CPU interface.
>
> Determinism in UART timing between the CPU bus interface and the "bits on
> the wire" has never been something that is specified.  You can go back to
> venerable parts like the 8251, and there's no spec in the data sheet.
> ( there's a tCR specified as 16 tCY for the read setup time from CTS*,
> DSR* to READ* assert.  And tSRX (2 usec min) and tHRX (2 usec min) for the
> setup and hold of the internal sampling pulse relative to RxD. And 20 tCY
> as a max from center of stop bit to RxRDY, and then whatever the delay is
> from the internal RxRDY to the bus read)
>
>
> There's "what we observed in a running circuit" or "what we inferred from
> knowing the internal design".
>
>
> Since a huge number of serial ports these days are implemented with a USB
> interface, the timing uncertainty is even greater, because you're dealing
> with the 8kHz frame timing on USB.
>
>
> This is why PTP compatible interfaces added time tagging to the PHY layer.
>
>
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] GPS message jitter (preliminary results)

[Mark Sims]

I have seen some reports of some Skylab GPS boards that had some rather sketchy 
GPS code.   A friend had one that was off around 0.5 degrees in longitude... 
but only if your location was between +/- 90 degrees longitude.  He was on the 
east coast and had the problem.  He sent it to me (96 dgrees west) and I didn't 
see it.  Same for a tester on the west coast.  He spend weeks going over his 
code and could not find what the problem was.   He sent me a raw data dump and 
sure enough, I got the same (wrong) location that he did.   I seem to remember 
the NMEA messages were correct, but the binary message (which was in Ublox 
format) had the issue.
--

For comparison with your data, attached is the ADEV+MDEV plot [1] for the 
SkyLab / MG1613S GPS board [2], the one with the 350 ms offset and 11 ms stdev. 

___
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] GPS message jitter (preliminary results)

[Bob Camp]

Hi

Very nice data !!

Hmmm….. software averaging against the MCU (or FPGA) clock source …  
NTP seems to get some pretty good results down into the single digit ms (or 
lower)
doing that based on some equally jittery  inputs. 

Looking at the data by eyeball (maybe not the best way):  A 10 to 30 sample 
finite 
impulse average (boxcar) would do a lot for the result.  Yes, you could get 
much fancier. 

Bob


> On Jul 18, 2016, at 3:50 PM, Mark Sims  wrote:
> 
> That plot was from a 12 hour run.   I've done 48+ hour runs and did not see 
> anything strange.   I'm not currently measuring the offset of the message 
> from the 1PPS,  just the stability/jitter in the timings of the last byte of 
> the timing message.   If the timing message offset time from 1PPS jumped, it 
> would show up as a spike in the message jitter (and if the offset jump was 
> not particularly large, would be hidden in the normal noise of the 
> end-of-timing-message time stamps.   
> 
> Adding the message jitter measurements to Lady Heather was a quick and dirty 
> 5 line code hack to investigate whether one needed a 1PPS signal to usefully 
> drive a clock display.  So far it looks like you could easily get +/- 30 msec 
> stability from a cheap GPS without the 1PPS (and much better with some 
> software averaging)... and that is on a non-real-time, multi-tasking 
> operating system going through who knows how many layers of serial port 
> message buffering, etc.  Using a dedicated micro to do the deed should be 
> quite a bit better.  You should, of course,  measure and compensate for your 
> chosen receiver's message offset time to the 1PPS to get an accurate time 
> display.
> 
> --
> 
> How long did you run your tests?
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

[time-nuts] GPS message jitter (preliminary results)

[Mark Sims]

That plot was from a 12 hour run.   I've done 48+ hour runs and did not see 
anything strange.   I'm not currently measuring the offset of the message from 
the 1PPS,  just the stability/jitter in the timings of the last byte of the 
timing message.   If the timing message offset time from 1PPS jumped, it would 
show up as a spike in the message jitter (and if the offset jump was not 
particularly large, would be hidden in the normal noise of the 
end-of-timing-message time stamps.   

Adding the message jitter measurements to Lady Heather was a quick and dirty 5 
line code hack to investigate whether one needed a 1PPS signal to usefully 
drive a clock display.  So far it looks like you could easily get +/- 30 msec 
stability from a cheap GPS without the 1PPS (and much better with some software 
averaging)... and that is on a non-real-time, multi-tasking operating system 
going through who knows how many layers of serial port message buffering, etc.  
Using a dedicated micro to do the deed should be quite a bit better.  You 
should, of course,  measure and compensate for your chosen receiver's message 
offset time to the 1PPS to get an accurate time display.

--

How long did you run your tests?  
___
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] GPS message jitter (preliminary results)

[Tom Van Baak]

> most receivers get the time messages out within a window less than 50 
> milliseconds
> wide with a standard deviation of less than 10 milliseconds.

Hi Mark,

For comparison with your data, attached is the ADEV+MDEV plot [1] for the 
SkyLab / MG1613S GPS board [2], the one with the 350 ms offset and 11 ms stdev.

The results are impressive. But I'd still recommend people use 1PPS instead of 
NMEA edges for clock timing.

And, because I've seen it myself sometimes on some receivers, I will agree that 
these NMEA timings are not necessarily consistent over long periods, especially 
over episodes with significantly varying reception quality, including loss and 
reacquisition of lock.

/tvb

[1] http://leapsecond.com/pages/MG1613S/log167.gif
[2] http://leapsecond.com/pages/MG1613S/
___
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] GPS message jitter (was GPS for Nixie Clock)

[David]

On Mon, 18 Jul 2016 11:43:32 -0700, you wrote:

>except that virtually every UART in use today has some sort of buffering 
>(whether a FIFO or double buffering) between the CPU interface and the 
>bits on the wire, which completely desynchronizes the bits on the wire 
>from the CPU interface.
>
>Determinism in UART timing between the CPU bus interface and the "bits 
>on the wire" has never been something that is specified.  You can go 
>back to venerable parts like the 8251, and there's no spec in the data 
>sheet.
>( there's a tCR specified as 16 tCY for the read setup time from CTS*, 
>DSR* to READ* assert.  And tSRX (2 usec min) and tHRX (2 usec min) for 
>the setup and hold of the internal sampling pulse relative to RxD. And 
>20 tCY as a max from center of stop bit to RxRDY, and then whatever the 
>delay is from the internal RxRDY to the bus read)

Long ago I remember seeing a circuit design or application note using
an 8250 or similar where the UART start bit was gated so that the
leading edge could be used for precision synchronization.
___
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] GPS message jitter (was GPS for Nixie Clock)

[Scott Stobbe]

I am happy to hear you issue was resolved. What I meant to say is the
problem could also be mitigated using the UART's flow control, this could
be done by the original GPS designers or by an end user if the CTS line is
pined out. Gating the UART with a conservative delay, say 500 ms from the
time mark or PPS signal. The serial string would just sit in the transmit
buffer until the fixed delay expires and the UART starts transmitting.

On Mon, Jul 18, 2016 at 12:19 PM, David J Taylor <
david-tay...@blueyonder.co.uk> wrote:

> I suppose it is one of those cases where, the GPS designers decided you
> shouldn't ever use the serial data for sub-second timing, and consequently
> spent no effort on serial latency and jitter.
>
> Most UARTs I have come across have been synthesized with a 16x baud clock
> and included flow control. It would not have been too much effort to spec
> latency as some mu ±100 ns and jitter of ±1/(16*baud).
>
> For 9600 baud, the jitter on the start bit would be ±6.5 us.
>
> If CTS was resampled a 1 full bit time (9600 baud), the jitter would
> be ±104 us.
> ==
>
> Scott,
>
> You're right about the design priorities (and we have had to take Garmin
> to task on this, but they did fix the problem), but it's not the UART which
> is the major problem, but that the tiny CPU inside is taking a variable
> amount of time to have the serial data ready.  We're talking tens, possibly
> hundreds of milliseconds peak-to-peak jitter.
>
> Cheers,
> David
> --
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-tay...@blueyonder.co.uk
> Twitter: @gm8arv
> ___
> 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] GPS message jitter (preliminary results)

[Gary E. Miller]

Yo Mark!

On Mon, 18 Jul 2016 18:30:08 +
Mark Sims  wrote:

> A few generalizations:   most receivers get the time messages out
> within a window less than 50 milliseconds wide with a standard
> deviation of less than 10 milliseconds.

How long did you run your tests?  My experience is that the GPS may be
stable for hours, then have a sudden shift in offset to a new stable
offset.

I would hope your tests were at lesat 24 hours long.


> The Navspark Venus based receivers have the greatest differences..  

Yes, they can be horrible.  But there is a soultion.  There is
a configuration option to tell the Navspark GPS to try to output
near the top of the second.  Then the results are much better.

> Surprisingly, the communications channel type is not that
> important.   I've seen little difference between hardware serial
> ports and a USB / RS-232 adapter.

How long did you run your tests?  I have also found that USB 1.1 NMEA
can be very stable. Maybe +/-100 microSeconds or better instead of the
expected +/- 500 microSeconds.  This is because the 1024/samples per
second on the USB port is linked to the system clock.  But after a few
days of solid performence the USB serial time may shift 1/1024th of a
second and stay at this new stable point.

You will find when mearusing the PPS that the Serial/USB difference is
much larger.  Maybe 1,000x or more.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgptko6HEtTSR.pgp
Description: OpenPGP digital signature
___
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] GPS message jitter (preliminary results)

[Mark Sims]

Ooops, that tboltjit.gif plot was actually from a Trimble Resolution-T SMT 
timing receiver running with an indoor antenna,  not a Thunderbolt.  The 
Thunderbolt with an outdoor antenna is about twice as good.

I just added the ability to feed the timing jitter value to Lady Heather's real 
time ADEV calculation code.   I doing a run with a Z3801A at the moment... (at 
500 tau it's down to 9E-4) 
___
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] GPS message jitter (was GPS for Nixie Clock)

[Bob Camp]

Hi

> On Jul 18, 2016, at 12:19 PM, David J Taylor  
> wrote:
> 
> I suppose it is one of those cases where, the GPS designers decided you
> shouldn't ever use the serial data for sub-second timing, and consequently
> spent no effort on serial latency and jitter.
> 
> Most UARTs I have come across have been synthesized with a 16x baud clock
> and included flow control. It would not have been too much effort to spec
> latency as some mu ±100 ns and jitter of ±1/(16*baud).
> 
> For 9600 baud, the jitter on the start bit would be ±6.5 us.
> 
> If CTS was resampled a 1 full bit time (9600 baud), the jitter would
> be ±104 us.
> ==
> 
> Scott,
> 
> You're right about the design priorities (and we have had to take Garmin to 
> task on this, but they did fix the problem), but it's not the UART which is 
> the major problem, but that the tiny CPU inside is taking a variable amount 
> of time to have the serial data ready.  We're talking tens, possibly hundreds 
> of milliseconds peak-to-peak jitter.


….. but …. 

It’s been a long time since 9600 baud was a fast baud rate. It is pretty common 
these
days to run at 115K baud on something like this. Indeed a number of GPS modules 
will only
run at that speed or faster if you want the full feature set to work. Most 
modern modules 
will run much faster than 115K if you want them to. The simple fact that they 
need the higher
baud rate to get all the data out forces a better serial i/o approach in a 
modern module. 

In order for sawtooth correction to work, the relation of the serial message to 
the pps
needs to be pretty well defined. It either is talking about the *next* pps or 
about the
*prior* pps edge. If it is ambiguous relative to the pps, you can not be sure 
of what it
is relating to. 

If the module has a pps out and has sawtooth correction (or uses the same code 
base
as one that does), the serial timing string is not going to be all over the 
place. They no 
longer are running itty bitty CPU’s in these things. ARM’s running at >= 400 MHz
are the typical approach these days.  Running out of clock cycles to get it all
done went away at least 5 years ago and more like 10 years for the “usual 
suspects” that
you see in timing applications. 

Can you still find a 20 or 30 year old module on eBay that has issues? Sure you 
can. It’s
not what I would call a modern part, even if it is being sold as “new in box”. 
Can you find
modules that simply do not keep time at all? Sure you can. That’s not the 
serial port’s fault. 
It’s the fact that that specific module is broke. Don’t use that one, move on. 

Bob

> 
> Cheers,
> David
> -- 
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-tay...@blueyonder.co.uk
> Twitter: @gm8arv 
> ___
> 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] GPS message jitter (was GPS for Nixie Clock)

[jimlux]

On 7/18/16 8:51 AM, Scott Stobbe wrote:

I suppose it is one of those cases where, the GPS designers decided you
shouldn't ever use the serial data for sub-second timing, and consequently
spent no effort on serial latency and jitter.

Most UARTs I have come across have been synthesized with a 16x baud clock
and included flow control. It would not have been too much effort to spec
latency as some mu ±100 ns and jitter of ±1/(16*baud).

For 9600 baud, the jitter on the start bit would be ±6.5 us.

If CTS was resampled a 1 full bit time (9600 baud), the jitter would
be ±104 us.




except that virtually every UART in use today has some sort of buffering 
(whether a FIFO or double buffering) between the CPU interface and the 
bits on the wire, which completely desynchronizes the bits on the wire 
from the CPU interface.


Determinism in UART timing between the CPU bus interface and the "bits 
on the wire" has never been something that is specified.  You can go 
back to venerable parts like the 8251, and there's no spec in the data 
sheet.
( there's a tCR specified as 16 tCY for the read setup time from CTS*, 
DSR* to READ* assert.  And tSRX (2 usec min) and tHRX (2 usec min) for 
the setup and hold of the internal sampling pulse relative to RxD. And 
20 tCY as a max from center of stop bit to RxRDY, and then whatever the 
delay is from the internal RxRDY to the bus read)



There's "what we observed in a running circuit" or "what we inferred 
from knowing the internal design".



Since a huge number of serial ports these days are implemented with a 
USB interface, the timing uncertainty is even greater, because you're 
dealing with the 8kHz frame timing on USB.



This is why PTP compatible interfaces added time tagging to the PHY layer.



___
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] GPS message jitter (preliminary results)

[Mark Sims]

I added the ability for Lady Heather to measure a plot the difference of the 
arrival times of each timing message (actually the time when Lady Heather 
receives the last byte of the timing message from the operating system).   The 
end-of-message arrival time is time stamped to nominally nanosecond resolution 
using either the Windows QueryPerformanceCounter() value or the Linux 
nanosecond res clock function... (actual resolutions are system depenent).  I 
measured several different receivers in both NMEA mode and their native binary 
mode.

A few generalizations:   most receivers get the time messages out within a 
window less than 50 milliseconds wide with a standard deviation of less than 10 
milliseconds.   Timing receivers tend to do a better job of it.  The Trimble 
Thunderbolt and Resolution-T receivers are particularly good (5 msec window, 1 
msec standard deviation).  The Z3801A is also rather good (10 msec window, 1.2 
msec standard deviation).

There is usually not much difference the performance of the NMEA messages and 
the native binary messages.   The Navspark Venus based receivers have the 
greatest differences..  their NMEA messages are about twice as consistent than 
the binary messages.  Occasionally you see a minor hicccup in the message time 
when the operating system goes off and does something else (particularly like 
when waking up from a screen saver mode).

The number of messages the receiver sends during each timing interval does not 
seem to make much difference.  I have a Ublox 8M tracking 20+ satellites and 
sending over a dozen NMEA messages each second.  It gets the timing message out 
within a 30 msec window, 6.5 msec standard deviation.

Surprisingly, the communications channel type is not that important.   I've 
seen little difference between hardware serial ports and a USB / RS-232 
adapter.   Even running a TCP/IP link between Dallas and Seattle gave 
surprisingly consistent messages (with a couple of spike to +/- 100 millisecond 
or so differences.   All of the tested receivers were running at 9600 baud,  
the Navspark at 115,200,  the Z3801A at 19,200.

Attached is a plot of the Trimble Thunderbolt running on a 3 GHz, single core 
Windows XP box.

  ___
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] 5061B Service Manual, Page 8-57 (BEAM I, if LOW)

[Oz-in-DFW]

And there is a free app from Steve Gibson to flip the registry bits
required to make sure you don't upgrade without agreeing.

https://www.grc.com/never10.htm



On 7/17/2016 3:31 PM, John Allen wrote:
> Hi to all - If you have been updated to Windows 10, you have 30 days to go 
> back to your old Windows.
> It takes from 5 to 30 or more minutes depending on computer speed.
>
> Here's how:
> http://www.howtogeek.com/220723/how-to-uninstall-windows-10-and-downgrade-to-windows-7-or-8.1/
>
> John K1AE
>
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Dan Rae
> Sent: Sunday, July 17, 2016 12:14 AM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] 5061B Service Manual, Page 8-57 (BEAM I, if LOW)
>
> On 7/16/2016 8:11 PM, Christopher Hoover wrote:
>> My 5061B (with FTS tube) has a low beam current.  Maybe 7 on the meter when
>> adjusted onto the primary peak.
>>
>> I bought the Ops and Service manual, but my copy is missing page 8-57 (and
>> 8-56 if that exists).
>>
> Christopher,
>
> Given that Foldout Page 8-57 (Beam I LOW Troubleshooting Chart) is Fig 
> 8-30 and Fig 8-29 (The HIGH version) is Page 8-55, I don't think there 
> actually is a Page 8-56.
>
> Since my computer was forcibly updated to WIN10 my scanner no longer 
> works with it but if you don't get a better offer I will try to get an 
> old laptop to work with it tomorrow and  scan Fig 8-30.  It's too hard 
> to abstract what you need, and will have to be in segments anyway.
>
> Dan
>
> ac6ao
> ___
> 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.
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> ___
> 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.


-- 
mailto:o...@ozindfw.net
Oz
POB 93167 
Southlake, TX 76092 (Near DFW Airport) 



___
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] Lucent boxes

[Chris Waldrup]

Hi Everyone,

I have two Lucent RFTG boxes in my workshop. The XO is a loaner. 
I'm curious if they will interface with each other or (most likely) they are a 
different series as the interface connectors on each have a different number of 
pins. 
One is marked RFTG-u REF 0
The other is RFTGm-II-XO

Thanks in advance. 

Chris
KD4PBJ


___
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] GPS message jitter (was GPS for Nixie Clock)

[David J Taylor]

I suppose it is one of those cases where, the GPS designers decided you
shouldn't ever use the serial data for sub-second timing, and consequently
spent no effort on serial latency and jitter.

Most UARTs I have come across have been synthesized with a 16x baud clock
and included flow control. It would not have been too much effort to spec
latency as some mu ±100 ns and jitter of ±1/(16*baud).

For 9600 baud, the jitter on the start bit would be ±6.5 us.

If CTS was resampled a 1 full bit time (9600 baud), the jitter would
be ±104 us.
==

Scott,

You're right about the design priorities (and we have had to take Garmin to 
task on this, but they did fix the problem), but it's not the UART which is 
the major problem, but that the tiny CPU inside is taking a variable amount 
of time to have the serial data ready.  We're talking tens, possibly 
hundreds of milliseconds peak-to-peak jitter.


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


___
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] GPS message jitter (was GPS for Nixie Clock)

[Scott Stobbe]

I suppose it is one of those cases where, the GPS designers decided you
shouldn't ever use the serial data for sub-second timing, and consequently
spent no effort on serial latency and jitter.

Most UARTs I have come across have been synthesized with a 16x baud clock
and included flow control. It would not have been too much effort to spec
latency as some mu ±100 ns and jitter of ±1/(16*baud).

For 9600 baud, the jitter on the start bit would be ±6.5 us.

If CTS was resampled a 1 full bit time (9600 baud), the jitter would
be ±104 us.

On Sat, Jul 16, 2016 at 3:13 PM, Mark Sims  wrote:

> I just added some code to Lady Heather to record and plot the time that
> the timing message arrived from the receiver (well, actually the time that
> the screen update routine was called,  maybe a few microseconds
> difference).I am using my existing GetMsec() routine which on Windoze
> actually has around a 16 msec granularity.  The Linux version uses the
> Linux nanosecond clock (divided down to msec resolution).  I just started
> testing it on a Ublox 8M in NMEA and binary message mode...  really
> surprising results to come shortly...
>
>
> ___
> 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] GPS message jitter (was GPS for Nixie Clock)

[Martin Burnicki]

Mark, Chris,

Chris Albertson wrote:
> Can't you take care of this in the build system?  I never go near
> Windows, the last version I used was Win 95.  But on other systems I
> always use something like the GNU Auto tools cmake or whatever and
> part of the process is to check for the availability of each system
> call and library and then the source is built using what's on that
> specific machine.   I'd guess that there is something like this in
> Windows.  Is GNU Autoconf ported to Windows?  If so then use
> QueryPerformanceCounter() if it is available.  It seems much cleaner
> to that care of this kind off thing in the build process

The QueryPerformanceCounter() (QPC) call is available on all Windows
Versions since Windows NT. I'm not sure if it was supported on Windows
9x, though. The windows 9x versions were more like DOS with a graphical
user interface.

QPC is implemented in the Windows Hardware Abstraction Layer (HAL). At
least Windows versions around XP were shipped with different versions of
the HAL DLL, and the Windows installer determined during installation
which version to use. The different versions used different timers on
the particular PC, and depending on the timer which was actually used
(TSC, HPET, PMTIMER, ...) the QPC call worked with different clock
frequencies and thus provided different resolution.

When Windows XP was current then current CPU types both from Intel and
AMD had problems with the TSC since the TSC clock frequency could change
when the CPU clock frequency changed due to power savings, and TSCs
might not have been synchronized across different cores in the same
physical CPU.

This is why you could force Windows XP always to use the PMTIMER which
is part of the ACPI support chipset, and if I remember correctly the SP3
for Windows XP did this automatically to avoid problems with the TSC.
You can use the QueryPerformanceFrequency() call to determine the clock
frequency of the timer used for QPC, and the frequency typically tells
you which timer/counter circuit or the PC it actually is.

One important point is that the TSC can be read very much faster than
one of the other timers/counters since its just reading a CPU register,
while other circuits are part of the chip set and need to be accessed
via a peripheral bus.

Modern Windows versions determine much more reliably if the TSC can be
used without problems, or not, and use it, if appropriate.

Modern Windows versions (Windows 8 an newer) also provide some new API
calls which return the system time with higher resolution/precision than
original API calls.

For example, the original API call GetSystemTimeAsFileTime() only had a
coarse resolution of 0.5 to ~ 16 ms, depending on the Windows version
and some conditions. Now there's a new API call
GetSystemTimePreciseAsFileTime() which always provides 100 ns
precision/resolution. Similar with some other call for which there are
"Precise" variant available now.

A common practice is to check at runtime if a "Precise" call is
supported by the OS version under which the application is currently
running.

For example, at program startup try to import the symbol
GetSystemTimePreciseAsFileTime and set up a function pointer with it. If
the symbol can't be imported (e.g. if running on windows XP) set the
pointer to GetSystemTimeAsFileTime, and get system time stamps only by
calls via that pointer. So you have a single executable which benefits
from the "Precise" call if available, and falls back to the standard
call if it's not available.

This page
https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408%28v=vs.85%29.aspx

provides a good overview of the available functions.

Martin

___
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] GPS message jitter (was GPS for Nixie Clock)

[David J Taylor]

You can also use the QueryPeformanceCounter and related functions for 
better precision.


From: Mark Sims

Heather's gotta work with XP (and maybe Win98)...  too many people 
(including me) run it on old trashy laptops, so no fancy pants new fangled 
Windoze calls allowed...


In the past I've avoided the use of QueryPerformanceCounter due to potential 
issues with AMD processors, multi-core processors and multi-processor 
systems,  inaccurate/invalid reported CPU clock frequency (TSC tick count 
divisor) values,  variable clock rate systems, etc.   I'm now back to using 
it, but have added an option for switching back to GetTickCount() and it's 
16 msec granularity.  I'm getting very good results so far.

___

Mark,

You can easily use the new functions if they are available simply by asking 
Kernel32.dll whether it knows about them.  If not, use the old function, if 
so, use the new.  The result from old and new is identical in format, just 
better in precision in the newer.




==
var
 FPreciseFT: procedure (var lpSystemTimeAsFileTime: TFileTime); stdcall;

begin
 FKernel32 := LoadLibrary ('kernel32.dll');
 if FKernel32 <> 0 then
   begin
   FPreciseFT := GetProcAddress (FKernel32, 
'GetSystemTimePreciseAsFileTime');

   if @FPreciseFT = nil then
 FPreciseFT := GetProcAddress (FKernel32, 'GetSystemTimeAsFileTime');
   FreeLibrary (FKernel32);
   end;
end.
==

Cheers,
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


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