[time-nuts] Serial or other simple protocols for exchanging time

[Ralph Aichinger]

[sorry for the messed up formatting in my previous email, I normally use my
linux
"mutt" mailer, but as I had subscription problems I am sending this over
the yet unfamiliar
to me Google web interface]

Am Mi., 7. Aug. 2019 um 20:02 Uhr schrieb Tom Van Baak <tvb at leapsecond.com>:

>
> Mimicking a NMEA ZDA sentence is fine. It's both simple and familiar. It
> even includes an optional checksum.


Yes, this makes it attractive to me, I had quite a bit of problems with
serial lines on microcontrollers, the more safeguards, the better.


> This would be a fun Arduino project. And it would allow you to drive all
> those NASA-era IRIG displays that you've bought on eBay ;-) On the PC
> side you would probably use a sound card to receive the signal. Read the
> NTP docs. Also google Arduino IRIG for a list of existing projects.
>

Thanks!

This would be fine too. There's some old PC code to generate SMPTE in my
> www.leapsecond.com/tools/ directory.
>

Very helpful, I think IRIG stuff is much much rarer in Europe than SMPTE,
there is quite a bit of used video stuff on ebay, with cool LED displays,
and the possibility to encode timecodes in video signals, which also
gives opportunities for playful time display. The only downside is
what to do with the "frame" numbers below seconds.

If it were me I would just use a 9600 baud ascii string in ISO 8601
> format. For example, right now it would output "2019-08-07 16:29:56\n".
> Very readable, for both human and computer.
>

Ah, yes. I thought about this too. But I am not sure if NMEA is not easier
to parse for computers.


> Note that in any of these solutions you have to decide if the timestamp
> refers to the previous or the next 1PPS. It's not always a simple decision.
>

Yes, indeed, that is basically the hardest problem of the NMEA+1PPS
combo to me. I am hoping to overcome it by doing three things: Increasing
update rates to 5 or 10Hz, counting with a timer which side of the
pulse is closer (less than +/-500ms to the ZDA sentence) and human
inspection (fortunately 1 second off is easy to detect by just looking
at a display, the same problem with milliseconds would be much much
harder to deal with).

I am not sure if increasing update rates is a good idea though,
I probably will have to increase baud rate on the connection from
4800 or 9600 to something faster, even if I just output one or two
sentences (ZDA and probably some "fix is OK, enough sats for a solution"
type sentence). That might open another can of worms with faster
output speed? Can GPS modules deal with it in the long run? Are
the timing chipsets (LEA6T or whatever) able to do this at all? The
cheap Adafruit MTK one does it. It is probably more of a drone use
thing.


> Some exceptions are hp 5061 (Cs) and 5065 (Rb) with option 01. That adds
> a 1PPS output and a 24h clock display to the front panel. But it's up to
> the user to manually set it (knobs or push-buttons) and there's no
> computer interface to output the time; it's visual only. The 1PPS
> alignment is done with a BNC input.
>

Ah, good to know, thanks. That is basically how I want my device to operate:
Having a "good" 1PPS pulse and a display+serial output as a "convenience
feature" without any tight coupling to the 1PPS.

/ralph -- thanks also to the other people who have responded! I don't want
to
             generate too much noise on the list to respond to each of you.