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

[Hal Murray]

> 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.