DEMO - RFC 2030 (SNTP) Simple Network Time Protocol with UDP packets over port 123

[Beau Schwabe (Parallax)]

Has anyone attempted using ICMP protocol with the Spinneret? ... Specifically to receive a Time stamp from the Internet? ... To eventually auto set/sync the built in RTC on the Spinneret.

Just curious.

Edit Update: 02/08/2011
See this link further down in this thread.

[Mike G]

I did not use ICMP but I did create a simple service that returns the date and time, UTC [m d y <day of week> h m s].
http://www.agaverobotics.com/spinneret/datetime.aspx

I did the same kind of thing to find my IP.
http://www.agaverobotics.com/spinneret/myip.aspx

[Timothy D. Swieter]

I considered, and started at one point, a NTP device. http://en.wikipedia.org/wiki/Network_Time_Protocol But my results didn't get too far other than wrapping my head around how to write application layer software with the Ethernet Driver and how to have multiple Application layer running and all accessing the single WIZnet driver. This problem is the rabbit hole I am in right now.

[DynamoBen]

NTP/SNTP is a better and more typical way to set time on a network device. I have some mostly finished SNTP code if you want to finish it up and post it to the repository.

[DynamoBen]

Hmmm 8 views but no responses. SNTP is the way to go for setting and updating the RTC, this is a worthwhile project I just don't have the time at the moment to finish it. If you need a boost check this project out

http://tuxgraphics.org/electronics/2...tp-clock.shtml
or
http://3meterclock.com

[Beau Schwabe (Parallax)]

DynamoBen,

I need to find time to get my head around it as well.

[DynamoBen]

DynamoBen,

I need to find time to get my head around it as well.

Excellent, this will be an perfect match with the spinneret.

[ags]

I don't have an RTC on my board, but wanted to report my server's (that's a stretch of the term) uptime, so I hacked together a way to get current time using the (deprecated) TIME protocol. It is not as accurate or complete as NTP or even SNTP, but after reviewing the RFCs for each, for my purposes (I'm not launching interstellar vehicles) the TIME protocol seemed just fine. My implementation simply gets the current time at boot up, stores that, and then for each page view gets the current time and compares the two to provide uptime. Try to break it (I don't say that with any hubris: I'm sure it will break, I don't want it to break, but at least I'll know where to look for the problem that breaks it...).

http://xxxxxxxxx

Thanks (I think)

[Beau Schwabe (Parallax)]

ags,

"...I don't have an RTC on my board,..." - If your using a Spinneret, then there is an RTC built-in to the board.

BTW) Without providing code, nobody can benefit from your solution to keep your server up and running.

Reference: (See page 4 for RTC)
Spinneret PDF

[ags]

@Beau: Actually, you've caught me - I guess I'm a poser here. I don't actually have a Spinneret. I have a WizNet WIZ812MJ module hacked onto my Propeller Proto USB. I don't have an RTC. I haven't looked at the RTC, but I'm guessing that using the TIME (or NTP/SNTP) protocol would still be a fairly elegant way of setting the initial time for the RTC.

I'm happy to share what I did, it's very simple. Just send a dummy (contents don't matter, it's just discarded anyway) UDP packet to a TIME server (list is here: http://tf.nist.gov/tf-cgi/servers.cgi) on port 37. Listen for a UDP packet on port 37. You'll receive a 12 byte packet (4 byte payload) containing a big-endian value representing the number of seconds since midnight Jan 1, 1900.

[NOTE: I suspect there is a bug in the WizNet driver, but I haven't had a chance to confirm & repair. Don't try to send a packet with an empty payload, be sure to have at least one byte payload]

At the moment, I'm prototyping a dozen things all at once, and my code is a disaster: a rudimentary HTTP server, DHCP client, TIME client, UDP streaming client, bootloader over Ethernet, and a few more. If actual code for this TIME client will be helpful (beyond the simple description above) I'll take the time to clean up what I have, modularize it and post it. If it's not needed (now) then I'll wait until I go through and scrub my existing code and then post it.

@Timothy: I think I see you in the other end of the rabbit hole I'm stuck in. I'm trying to figure out the same thing myself: how to have multiple applications/protocols using the WizNet module when only one cog can be running the driver. I'm reluctant to build a huge loop that looks for every possibility and dispatches accordingly. I'm concerned that would make the response of anything that actually is active unsatisfactory. I'm new to the Propeller, so still think in terms of interrupts. That might be my mistake, but I'm thinking it also might be that in this case, where a resource (the WizNet) is limited, one can't use the same solution (start another cog) that allows the Propeller to not need interrupts. I'm open to ideas at this point.

[ags]

OK, I read my reply and it's just lame. Yes, the code is a mess and no, I don't have spare time. But who does? So I made some time and cleaned up the code. I'm attaching it here and hope it will be useful as is, or at least as a template for others.

As noted earlier, I'm using the simpler, less accurate TIME protocol. For my needs, it's adequate.

[Beau Schwabe (Parallax)]

ags,

Thanks, attached is a version that will work with the Spinneret. The returned time is in RFC-868 format where the 32 bit binary value represents the number of seconds since Jan 1st, 1900 with an accuracy of 1 second.

What concerns me is that this protocol is being phased out, and there may be others to choose from. For example ... .RFC-1305 ... this protocol uses port 123 (instead of 37) and returns a 64 bit binary value representing the number of seconds since Jan 1st, 1900 with an accuracy of 200 pico seconds.

Another one to look at might be RFC-867 ... this server listens on port 13 and returns the TIME stamp in standard ASCII characters over a tcp/ip or udp/ip connection.

[ags]

The ASCII version is the DAYTIME protocol. I looked at it and decided that I'd just write my own converter from the TIME long value to an ASCII representation. This way with just one query (not that it takes much time) and store I have what I need. Also, while there is some consistency in the format used for the ASCII DAYTIME protocol, it's not specified in the RFC (AFAIK) so not guaranteed. Also, if you want to modify even slightly, now you're back to parsing. It takes more memory to store the string value, and if you want to convert to Zulu or local zone, more parsing. So, I'll write that converter sometime... (wait for it...)

"I just don't have the time right now".

[Beau Schwabe (Parallax)]

This version implements a 'newer' RFC 2030 (SNTP) Simple Network Time Protocol with UDP packets over port 123. Instead of the previous RFC-1305 (NTP) Network Time Protocol over port 37.

Note: The same server (64.147.116.229) is used and can be located among several other time servers here: http://tf.nist.gov/tf-cgi/servers.cgi


The SNTP time is returned as a 64 bit standard time stamp, but for this application the fractional time data is omitted. The date and time is decoded from the 'Transmit Timestamp' and the 'time of flight' data is available to be derived but it is not implemented in this example.

In the next update >>HERE<<I will implement a method that will allow the Spinneret to set/sync it's own RTC (Real Time Clock) over an internet connection.

You can compare the output results to this sight: http://wwp.greenwichmeantime.com/

PST output example:

INFO::GetTime:Socket successfully opened.
Mode:4
Version:4
Leap Indicator:00
Stratum:1
Poll Interval: 0
Precision:227
Root Delay:0
Root Dispersion:0
Reference Identifier:ACTS
Reference Timestamp:D0FB5C7D99271CE4
Originate Timestamp:0000000000000000
Receive Timestamp:D0FB5CB46FB48F24
Transmit Timestamp:D0FB5CB46FB595A3

(GMT + 0:00) 02/08/2011 06:09:56
INFO::GetTime:Closing socket.