Re: [time-nuts] Serial or other simple protocols for exchanging time
Hi NTP brings along a bunch of “baggage” that gets you out of the category of “couple of lines of code” protocol. What I’m suggesting is very much the same thing as a GPS sentence. Sent once a second with a very minimal payload. You just are doing it via UDP instead of RS-232 serial. Bob == Time protocol - port 37? Did someone suggest this? Cheers, David -- SatSignal Software - Quality software for you Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Serial or other simple protocols for exchanging time
Hi NTP brings along a bunch of “baggage” that gets you out of the category of “couple of lines of code” protocol. What I’m suggesting is very much the same thing as a GPS sentence. Sent once a second with a very minimal payload. You just are doing it via UDP instead of RS-232 serial. Bob > On Aug 15, 2019, at 11:35 AM, Tim Shoppa wrote: > > Bob, ntpd for ages has supported broadcast/multicast UDP. > https://www.eecis.udel.edu/~mills/ntp/html/assoc.html#broad > > If you care about security it's like a bag of angry cats. And the > one-way-ness removes the ability to measure round-trip delay. So it's > pretty rare to see it being used well. > > Tim N3QE > > On Thu, Aug 15, 2019 at 11:08 AM Bob kb8tq wrote: > >> Hi >> >> Which all sort of begs the question: >> >> Why not a simple “broadcast UDP” once a second time packet approach for a >> home LAN? >> >> Unless you get really crazy, it’s not going to be a very big packet. >> Seconds since some >> arbitrary point in time. Time zone offset. Maybe a leap second count. >> Server ID maybe. >> Less than 100 bytes not including the overhead. >> >> Bob >> >>> On Aug 15, 2019, at 5:36 AM, Hal Murray wrote: >>> >>> >>> ausserirdischesindges...@gmail.com said: I am a newbie and am wondering what options there are for exchanging >> time on a more basic level than NTP or PTP (that is for situations when a full network stack is too complex). >>> >>> You haven't described your problem fully yet. >>> >>> Are you interested in client side or server side? (or both) >>> >>> What sort of environment are you working in? What sort of hardware do >> you >>> have available? >>> >>> NMEA over a serial port is probably what you want, but... >>> >>> >>> Raspberry Pi and similar are not very expensive. They come with >> networking >>> software. The Pi isn't very nice for time-nut work over the net because >> the >>> Ethernet is on USB which adds jitter and/or hanging bridges. It does >> have >>> GPIO. >>> >>> >>> There is a lot of things you can do without a "full network stack". >>> >>> What level of hacking is reasonable depends on your environment. For a >> setup >>> at home, you are unlikely to annoy anybody else. >>> >>> The Alto firmware could boot over the (3 MB) Ethernet. The boot servers >> would >>> periodically send a boot-loader packet to a reserved hardware address. >> The >>> firmware only had to setup the hardware to receive a packet, wait for >> one, >>> sanity check things, and jump to it. >>> >>> If you use UDP rather than TCP, the "stack" level packet format is much >>> simpler. Retransmission becomes trivial if you only have one un-ACKed >> packet >>> to consider. Performance on a LAN is OK most of the time. >>> >>> For something like a NTP server, you can avoid routing and ARP by >> sending the >>> reply back where it came from. >>> >>> For the client side, the normal problem is finding the server. If you >> only >>> have one server, you can wire in the address. >>> >>> >>> >>> >>> -- >>> These are my opinions. I hate spam. >>> >>> >>> >>> >>> ___ >>> time-nuts mailing list -- time-nuts@lists.febo.com >>> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>> and follow the instructions there. >> >> >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. >> > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Serial or other simple protocols for exchanging time
Bob, ntpd for ages has supported broadcast/multicast UDP. https://www.eecis.udel.edu/~mills/ntp/html/assoc.html#broad If you care about security it's like a bag of angry cats. And the one-way-ness removes the ability to measure round-trip delay. So it's pretty rare to see it being used well. Tim N3QE On Thu, Aug 15, 2019 at 11:08 AM Bob kb8tq wrote: > Hi > > Which all sort of begs the question: > > Why not a simple “broadcast UDP” once a second time packet approach for a > home LAN? > > Unless you get really crazy, it’s not going to be a very big packet. > Seconds since some > arbitrary point in time. Time zone offset. Maybe a leap second count. > Server ID maybe. > Less than 100 bytes not including the overhead. > > Bob > > > On Aug 15, 2019, at 5:36 AM, Hal Murray wrote: > > > > > > ausserirdischesindges...@gmail.com said: > >> I am a newbie and am wondering what options there are for exchanging > time > >> on a more basic level than NTP or PTP (that is for situations when a > >> full network stack is too complex). > > > > You haven't described your problem fully yet. > > > > Are you interested in client side or server side? (or both) > > > > What sort of environment are you working in? What sort of hardware do > you > > have available? > > > > NMEA over a serial port is probably what you want, but... > > > > > > Raspberry Pi and similar are not very expensive. They come with > networking > > software. The Pi isn't very nice for time-nut work over the net because > the > > Ethernet is on USB which adds jitter and/or hanging bridges. It does > have > > GPIO. > > > > > > There is a lot of things you can do without a "full network stack". > > > > What level of hacking is reasonable depends on your environment. For a > setup > > at home, you are unlikely to annoy anybody else. > > > > The Alto firmware could boot over the (3 MB) Ethernet. The boot servers > would > > periodically send a boot-loader packet to a reserved hardware address. > The > > firmware only had to setup the hardware to receive a packet, wait for > one, > > sanity check things, and jump to it. > > > > If you use UDP rather than TCP, the "stack" level packet format is much > > simpler. Retransmission becomes trivial if you only have one un-ACKed > packet > > to consider. Performance on a LAN is OK most of the time. > > > > For something like a NTP server, you can avoid routing and ARP by > sending the > > reply back where it came from. > > > > For the client side, the normal problem is finding the server. If you > only > > have one server, you can wire in the address. > > > > > > > > > > -- > > These are my opinions. I hate spam. > > > > > > > > > > ___ > > time-nuts mailing list -- time-nuts@lists.febo.com > > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > > and follow the instructions there. > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Serial or other simple protocols for exchanging time
Hi Which all sort of begs the question: Why not a simple “broadcast UDP” once a second time packet approach for a home LAN? Unless you get really crazy, it’s not going to be a very big packet. Seconds since some arbitrary point in time. Time zone offset. Maybe a leap second count. Server ID maybe. Less than 100 bytes not including the overhead. Bob > On Aug 15, 2019, at 5:36 AM, Hal Murray wrote: > > > ausserirdischesindges...@gmail.com said: >> I am a newbie and am wondering what options there are for exchanging time >> on a more basic level than NTP or PTP (that is for situations when a >> full network stack is too complex). > > You haven't described your problem fully yet. > > Are you interested in client side or server side? (or both) > > What sort of environment are you working in? What sort of hardware do you > have available? > > NMEA over a serial port is probably what you want, but... > > > Raspberry Pi and similar are not very expensive. They come with networking > software. The Pi isn't very nice for time-nut work over the net because the > Ethernet is on USB which adds jitter and/or hanging bridges. It does have > GPIO. > > > There is a lot of things you can do without a "full network stack". > > What level of hacking is reasonable depends on your environment. For a setup > at home, you are unlikely to annoy anybody else. > > The Alto firmware could boot over the (3 MB) Ethernet. The boot servers > would > periodically send a boot-loader packet to a reserved hardware address. The > firmware only had to setup the hardware to receive a packet, wait for one, > sanity check things, and jump to it. > > If you use UDP rather than TCP, the "stack" level packet format is much > simpler. Retransmission becomes trivial if you only have one un-ACKed packet > to consider. Performance on a LAN is OK most of the time. > > For something like a NTP server, you can avoid routing and ARP by sending the > reply back where it came from. > > For the client side, the normal problem is finding the server. If you only > have one server, you can wire in the address. > > > > > -- > These are my opinions. I hate spam. > > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Serial or other simple protocols for exchanging time
ausserirdischesindges...@gmail.com said: > I am a newbie and am wondering what options there are for exchanging time > on a more basic level than NTP or PTP (that is for situations when a > full network stack is too complex). You haven't described your problem fully yet. Are you interested in client side or server side? (or both) What sort of environment are you working in? What sort of hardware do you have available? NMEA over a serial port is probably what you want, but... Raspberry Pi and similar are not very expensive. They come with networking software. The Pi isn't very nice for time-nut work over the net because the Ethernet is on USB which adds jitter and/or hanging bridges. It does have GPIO. There is a lot of things you can do without a "full network stack". What level of hacking is reasonable depends on your environment. For a setup at home, you are unlikely to annoy anybody else. The Alto firmware could boot over the (3 MB) Ethernet. The boot servers would periodically send a boot-loader packet to a reserved hardware address. The firmware only had to setup the hardware to receive a packet, wait for one, sanity check things, and jump to it. If you use UDP rather than TCP, the "stack" level packet format is much simpler. Retransmission becomes trivial if you only have one un-ACKed packet to consider. Performance on a LAN is OK most of the time. For something like a NTP server, you can avoid routing and ARP by sending the reply back where it came from. For the client side, the normal problem is finding the server. If you only have one server, you can wire in the address. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Serial or other simple protocols for exchanging time
[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 : > > 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. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Serial or other simple protocols for exchanging time
Am Do., 8. Aug. 2019 um 05:09 Uhr schrieb Gary Chatters < gcarlis...@garychatters.com>: > I would expect that making your Arduino device look like a GPS receiver > outputting NMEA messages and a PPS signal would be about the simplest > approach you could take. It has the advantage that there is existing > software to deal with the messages, including NTP drivers. > Yes, this is exactly my thinking. I am looking for a simple way to monitor this rubidium device (and the Arduino clock linked to it), and having an NTP server tracking its performance is probably the easiest way to do this (graphing drift, catching systematic errors in the Arduino programming etc.). - How is your Arduino going to get time? > >From a GPS receiver with PPS output, via serial NMEA. I plan to do three things when the Arduino based clock is set (by plugging in a cable and pressing a button or something, so not continuously): 1. the GPS signal will be sanity checked (enough sats, is there a fix) 2. the PPS divider (either on the Arduino itself or one of Tom's PicDivs) of the rubidium will be reset to zero when the next PPS from the GPS arrives. 3. The NMEA time from the GPS is parsed and used to set time and date above seconds level on the Arduino based clock. > - What is the computer going to do with it? > For now mainly monitor it: Is the rubidium off from GPS time, did the dividers/counters count right, etc., both to check hardware and my poor attempts at programming ;) /ralph -- thanks! > > > > Gary > WA9ZZZ > > On 8/7/19 8:13 AM, Ralph Aichinger wrote: > > Hi everybody! > > > > > > I am a newbie and am wondering what options there are for exchanging time > > > > on a more basic level than NTP or PTP (that is for situations when a > > > > full network stack is too complex). > > > > > > For now I have found: > > > > > > NMEA (probably ZDA only) > > > > IRIG timecode (this is rather complex, I would rather have a > > > >full network stack than IRIG?) > > > > SMPTE timecode (this too?) > > > > > > Are there any other obvious candidates I missed? How did e.g. > > > > HP atomic clocks tell their time to connected devices before > > > > there was the NTP protocol? Did they output NMEA or something > > > > else? Did they emit IRIG directly? > > > > > > I want to create an Arduino based clock that tells time to a computer > > > > it is linked too. For exact seconds alignment I want to use a PPS signal, > > > > but I need a means to tell the computer about second numbers, hours etc. > > > > too. > > > > > > Of course I could invent a serial protocol, but I suppose if I invented a > > > > text based serial protocol, it would probably end up looking very > > > > similar in structure to NMEA ZDA sentences. > > > > > > *Is* NMEA the most practical time protocol at the 1 second level > > > > (that is when a PPS pulse takes care of second alignment?) or should > > > > I use something else if I am free to design stuff clean slate? > > > > > > TIA > > > > /ralph > > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Serial or other simple protocols for exchanging time
If I understand correctly, your Arduino based device is generating the time code to send to your computer. In the past I have used GPS NMEA messages and IRIG-B for data acquisition time stamps. I considered SMPTE, but it did not look useful. I would expect that making your Arduino device look like a GPS receiver outputting NMEA messages and a PPS signal would be about the simplest approach you could take. It has the advantage that there is existing software to deal with the messages, including NTP drivers. IRIG-B has the advantages that it has a lower bit rate and only requires one signal line. I looked at NTP source code and there is a driver for IRIG-B (and E) using 1 kHz modulation. Two questions come to mind: - How is your Arduino going to get time? - What is the computer going to do with it? Gary WA9ZZZ On 8/7/19 8:13 AM, Ralph Aichinger wrote: Hi everybody! I am a newbie and am wondering what options there are for exchanging time on a more basic level than NTP or PTP (that is for situations when a full network stack is too complex). For now I have found: NMEA (probably ZDA only) IRIG timecode (this is rather complex, I would rather have a full network stack than IRIG?) SMPTE timecode (this too?) Are there any other obvious candidates I missed? How did e.g. HP atomic clocks tell their time to connected devices before there was the NTP protocol? Did they output NMEA or something else? Did they emit IRIG directly? I want to create an Arduino based clock that tells time to a computer it is linked too. For exact seconds alignment I want to use a PPS signal, but I need a means to tell the computer about second numbers, hours etc. too. Of course I could invent a serial protocol, but I suppose if I invented a text based serial protocol, it would probably end up looking very similar in structure to NMEA ZDA sentences. *Is* NMEA the most practical time protocol at the 1 second level (that is when a PPS pulse takes care of second alignment?) or should I use something else if I am free to design stuff clean slate? TIA /ralph ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Serial or other simple protocols for exchanging time
Hi With anything like this a very real question is “what am I trying to do?”. Generally it involves getting time from device A to device B. The next layer of the onion is “how accurate is device A?” and “how good does device B need to be?”. If the source is only good to 0.1 seconds, there isn’t any way the destination will be any better than that. Once the link is 10X better than the source, making it any better does not significantly improve the destination’s idea of what time it is. You can do pretty well with serial streams that have a definition of which point in the string is the “time mark”. That assumes your gear has a good way to link that point in the string to your local source clock (at the origin) or the flywheel clock (at the destination). This may not be as easy to do as one might hope. Often the packaged solution that already worked out all this mess wins out. Bob > On Aug 7, 2019, at 8:13 AM, Ralph Aichinger > wrote: > > Hi everybody! > > > I am a newbie and am wondering what options there are for exchanging time > > on a more basic level than NTP or PTP (that is for situations when a > > full network stack is too complex). > > > For now I have found: > > > NMEA (probably ZDA only) > > IRIG timecode (this is rather complex, I would rather have a > > full network stack than IRIG?) > > SMPTE timecode (this too?) > > > Are there any other obvious candidates I missed? How did e.g. > > HP atomic clocks tell their time to connected devices before > > there was the NTP protocol? Did they output NMEA or something > > else? Did they emit IRIG directly? > > > I want to create an Arduino based clock that tells time to a computer > > it is linked too. For exact seconds alignment I want to use a PPS signal, > > but I need a means to tell the computer about second numbers, hours etc. > > too. > > > Of course I could invent a serial protocol, but I suppose if I invented a > > text based serial protocol, it would probably end up looking very > > similar in structure to NMEA ZDA sentences. > > > *Is* NMEA the most practical time protocol at the 1 second level > > (that is when a PPS pulse takes care of second alignment?) or should > > I use something else if I am free to design stuff clean slate? > > > TIA > > /ralph > > -- > > - > > > https://aisg.at > > ausserirdische sind > gesund > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Serial or other simple protocols for exchanging time
> NMEA (probably ZDA only) Mimicking a NMEA ZDA sentence is fine. It's both simple and familiar. It even includes an optional checksum. > IRIG timecode 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. > SMPTE timecode (this too?) This would be fine too. There's some old PC code to generate SMPTE in my www.leapsecond.com/tools/ directory. > Are there any other obvious candidates I missed? 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. Another method I've seen used by telecom GPS receivers is to output unix integer time; right now it would output "1565195396\n". That's even simpler (for computer) but not as self evident (for human). 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. > How did e.g. HP atomic clocks tell their time to connected devices They didn't. Almost all "atomic clocks" are just precise frequency standards that output, for example, 10 MHz. As such they don't know what the date and time is. Some other external h/w or s/w deals with all that. 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. Another exception is the 5071A. It too has a 1PPS output and a 24h time display. Serial / SCPI commands or the front panel keypad are used to set the date (MJD) and time and to enable the BNC sync input. /tvb ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Serial or other simple protocols for exchanging time
Ralph your need does appear simple. Many of the timecodes that exist do so because of specific distribution needs over distances. IRIG and SMPTE are good examples. I use smpte in my house because I was able to obtain very nice displays cheaply. I have in the past used IRIG B. Simply silly but if you can do it why not. That said the small NTP servers using arduinos or PIs are amazing and a low cost and technical lift and may be good enough. But for accuracy a typical GPS receiver and the nema sentence is really easy to use. Can be converted to RS232 for reasonable distance and the same for the 1PPS. Typical applications I have seen use one of the rs232 control lines to receive the 1 pps. There can be one catch in this approach. The sentence may have passed the second tick if you are using the typical 4800 baud sentence and other messages are coming out of the GPS receiver. Eliminate un-used sentences and I use 38.4 Kb/s. Seems to avoid the issue. Regards Paul WB8TSL On Wed, Aug 7, 2019 at 12:01 PM Ralph Aichinger < ausserirdischesindges...@gmail.com> wrote: > Hi everybody! > > > I am a newbie and am wondering what options there are for exchanging time > > on a more basic level than NTP or PTP (that is for situations when a > > full network stack is too complex). > > > For now I have found: > > > NMEA (probably ZDA only) > > IRIG timecode (this is rather complex, I would rather have a > > full network stack than IRIG?) > > SMPTE timecode (this too?) > > > Are there any other obvious candidates I missed? How did e.g. > > HP atomic clocks tell their time to connected devices before > > there was the NTP protocol? Did they output NMEA or something > > else? Did they emit IRIG directly? > > > I want to create an Arduino based clock that tells time to a computer > > it is linked too. For exact seconds alignment I want to use a PPS signal, > > but I need a means to tell the computer about second numbers, hours etc. > > too. > > > Of course I could invent a serial protocol, but I suppose if I invented a > > text based serial protocol, it would probably end up looking very > > similar in structure to NMEA ZDA sentences. > > > *Is* NMEA the most practical time protocol at the 1 second level > > (that is when a PPS pulse takes care of second alignment?) or should > > I use something else if I am free to design stuff clean slate? > > > TIA > > /ralph > > -- > > > - > > > https://aisg.at > >ausserirdische sind > gesund > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
