Re: [time-nuts] Four hour cycle in GPS NMEA jitter

[Trent Piepho]

On Thu, 2017-03-23 at 08:28 +1300, Kiwi Geoff wrote:
> On 3/22/17, Trent wrote:
> > https://goo.gl/photos/JZhBbFKFzkBAykti6
> > Why would a GPS module produce jitter with a pattern like this?
> 
> Trent, I decided to R.T.F.M.(read the fantastic manual ;-)
> 
> It looks like that in your Telit module, there is a mode called
> 
> ---
> Client Generated Extended Ephemeris (CGEE)

That sounds very promising!  Your FM is better than my FM, the "JN3
Hardware User Guide" revision 2, which has nothing in it about extended
ephemeris mode.

> CGEE data is always generated for a prediction interval of three days:
> - Consists of 18 blocks of 4-hour EE data blocks
> - Updated when a newly visible satellite is acquired

I'm indoors with a poor view of the sky, so I'm be surprised if new
satellites don't come into view throughout the day.  

> - Updated when new broadcast ephemeris is received from a tracked
> satellite and the current EE data block is nearing expiration

That explains the peak every four hours, assuming the EE data blocks are
synced to start at UTC (n*4):00 and not device power on.

> - On average, it takes 1.2 seconds per satellite for the receiver to
> calculate CGEE

That would easily explain the few outliers at the 4 hour mark.  But
std.dev. sure appears to increase for about 2 hours up to the 4 hour
mark, then rests back to a lower value for about 2 hours before
increasing again.  See attached graphs.  It's even more apparent when I
overlay each hour period on the same X axis.

That doesn't seem to fit the description of CGEE mode, but then again we
don't really know the algorithms used in the GPS receiver.  It's
possible that a calculation involving a 4 hour EE data table takes
longer, and thus produces more jitter in competing threads like NMEA
output, when the computation is using the end of the interval vs the
beginning.  E.g., a linear search for a line in the table to use.

> >From a quick glance at the manual, it looks like this mode can be
> turned off with:
> 
> AT$GPSIFIX=0

Unfortunately, the GPS's design as part of the IRU means I can't write
to it :(.  I'd really like to try that and see what happens.

Obviously the proper fix is to get PPS working and I've known that all
along.  I'm really more interested in the WHY of the four hour cycle.  I
think turning off CGEE will be the only way to know if that's the sole
explanation, or if there is more at play.
___
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] Four hour cycle in GPS NMEA jitter

[Kiwi Geoff]

On 3/22/17, Trent wrote:
> https://goo.gl/photos/JZhBbFKFzkBAykti6
> Why would a GPS module produce jitter with a pattern like this?

Trent, I decided to R.T.F.M.(read the fantastic manual ;-)

It looks like that in your Telit module, there is a mode called

---
Client Generated Extended Ephemeris (CGEE)

CGEE data is always generated for a prediction interval of three days:
- Consists of 18 blocks of 4-hour EE data blocks
- Updated when a newly visible satellite is acquired
- Updated when new broadcast ephemeris is received from a tracked
satellite and the current
EE data block is nearing expiration
- On average, it takes 1.2 seconds per satellite for the receiver to
calculate CGEE
---

So I think that is the cause of your 4 Hour NMEA latency issues, when
your Telit module is  creating a new EE (Extended Ephemeris) data set.

>From a quick glance at the manual, it looks like this mode can be
turned off with:

AT$GPSIFIX=0

That "should" remove your 4 hour NMEA latency issues (fingers crossed).

Regards, Geoff  ( Christchurch , New Zealand )
___
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] Four hour cycle in GPS NMEA jitter

[Mark Sims]

I did a lot of work in Lady Heather to add timing message arrival time analysis 
capability.  Heather has a "set the system clock to receiver time" function 
that is intended to be used on systems without access to something like NTP.  
By knowing the arrival time of the last byte of the timing message, Heather can 
set the system clock more accurately.  You can specify the message arrival time 
offset of the message time code or Heather uses a pre-computed typical value 
for the receiver.

Heather has a mode that can analyze and calculate the message timing offset for 
any receiver / cpu combination.  During the analysis it plots the message 
arrival time offset in milliseconds,  the jitter in the message arrival time,  
and ADEV/HDEV/MDEV and TDEV of those values.  When you exit message analysis 
mode it analyzes a histogram of the arrival time data to calculate an "optimum" 
arrival time offset to use for the system + receiver.

Most timing receivers that can operate in binary mode have rather consistent 
arrival times.  Some NMEA receivers can be quite good and others are rather 
problematic.  Some receivers have rather consistent time for long periods and 
then jump to a new "stable" value.  Also,  doing other things on the system 
during the analysis can cause spikes in the data.

Attached is a table of the arrival time offsets and standard deviations of 
several receivers.



Here are the results of measuring the difference between the time code in 
a GPS receiver time message and the arrival time of the last byte of 
the message.  POSITIVE values mean that the receiver sends the timing 
message AFTER the 1PPS pulse that it describes. The table also shows the 
standard deviation of the message arrival times.



The test configuration was a Compaq N610C laptop (2 GHz Pentium, hardware 
serial port) running Linux Ubuntu Mate 15.10).  The time of the message
arrival was from the system clock synced to NTP.  The receivers were tested 
in native binary protocol and, if supported, NMEA.  The com port was running
at the default value for the receiver.  If not specified that was 9600:8:N:1
Data was collected after the receiver had been tracking satellites for at 
least 1 hour and averaged over 4 hours.  The timings were also checked and
agree with those on a Raspberry PI 3 and a quad-core 3 GHz box.



Although measuring the arrival time of the first byte of the timing message
makes more technical sense (less variation due to timing message length and 
baud rate) these measurements are of the last byte of the message.  This was 
chosen to assist people trying to sync a clock to a GPS receiver without 
relying on the 1PPS pulse.  They are also useful to people that want to know
how long they have to process a timing message (like to set a sawtooth 
compensation delay line) before the next 1PPS pulse comes out.



A few receivers appear to not fully sync their timing message to some reference
clock.  This causes the timing message arrival time to follow a ramp curve.
The ramp size is fairly small in most receivers.



Device Protocol Firmware  (msg-arrival)  sdev

 (msecs)

=    =   =

Thunderbolt TSIPApp:3.0 GPS:10.243.7 *6.2   (gold 
box)

Thunderbolt TSIPApp:2.22 GPS:10.2   54.6 *   10.2   (red 
box)

Resolution-TTSIPGPS:1.2699.4 *5.4

Res-T SMT   TSIPGPS 2.7393.2 *   63.7

Res-T SMT   Motorola(12ch)  HW 3010 SW:0.03.0  519.7 *   49.1

Starloc II  TSIPApp:1.10 GPS:1.2   266.0 *7.2

Nortel NTBW50AA TSIPGPS 10.460.8 *1.2   (made 
by Trimble)

Nortel NTGS50AA TSIPGPS 10.550.8 *2.4   (made 
by Trimble) 

Nortel NTPB15AA TSIPGPS 10.162.8 *1.4   (made 
by Trimble) 

Nortel NTPX26AB TSIPGPS 10.159.8 *1.4   (made 
by Trimble, aka Nortel GSPR) 



NVS NC08C-CSM   BINR 115.2K CSM24 04.08 20/10/1440.7 *7.3



Ublox LEA-6Tbinary  6.02 (36023)   206.0 *4.4

Ublox LEA-6TNMEA6.02 (36023)   144.5 *   11.1

Ublox Neo6M binary  7.03 (45969)   197.1 *9.3

Ublox Neo6M NMEA7.03 (45969)   137.6 *8.4

Ublox 7 binary  1.00 (59842)   178.4 *2.6

Ublox 7 NMEA1.00 (59842)   146.2 *7.9

Ublox NEO-8Mbinary  2.01 (75350)   207.7 *9.1

Ublox NEO-8MNMEA2.01 (75250)   181.2 *8.0


V.KEL SIRFIII   binary  GSW3.2.5   417.0 *6.1

V.KEL SIRFIII   NMEAGSW3.2.5   385.0 *5.0


Navspark Mini   bin+NMEA 115.2K 1.7.27 15.8.18 170.8 *7.1

Navspark NS-T   

Re: [time-nuts] Four hour cycle in GPS NMEA jitter

[Kiwi Geoff]

> https://goo.gl/photos/JZhBbFKFzkBAykti6
> Why would a GPS module produce jitter with a pattern like this?

Trent, I must admit I have not seen such a four hour "spike" before in
the NMEA latency, however a clue may be that the GPS ephemeris
(broadcast by the SV's) orbit description is valid only for a "4 Hour
Period" - before the SUN and Moon and other factors make it too
imprecise.

I did a Google search for

telit ephemeris gps "4 hour"

and found that the TELIT appears to have some algorithm that enhances
somehow the ephemeris. Maybe your 4 hour spike (which appears to be
for 4 seconds each time) is evidence of your TELIT doing some extra
homework involving the ephemeris - just a guess on my part.

Regards, Geoff (Christchurch , New Zealand)
___
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] Four hour cycle in GPS NMEA jitter

[Bob Camp]

HI


> On Mar 21, 2017, at 4:52 PM, Trent Piepho  wrote:
> 
> Thanks to all who responded.  Yes, I know PPS is the way get a more
> accurate timestamps.  That is the plan, but it takes more time to write
> FPGA programs.  The surprise is not that there is considerable jitter on
> the NMEA output, but rather why does the jitter have patterns in it?
> 
> It seems significant enough that someone who had used NMEA for time
> would have noticed it before.  Unless it is somehow unique to me, but
> how would that be?

The simple answer is that we *do* see it and that’s why we use PPS and not 
NMEA. 
Arrival times on NMEA sentences varying over a 100 ms region is not at 
all unusual. Getting them out “exactly on time” is not a priority compared to 
the
other tasks overworked CPU in the module needs to perform. 

Bob


> 
> On Tue, 2017-03-21 at 16:43 -0700, Kiwi Geoff wrote:
>> For example, here is a (24 hour) graph from my Garmin 18x (firmware
>> v3.6) where a plot (thanks to Hal) shows the start time of the NMEA
>> sentence from the time of the GPS 1PPS edge.
> 
> I've tried to duplicate that graph to some extent, plotting NMEA
> sentence offset from system clock.  Attached and also at
> https://goo.gl/photos/TBEg27SRqY2EQW3HA
> 
> In this plot I've taken the offset from the system clock, fitted it to a
> simple f(x)=a+b*x model, then plotted the residuals.  I.e., I've taken
> out a constant clock drift (of 5.7 ppm).  While interesting, there
> doesn't appear to be any pattern that synced to every four hours start
> at 00 UTC time.  It's not a lot different than your plot from the 18x.
> 
> However, if I plot not the raw offsets, but the mean and variance over
> an interval, we see there is a clear four hour pattern, and it's synced!
> 
> https://goo.gl/photos/JZhBbFKFzkBAykti6
> 
> Why would a GPS module produce jitter with a pattern like this?
> 
> 
> On Tue, 2017-03-20 at 15:19 -0700, Chris Albertson wrote:
>> If you have an FPGA available then you could significantly improve
>> system time keeping.   Currently the PPS interrupts the CPU to
>> snapshot internal counter.   Unpredictable interrupt latency lifts NTP
>> timekeeping to about 1 or 2 microseconds but is the counter snap
>> shooting could be moved out to FPGA hardware there would be no unknown
>> latency and you could get NTP to break a "magic" 1uS barrier.   I've
> 
> My initial idea for the PPS hardware would be to start a counter in the
> FPGA, there is a good 100 MHz clock for this, on the edge of the PPS
> signal.  The irq handler can use the value of the counter to subtract
> out most of the software interrupt latency.  Most, since the Linux PPS
> framework wants to create the system clock component of the PPS
> timestamp pair _after_ the hardware part is generated.  There is some
> delay and jitter in how long it takes the CPU to create the system
> timestamp after I have created the latency compensated PPS timestamp.
> ___
> 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] Four hour cycle in GPS NMEA jitter

[Chris Albertson]

Wow.   350 nS.  I had not been following this for the last few years.   It
seems the ARM is a simply CPU with much more predictable interrupts timing.


One might ask way you'd need such good internal timing.   What got me into
this years ago was scientific data acquisition.  I wanted to time stamp the
data.   So I had a Linux based PC connect periodically to the Internet
using a dial-up phone modem and run NTP.   It worked well enough.A GPS
receiver at $10,000 each was out of the question.



On Mon, Mar 20, 2017 at 5:06 PM, Gary E. Miller  wrote:

> Yo Chris!
>
> On Mon, 20 Mar 2017 15:19:25 -0700
> Chris Albertson  wrote:
>
> > I've only hear of 1 uS being broken with hardware.
>
> A Raspberry Pi can get down to a Standard Deviation of about 350 nano
> seconds
> using NTPsec..
>
> https://blog.ntpsec.org/2017/02/01/heat-it-up.html
>
>
> RGDS
> GARY
> 
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> 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.
>



-- 

Chris Albertson
Redondo Beach, California
___
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] Four hour cycle in GPS NMEA jitter

[Gary E. Miller]

Yo Chris!

On Mon, 20 Mar 2017 15:19:25 -0700
Chris Albertson  wrote:

> I've only hear of 1 uS being broken with hardware.

A Raspberry Pi can get down to a Standard Deviation of about 350 nano seconds
using NTPsec..

https://blog.ntpsec.org/2017/02/01/heat-it-up.html


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

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
___
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] Four hour cycle in GPS NMEA jitter

[Kiwi Geoff]

Hi Trent,

> But first things first.  I'm just grabbing the time from NMEA sentences.
> And there's quite a bit of jitter there!  Clearly using the first sentence
> output by the GPS is critical.  I've tried to account for any time delays in
> the software.  I think it's the GPS module that is creating the largest
> source of jitter.  It appears to go in four hour cycles, peaking at 0:00Z,
> 4:00Z, 8:00Z, etc.

>From my observations on various GPS receivers, the 'time" that the
NMEA data is transmitted can be highly variable.

For example, here is a (24 hour) graph from my Garmin 18x (firmware
v3.6) where a plot (thanks to Hal) shows the start time of the NMEA
sentence from the time of the GPS 1PPS edge.

http://www.satsignal.eu/ntp/Garmin-18x-3.7.png

David Taylor explains more about this Garmin firmware variation here:

http://www.satsignal.eu/ntp/Garmin-GSP18x-LVC-firmware-issue.htm

Where an earlier version of the 18x, the latency could be so long
that it actually gave the timestamp for the wrong second !

So yes, beware of using the "transmit time" of NMEA sentences, many
GPS receivers appear to have a cuppa tea, a scone and solve a Sudoko
before telling us the time !

Regards, Kiwi Geoff  (Christchurch , New Zealand).
___
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] Four hour cycle in GPS NMEA jitter

[Bob Camp]

Hi


NMEA sentences are not the best thing to use for timing. If you *do* decide to 
use them, configure the 
receiver so that one and only one sentence comes out. Any time you have more 
than one, you run the risk
of collision in the serial buffer on the part. Next thing to do is to pick the 
shortest useful sentence you 
can find. In some cases you only have one option. 

Next up is to be sure that your PC is set up so that there is minimal lag in 
serial processing. That may not
be as simple as you might think. All modern OS’s head off to do “interesting 
things” from time to time. The
usual approach is to kill just about anything that *might* create an issue. 

Once you have all that, you start pruning the outliers and fitting to the 
center of the data. Since you don’t have
a super duper clock on your motherboard, you are fitting both the randomness of 
the clock and the GPS. The
answer is to go slow and look at data over a lot of samples. 

The other answer to all this is to use a GPS with a PPS out. Feed that into 
some sort of capture process and 
go from there. The result is likely to improve things by at least a couple 
orders of magnitude. 

Bob

> On Mar 20, 2017, at 5:00 PM, Trent Piepho  wrote:
> 
> Hello time nuts,
> 
> I'm working on a custom embedded Linux device, with a custom inertial 
> reference unit, which contains a GPS module.   The module is a Telit JN3, 
> which is based on the SiRFSTAR IV I believe.  I'd like to use the GPS to sync 
> the Linux system clock.  Eventually I'd like to use the PPS signal, which is 
> routed to a FPGA that's part of the CPU, to implement a custom PPS hardware 
> module that I can write a kernel driver for and use the Linux hardpps system. 
>   And maybe make that feedback to the CPU's main clock source, since the FPGA 
> also controls that and could create a PLL between the TCXO that serves as the 
> master clock signal and the CPU's source clock.
> 
> But first things first.  I'm just grabbing the time from NMEA sentences.  And 
> there's quite a bit of jitter there!  Clearly using the first sentence output 
> by the GPS is critical.  I've tried to account for any time delays in the 
> software.  I think it's the GPS module that is creating the largest source of 
> jitter.  It appears to go in four hour cycles, peaking at 0:00Z, 4:00Z, 
> 8:00Z, etc.
> 
> Does this sound like something that one would expect with the NMEA output of 
> a non-timing GPS?  Is it related to satellite orbits?  Or perhaps is has 
> something to do with the design of the SiRFStar IV?
> 
> I'll attach a graph of what I'm seeing.  If the attachment doesn't come 
> though it's viewable at https://goo.gl/photos/JtYfJCpRSZb3hCnM8.
> 
> Methodology for the graph:
> System clock is left free running and not disciplined, after an initial one 
> time set based on the GPS time.
> On each NMEA GGA sentence, sent at 1 Hz, the system clock's offset from the 
> NMEA timestamp is measured.
> Each minute, the mean, std.dev, min and max are found for the last 60 offset 
> samples.  This is plotted on the graph.
> Any outlier samples, defined as more than 3 sigma from the previous mean, are 
> also plotted.
> Concurrently, the chrony NTP daemon is running and monitoring the IT dept's 
> NTP server, but NOT being used to set the local system clock.
> Once a minute, the system clock's offset to chrony's idea of the NTP server's 
> clock is also measured.  Chrony is using an algorithm based on median 
> filtering to get its idea of the NTP server's clock.
> The NTP server is just a windows domain controller synced to the internet NTP 
> pool and far from a precision source.
> ___
> 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] Four hour cycle in GPS NMEA jitter

[Chris Albertson]

> Does this sound like something that one would expect with the NMEA output of 
> a non-timing GPS?  Is it related to satellite orbits?  Or perhaps is has 
> something to do with the design of the SiRFStar IV?
>

Remember the phone based time service? "At the tome time time will be
 BEEP"  With a GPS the NEMA sentence take the place of the spoken
words on the phone.   The NEMA specification allows the sentences to
up to one second "off".   That said most GPS receivers do MUCH better
than the NEMA spec but you should never count on non-specified
performance in a professional design.   The PPS is of course doing the
job of the BEEP on the old phone system.  Set you watch based on the
beep, not NEMA.

If you have an FPGA available then you could significantly improve
system time keeping.   Currently the PPS interrupts the CPU to
snapshot internal counter.   Unpredictable interrupt latency lifts NTP
timekeeping to about 1 or 2 microseconds but is the counter snap
shooting could be moved out to FPGA hardware there would be no unknown
latency and you could get NTP to break a "magic" 1uS barrier.   I've
only hear of 1 uS being broken with hardware.You would actually
not ned to write much software to make this happen, just move the
counter outside the CPU to the FPGA and you about have it.


Chris Albertson
Redondo Beach, California
___
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] Four hour cycle in GPS NMEA jitter

[Trent Piepho]

Hello time nuts,

I'm working on a custom embedded Linux device, with a custom inertial reference 
unit, which contains a GPS module.   The module is a Telit JN3, which is based 
on the SiRFSTAR IV I believe.  I'd like to use the GPS to sync the Linux system 
clock.  Eventually I'd like to use the PPS signal, which is routed to a FPGA 
that's part of the CPU, to implement a custom PPS hardware module that I can 
write a kernel driver for and use the Linux hardpps system.   And maybe make 
that feedback to the CPU's main clock source, since the FPGA also controls that 
and could create a PLL between the TCXO that serves as the master clock signal 
and the CPU's source clock.

But first things first.  I'm just grabbing the time from NMEA sentences.  And 
there's quite a bit of jitter there!  Clearly using the first sentence output 
by the GPS is critical.  I've tried to account for any time delays in the 
software.  I think it's the GPS module that is creating the largest source of 
jitter.  It appears to go in four hour cycles, peaking at 0:00Z, 4:00Z, 8:00Z, 
etc.

Does this sound like something that one would expect with the NMEA output of a 
non-timing GPS?  Is it related to satellite orbits?  Or perhaps is has 
something to do with the design of the SiRFStar IV?

I'll attach a graph of what I'm seeing.  If the attachment doesn't come though 
it's viewable at https://goo.gl/photos/JtYfJCpRSZb3hCnM8.

Methodology for the graph:
System clock is left free running and not disciplined, after an initial one 
time set based on the GPS time.
On each NMEA GGA sentence, sent at 1 Hz, the system clock's offset from the 
NMEA timestamp is measured.
Each minute, the mean, std.dev, min and max are found for the last 60 offset 
samples.  This is plotted on the graph.
Any outlier samples, defined as more than 3 sigma from the previous mean, are 
also plotted.
Concurrently, the chrony NTP daemon is running and monitoring the IT dept's NTP 
server, but NOT being used to set the local system clock.
Once a minute, the system clock's offset to chrony's idea of the NTP server's 
clock is also measured.  Chrony is using an algorithm based on median filtering 
to get its idea of the NTP server's clock.
The NTP server is just a windows domain controller synced to the internet NTP 
pool and far from a precision source.
___
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.