NMEA messages

NMEA messages

Post by uaca » Wed, 23 Jun 2004 04:52:17



Hi all

I have tested with two units of the Garmin 35-HVS that the NMEA messages
are not syncronized with the PPS Pulse and that have an high jitter.

I tried the following by seting up the GPS to show only RMC or GGA messages

If I attach an osciloscope to the NMEA messages (RMC or GGA), I see that
these messages have an offset of +300ms. to +700ms

I setup the GPS as suggested in the GPS FAQ:

# NMEA reference
server 127.127.20.0 mode 2 version 4 prefer
fudge 127.127.20.0 time1 0.550
^^^^^ This is an average offset of the signal

# PPSkit's clock discipline
server 127.127.22.0

The high jitter of the NMEA messages makes to NTP stablish both servers
as falsetickers from time to time (reject them as a source of the Time).

Is this normal? I don't think so

Is there a solution?

Any comment or suggestion would be greatly appreciated.

Thanks in advance

Ulisses

Debian GNU/Linux: a dream come true
-----------------------------------------------------------------------------
"Computers are useless. They can only give answers." Pablo Picasso

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
 
 
 

NMEA messages

Post by patric » Thu, 24 Jun 2004 01:47:56

In article < XXXX@XXXXX.COM >,


True. Depending on the current processing load in the Garmin GPS-35, the
NMEA strings may be delayed for some time (I've seen it at least up to
1 second).


Garmin's GPS-16 is supposed to be better at reducing this jitter. Probably
not that helpful to someone who already has a bunch of GPS-35s, huh?

We ended up having to "validate" the NMEA strings against the PPS to see
if we liked what we were seeing. If we saw NMEA strings that crossed over
the PPS, we threw away that second's data (ignored the NMEA strings for that
second). Plus we added code to see if what we got in the NMEA strings was
consistant with what we were expecting, and threw out what we didn't like.

The PPS itself was very stable, but the NMEA strings could not always be
trusted.

Patrick
========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
Patrick Klos Email: XXXX@XXXXX.COM
Klos Technologies, Inc. Web: http://www.yqcomputer.com/
==================== What goes around, comes around... =====================

 
 
 

NMEA messages

Post by Bart Smi » Thu, 24 Jun 2004 03:02:13


This seems not unreasonable. The main purpose of the time stated in the
NMEA messages is not to tell you what time it is, but what time the
other data (e.g. position) refers to.


Lucky you! If that is true, you can unambiguously number the seconds
that the PPS signal give you. I have a GPS receiver that has an offset
in a range wider than one second, so I cannot do this.


Yuck! ;-)


I think you should forget about using NMEA output for this purpose and
either use your receiver's binary mode if it has one or use another ntp
server and/or another reference clock (e.g. a radio clock) for
'numbering the seconds'.

--B
 
 
 

NMEA messages

Post by Richard B. » Thu, 24 Jun 2004 10:17:58


Have you considered using something other than these Garmin 35HVS?
From your description, they do not seem well suited to the task. Were
they designed as timing units? Or were they intended for navigational use?
 
 
 

NMEA messages

Post by David Schw » Thu, 24 Jun 2004 14:11:59


If you want to use a GPS unit for timing, you must use one that is
designed for this purpose and has specifications that explain what
performance you can expect for this purpose. Use it according to the
manufacturer's specifications and if you don't get the promised accuracy,
return it.

You are using a wrench as a screwdriver -- what did you expect?

DS
 
 
 

NMEA messages

Post by D. Hutchin » Wed, 30 Jun 2004 07:28:42


Similar problem here, using a trimble sv6 where the TSIP binary drifts 40
+- 40 m from the PPS. Solutions are

use calibrate to get the time1 value to the mean delay, and

add another peer, which is a local machine slaved off an internet time
server. With three clocks the system can unambigously ignore the TSIP when
it wanders, but stays locked to the PPS (which is of course stable). Not a
solution if you're on a small network, but it is I believe what David
Mills recommends

--David