Lady Heather does measurements on the arrival time of message vs the time
encoded in the time message being used and compensates the time code for the
offset. It uses a default value that depends upon the receiver type or can use
a user specified value. For generic NMEA receivers you should
Hi
On many receivers the buffering process on the messages has an impact on
arrival times.
If you *only* use one message and never use any others that might not be a big
deal. Most
applications use a number of messages to be sure that the software knows what
is really
going on.
You can
stevesommars...@gmail.com said:
> Do people regularly characterize the arrival times of NMEA sentences at ~msec
> resolution?
On this list? What sort of response were you expecting?
I'm interested in NMEA timing for use with NTP.
There are lots of low cost GPS units available. Most use USB.
Just to let everyone know what I ended up doing and seems to be working for
me...
I grabbed a raspberry pi. Hooked up the TICC via USB to it.
I also hardwired my TTL-level NMEA serial output to the serial input on the
raspberry pi's header.
I wrote a tiny script which sets up both serial ports,
> I can capture the NMEA data and the TICC data - this is not a problem.
> But I'd really like to be able to capture both datasets in some sort of
> time-correlated way, so I can easily post-process the TICC data using the
> quantization error data. I can probably throw something together in
> On Sep 14, 2019, at 5:20 PM, Mark Sims wrote:
> Lady Heather should do the job. It supports using a GPS device as the main
> input device and a TICC/counter as an auxiliary input device (/ei= command
> line option). Writing a .xml format log file will have all the data. On a
> TICC you
Lady Heather should do the job. It supports using a GPS device as the main
input device and a TICC/counter as an auxiliary input device (/ei= command
line option). Writing a .xml format log file will have all the data. On a
TICC you should connect chA to the 1PPS signal (and optionally the
In Unix there is the "ts" (aka timestamp) command will be a good start as
long as you have newlines (pure NMEA has CRLF at the end of each line but
I've come across devices that use other variations).
http://manpages.ubuntu.com/manpages/trusty/man1/ts.1.html
e.g. I like to use the "%.s" format
One of the GPS modules I'm currently playing with outputs quantization
error data in the NMEA data.
I can capture the NMEA data and the TICC data - this is not a problem.
But I'd really like to be able to capture both datasets in some sort of
time-correlated way, so I can easily post-process the