When I run the sample all seems to work ok (single step debugging), until waiting for the UDP packet reply for the NTP server. It never arrives. I known the NTP servers is there because my XP laptop is set to be synchronised by the same server.
I’m going to investigate the problem in more detail and have a look to see if the rabbit 3720 is sending the UDP packet request.
But if anyone else has had any experiance with NTP servers any help you can give would be good.
There are a couple of possible reasons your sample time program is not working:
(1) the rabbit end is buggy, and never sending the request; unlikley, presuming the DHCP query get’s a proper reply with sensible network config values; I’ve had my rabbit send and receive UDP requests, though all over a local lan
(2) the sample program uses a “fake” ntp; it’s actually using timep, on socket 37, which is an old 1-second resolution unix time protocol and a 32 bit counter; real NTP uses socket 123 and 64 bit magic numbers; it’s possible the targets you note are not responding to socket 37, whereas they would respond on socket 123
(3) the greater LAN/WAN routers, NAT, firewalls and/or transport system (between the rabbit and the time sources you are using) drop the request somewhere; UDP is “unreliable”, and on busy networks, the routers just simply drop the packets; that’s why NFS pre-tcp version4 had to have it’s own internal error recovery algorithims, for example
(4) if you have a local linux system on the LAN where your rabbit is, try the sample program again, using the linux server as the time source, and that will ensure (2) and (3) are removed as possible points as to why it’s not working [BTW: I’ve turned the sample into a library routine, and it’s working just fine, though using a local linux server as a time reference]
Thanks for the reply. I’ve spent more time on the problem and using another of the sample apps I got access to a time server. The sample used a TCP client to connect to the time server using a DAYTIME port.
I think I was going wrong with the port number that I was using. I’ll go back and try the UDP program using the correct port number (123)
Hope I’m not teaching you what you already know:
Beware there is a fundamental difference between probing port 37 (timep) and port 123 (ntp).
On port 37, all you need to is send it something, anything and (security issues aside), the daemon (usually inetd on a u**x server) will ignore what it’s been sent, and then will return a 32-bit unsigned integer; the integer being the number of seconds that have elapsed since the beginning of the unix-universe, being 1st Jan 1970 UTC. (the “epoch”).
On port 123, you need to send it a semi-intelligent formatted number, and you will get back an internally formatted number, including the current time, plus some other stuff. Have a look at www.ntp.org for more details than you probably want to know.
The sample rabbit prog does not contain any smarts on how to build a “probe” NTP packet, then rip apart the NTP reply, let alone what to do with it past that. Troll the web for sample “sntp” implimentations to get an idea of what’s involved. (The client only side of NTP).
I submit, it’s also dubious value, in as much as the RTC & SECTIMER in the rabbit has a 1 second resolution, so there is little value in quizzing a clock that can be accurate to within nano-seconds.
Hi Jon,
try SNTP.LIB written by Hans Van Ingelgom (was posted on Zworld’s old BB), it’s a simple an robust library that can be used to synchronize the on-board RTC. See the description below to decide whether this library is suitable for your application.
Description:
/* SNTP.LIB V0.8
*
This library provides a very very simple SNTP (Simple Network
Time Protocol, RFC1769) interface.
sntp_gettime() returns the time, measured in seconds since
Jan 01, 1980, 00:00 GMT. To do so, it sends an empty NTP request
to the server and retreives the time from the reply. THIS MEANS
THERE IS NO ROUDTRIP DELAY CALCULATION! (read the RFC if you wish
to implement this feature).
This software is freeware. You can use it in your own programs,
as long as this copyright notice is not changed. No warranties
implied. If you make changes to the code, please send them to