 |
 |
| View previous topic :: View next topic |
| Author |
Message |
ajt
Joined: 07 Sep 2003
Posts: 110
|
|
 Posted: Wed Jun 27, 2012 6:26 am |
 |
|
| FvM wrote: | | Quote: | | I want to use the much simpler DAYTIME protocol implemented on the NIST servers. |
I doubt that it's simpler at all. DAYTIME (RFC 867) is first of all legacy and the lack of a defined syntax is reason enough to avoid it. Everyone is using SNTP (RFC 1305) these days. The basic implementation doesn't involve more than UDP port open and the states UDP_SEND, UDP_RECEIVE and wait for intervall expiration. By reading binary numbers directly, you save a lot of sscanf() string decoding effort. |
The only example I have located for an SNTP client is in the Microchip Application Library and it is quite involved (not to mention would require conversion to CCS). Can you point me to some sample code (or pseudo-code) to do it in a simple way as you have described?
_________________
Al Testani |
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Wed Jun 27, 2012 8:04 am |
|
|
The MAL SNTP code looks much more friendly if you strip off all commented or dead code (SM_SHORT_WAIT state is e.g. unused). Then evaluate some MAL specific macros. I didn't try, but there won't be much CCS porting effort left.
Alternatively, you can write the code from scratch based on RFC 1305. Basically DAYTIME and SNTP are both sending and receiving one UDP packet each. |
|
|
ajt
Joined: 07 Sep 2003
Posts: 110
|
|
| Posted: Wed Jun 27, 2012 1:02 pm |
|
|
I actually had started doing the commenting and conversion to CCS but went off and tried something else. I have 4 different programs using various techniques to get a timestamp.
My problem here is that I am trying to learn all the CCS (Microchip) stack stuff which is a lot to digest in the first place. In addition, I may have something working and not even know it because the time servers quickly block requests so debug of code is a real pain.
I have been thinking that I am probably making this a lot harder than necessary. I don't need accurate time, any old time would be fine. I am thinking of writing a simple PHP script on one of the websites I will be sending data to that issues me its server time when I request it. That way I can simply call for a timestamp whenever I need it and not have to worry about getting blocked and/or having to keep my own clock in the MCU.
_________________
Al Testani |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Jun 27, 2012 1:08 pm |
|
|
Download a few messages from a NIST server as examples. Then create
your own "test server" on the bench in your lab using a PIC or PC, which
will send out messages as if it's the real server. Then test and debug
your program without any constraints due to NIST cutting you off. |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Wed Jun 27, 2012 11:18 pm |
|
|
| ajt wrote: | I actually had started doing the commenting and conversion to CCS but went off and tried something else. I have 4 different programs using various techniques to get a timestamp.
My problem here is that I am trying to learn all the CCS (Microchip) stack stuff which is a lot to digest in the first place. In addition, I may have something working and not even know it because the time servers quickly block requests so debug of code is a real pain.
I have been thinking that I am probably making this a lot harder than necessary. I don't need accurate time, any old time would be fine. I am thinking of writing a simple PHP script on one of the websites I will be sending data to that issues me its server time when I request it. That way I can simply call for a timestamp whenever I need it and not have to worry about getting blocked and/or having to keep my own clock in the MCU. |
Or, you can easily install Linux on any poo-PC sitting around and build your own Stratum 1 (or maybe 2) server.
It's pretty easy to make your own official NTP server.
I use CentOS in my network (which is a free RedHat Enterprise derivative).
If you're going to write network enabled PIC stuff, you should definitely have industry standard stuff running on your network.
(and no, Microsoft doesn't count. They routinely muck up interpretations of RFC in order to "embrace and extend" standards -- or in other words, break them. Now, if you want to be MS compatible, that's fine -- but it might make you NOT standards compatible. Just so you know.)
Cheers,
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
ajt
Joined: 07 Sep 2003
Posts: 110
|
| UTC Timerstamp from Interent (was: NIST Daytime Protocol) |
| Posted: Mon Jul 09, 2012 7:46 pm |
|
|
| ajt wrote: | I'm looking for some example code for reading the Daytime string from one of the NIST servers. I will be using the CCS (Microchip) TCP/IP stack. I understand the string format is variable by server and will figure that out later. Right now, I just need to send a command and get the string back from a specific server.
Any leads would be appreciated. Thanks |
After encountering the difficulty in debugging PIC code for either accessing the NIST DAYTIME or SNTP protocols because these servers block you if you make too may requests, I changed the approach and wrote a very simple PHP script on one of my websites to return the server's UTC time. The PHP code looks like this:
| Code: | <?php
echo date('Y-m-d+H:i:s');
?> |
If you want to see how this works, type this into your browser:
http://weather.testani.net/timestamp.php
The format of the returned string is exactly what I need to include in a GET string to Weather Underground for the remote weather station I am working on.
I am now turning my attention back to the TCPIP stack code. I have to admit I still don't "get it" with using the CCS (Microchip) stack and the many examples I have reviewed. IOW, the light bulb has not lit up yet!
What I need to do is:
1) use DHCP to get a LAN IP address from an Internet connected router (this code is working)
2) Issue an ARP Request (code working in ex13.c)
3) Issue the equivalent of the above URL to get the UTC timestamp (I have the absolute IP address so don't need to use DNS)
4) Issue two GET requests and receive strings "success" or nothing (using a timeout to declare failure).
For #3 and one of the requests in #4 I am accessing a sub-domain (weather.testani.net) but that sub-domain resolves to the same domain as the master domain (testani.net). I am planning to open a socket to the testani.net IP address and use the TCP string:
| Code: | | \weather\timestamp.php |
Does that sound right?
I know the IP address for the Weather Underground domain I need to send the weather data to and the format is:
| Code: | http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?ID=KCASANFR5&PASSWORD=XXXXXX&
dateutc=2000-01-01+10%3A32%3A35&winddir=230&windspeedmph=12&windgustmph=12&tempf=70&rainin=0&baromin=29.1&
dewptf=68.2&humidity=90&weather=&clouds=&softwaretype=vws%20versionxx&action=updateraw |
...so I plan to open a socket to the IP address on port 80 for
http://weatherstation.wunderground.com and send the TCP array of the rest of the above string. If this transmission succeeds WU will return a string "success".
I have all of this working on a PC and am now trying to eliminate the PC and do it all in a PIC. The PC code uses HTTP Get requests.
For all all the HTTP requests, do I simply base my code on the TCP Client example CCS provides and just do a TCPPutArray or do I need to use another method to implement an HTTP GET request?
Thanks for any help in getting me further up this learning curve!
_________________
Al Testani |
|
|
quarencia
Joined: 02 Sep 2012
Posts: 1
Location: Connecticut, USA
|
|
| Posted: Sun Sep 02, 2012 5:54 am |
|
|
Some thoughts on the comment that Daytime isn't any simpler than SNTP.
While I agree with the statement in terms of processing the response from the servers, I think the choice is more nuanced. Actually, I've never understood the (apparent) preference for using SNTP instead of Daytime protocol in microprocessor applications.
The Daytime protocol responds when a client simply connects to the server. It does not require building and sending a request like SNTP does. This tends to make implementation simpler and code smaller.
Also, I think maybe people forget that Daytime servers respond to UDP and TCP requests (at least NIST servers do). Most of my projects require TCP and few require UDP. For me, the only time I use UDP if for SNTP implementations. Using the Daytime protocol with TCP lets me ditch the overhead of both TCP and UDP in my code. While processing the SNTP packet may be more efficient, I find that using Daytime with TCP and not carrying the UDP overhead reduces overall code size. May cost me some processor cycles, but for me, that's better than using my limited code space.
Additionally, the NIST Daytime response includes a DST flag. So if you're interested in local time corrected for DST, you can do this directly from the Daytime protocol response. You don't have to track dates or worry about changing your code if the govt changes the DST implementation dates in the future.
I know arguments can be made for accuracy between the two methods, but for my applications (and I believe most peoples) , microseconds aren't critical. When I really thingk about it, I can't make much of an argument for needing time more accurate than within a minute.
On the whole, I prefer to use the Daytime protocol and actually think it is simpler.
If I'm smoking crack here, I'm open to corrections...but you can't have any of my crack! |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
