[time-nuts] Capturing NMEA and TICC timestamp data in time-correlated way?

[Steven Sommars]

Do people regularly characterize the arrival times of NMEA sentences at
~msec resolution?  (I did this once for a Garmin GPS18 with a poorly
performing firmware version:
https://www.satsignal.eu/ntp/Garmin-GSP18x-LVC-firmware-issue.htm  )

Late-arriving $GPRMC sentences could confuse NTP servers.

On Thu, Sep 19, 2019 at 8:00 AM Forrest Christian (List Account) <
lists at packetflux.com> wrote:

> 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, then uses cat to
> pipe them through ts (as suggested by another poster, thank you!), and then
> writes them out to a separate file for each serial port, so I have a TICC
> and a NMEA file, with each line being timestamped.
>
> The advantage of this is that I can set it on the bench and it will happily
> run for some time without worrying about windows doing an update or
> similar.
>
> This seems to be working for me.   I also wrote a couple of python scripts,
> the main one being one which extracts a Channel A and a Channel B timestamp
> file suitable for timelab from each of the files.    If I see an oddity I
> now have enough data to be able to track the oddity back to a specific
> period of time in the NMEA file.  Has already helped quite a bit as I now
> don't have to wonder if this was a GPS signal event or something else.
>
> I'll probably spend some time in a couple of days writing another chunk of
> python which will extract relevant data from both the TICC and NMEA files
> and then try some adjustments of the TICC data based on the NMEA data.
>
> On Tue, Sep 17, 2019 at 8:01 AM Hal Murray <hmurray at megapathdsl.net>
> wrote:
>
> >
> > > 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
> > Python
> > > or C to do this, but before I went through the effort, I figured I
> would
> > ask
> > > if there is a standard tool I haven't been able to find yet which is in
> > > common use.
> >
> > How accurately do you want to stamp the NMEA data?  If the time on your
> PC
> > is
> > good enough, then software will work.  If you can feed a PPS to both the
> > TICC
> > and your PC, then you can get accurate timings on a second signal to the
> > TICC.
> >
> > With a good PPS, ntpd should hold the time on a PC better than a ms.
> >
> > You don't actually need good time on the PC, or a good PPS.  All you need
> > is a
> > signal that is ballpark of once a second that you can feed to both the PC
> > and
> > TICC.  You can use the PPS capture on the PC to tell you when it arrives
> > without using it to control the time.
> >
> > If you want more accurate timings on the NMEA data, I think you will need
> > to
> > build something to indicate the start of the NMEA data clump and feed
> that
> > signal to the TICC.  The idea is to turn a long burst of transitions into
> > a
> > single pulse so you don't swamp the TICC.
> >
> > [It might just work.  I'm assuming the TICC will be overloaded by the
> NMEA
> > bit
> > stream, but it will probably get the first bit and lots of others.  You
> > can
> > throw away the others.  Has anybody tried something like this?]
> >
> > You could do it in hardware with a retrigerable one-shot.  This assumes
> > that
> > the characters come out back-to-back, no extra time between them due to
> > software being busy doing something else.  Set the one-shot for a bit
> > longer
> > than a character time and trigger it from the serial data stream.  That
> > will
> > give you an output pulse a bit longer than the NMEA burst.  You can feed
> > that
> > to the TICC.
> >
> > If your geek hat is on, you will have to subtract off the delay through
> > the
> > one-shot.
> >
> > (I'm thinking of one-shots because I was working with a FatPPS recently.
> > 74LS123  Thanks John.)
> >
> > If you prefer software, you can do it with your favorite tiny PIC or AVR
> > size
> > chip.  That will probably add several cycles of jitter.  I'd have to look
> > at
> > the data sheets carefully to work out the details.
> >
> >
> >
> > --
> > These are my opinions.  I hate spam.
> >
> >
> >
> >
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com
> > To unsubscribe, go to
> > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
> >
>
>
> --
> - Forrest
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>