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) < [email protected]> 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 <[email protected]> > 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 -- [email protected] > > 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 -- [email protected] > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
