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?

On Tue, 2017-03-21 at 16:43 -0700, Kiwi Geoff wrote:

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:

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.

HI

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

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)

On 3/22/17, Trent wrote:

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.

turned off with:

AT$GPSIFIX=0

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

Regards, Geoff  ( Christchurch , New Zealand )

On Thu, 2017-03-23 at 08:28 +1300, Kiwi Geoff wrote:

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.

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.

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.

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.

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.