Hi,
have you tried to check also the return value of Udp.available()? If it were negative your "if" block would be executed anyway.
if ( Udp.available() > 0 )
{
}
PaulS:
In all the cases you posted where the time is set incorrectly, the last 8 bytes are all 0. It isn't rocket surgery to figure out to stop setting the time to an invalid value. Simply ignore the packet if the last 8 bytes are all 0.
Sounds interesting, Paul, but I need to fix the bug - ignoring packets if the last 8 bytes are 0 will mean a given sketch is unable to sync the time more than once.
I've got some code to try from the github lads, so I'll give that a go and report back.
ea123:
Hi,
have you tried to check also the return value of Udp.available()? If it were negative your "if" block would be executed anyway.
Actually, I have to beg to differ, this seems not to be the case. If UDP is unavailable, the code does not run.
Sounds interesting, Paul, but I need to fix the bug - ignoring packets if the last 8 bytes are 0 will mean a given sketch is unable to sync the time more than once.
I don't understand this. If the packet is bad, what else can you do but ignore it. Not using the bad packet means that you don't change the need-to-sync flag, so you try again.
PaulS:
I don't understand this. If the packet is bad, what else can you do but ignore it. Not using the bad packet means that you don't change the need-to-sync flag, so you try again.
Paul, due to the bug I've bored you all to tears with by now, please be reminded that all packets after the first are bad.
RTC before: 2036-02-08 02:40:08
RTC after : 2012-02-23 18:35:09
Time update successful
Time to set the clock at: 2012-02-23 18:36:10
RTC before: 2012-02-23 18:36:10
RTC after : 2012-02-23 18:36:11
Time update successful
WOOHOOOOOO!
What did you change to make it work? 
I'm sorry! I absolutely intended to say more... What can I say? Overcome with relief/excitement.
First, I updated to the newer code from Github, linked to above in "fix", then I changed the code as follows, based on advice on the Google Code UDP bug page users:-
NEW
if ( Udp.parsePacket() )
{
Udp.read(pb, NTP_PACKET_SIZE);
unsigned long t1, t2, t3, t4;
OLD
if ( Udp.available() )
{
Udp.read(pb, NTP_PACKET_SIZE);
unsigned long t1, t2, t3, t4;
Thanks. I'm in learning mode (lurking). I'm glad you have it working!
Is "Udp.parsePacket()" Arduino 1.0 specific ?
robtillaart:
Is "Udp.parsePacket()" Arduino 1.0 specific ?
I don't know, but I did notice this:-
parsePacket() must be called before reading the buffer with UDP.read().
Is "Udp.parsePacket()" Arduino 1.0 specific ?
Found it, it is 1.0 specific, it returns the size of the received packet so you can allocate dynamically a buffer the right size ...
The sources are in the library section of the distribution BTW.
Hi all.
I have the same problem with NTP.
669 issue fixed, Udp.parsePacket() used.
Here is my serial output:
NTP2RTC 0.5
network ...
RTC before:
24.1.6.ED.
0.0.0.0.
0.0.0.F.
50.50.53.0.
D2.F6.6C.7E.
34.98.9F.F6.
0.0.0.0.
0.0.0.0.
D2.F6.6C.7E.
D5.44.B9.5F.
D2.F6.6C.7E.
D5.46.8A.10.
T1 .. T4 && fractional parts
2042-02-26 20:56:30 0.2054
2066-02-06 06:28:16 0.0000
2042-02-26 20:56:30 0.8331
2042-02-26 20:56:30 0.8331
RTC after : 2042-02-26 17:56:32
done ...
RTC before:
24.1.6.ED.
0.0.0.0.
0.0.0.16.
50.50.53.0.
D2.F6.6C.7E.
34.98.9F.F6.
0.0.0.0.
0.0.0.0.
D2.F6.6C.86.
22.6F.8C.6B.
D2.F6.6C.86.
22.71.61.A.
T1 .. T4 && fractional parts
2042-02-26 20:56:30 0.2054
2066-02-06 06:28:16 0.0000
2042-02-26 20:56:38 0.1345
2042-02-26 20:56:38 0.1345
RTC after : 2042-02-26 17:56:39
done ...
RTC before:
24.1.6.ED.
0.0.0.0.
0.0.0.F.
50.50.53.0.
D2.F6.6C.8D.
34.F5.F1.47.
0.0.0.0.
0.0.0.0.
D2.F6.6C.8D.
66.23.10.25.
D2.F6.6C.8D.
66.24.D9.84.
T1 .. T4 && fractional parts
2042-02-26 20:56:45 0.2069
2066-02-06 06:28:16 0.0000
2042-02-26 20:56:45 0.3990
2042-02-26 20:56:45 0.3990
RTC after : 2042-02-26 17:56:46
sv_h:
Hi all.
I have the same problem with NTP.
669 issue fixed, Udp.parsePacket() used.
I wonder if it is necessary to apply fix 669. I think my code started working when I changed the code, without needing to change the ethernet library files.
I would be interested in whether merely using Udp.parsePacket() is enough with the standard 1.0 IDE download.
Udp.available() is affected by the "605 Bug" also.
http://code.google.com/p/arduino/issues/detail?id=605
This bug affects udp and dhcp.
http://arduino.cc/forum/index.php/topic,93623.0.html
It's gives the same result regardless fixed/unfixed 669 bug, fixed/unfixed 605 bug, dhcp enabled/disabled.
NTP always returns -1 day to the current date and 2042 year.
Though time is syncronized perfectly
P.S. I'm using Arduino IDE 1.0 for Windows.
Who have any ideas regarding output listed below?
sv_h:
[...]time is syncronized perfectly
The incorrect time is synced perfectly, right? Just so I understand what you mean.
You'll need to post your code, please. Who'd have thought I'd ever be saying that?? 8)
The incorrect time is synced perfectly, right?
I mean that there is no errors in time. It's error in date sync
NTP always returns -1 day to the current date and 2042 year.
Code unmodified from http://arduino.cc/playground/Main/DS1307OfTheLogshieldByMeansOfNTP
sv_h:
Code unmodified from Arduino Playground - DS1307OfTheLogshieldByMeansOfNTP
There's your problem! You need to read through this thread!
Scroll back a bit through this read until you reach my post February 23, 2012, 08:15:13 PM.
This fixes the issue. Having done some testing yesterday, I have confirmed my earlier hypothesis:
Dane:
I wonder if it is necessary to apply fix 669. I think my code started working when I changed the code, without needing to change the ethernet library files.
It isn't necessary to apply fix 669.
Hi sv_h,
(I am the author of Arduino Playground - DS1307OfTheLogshieldByMeansOfNTP )
Arduino is open source and work in progress, when I wrote this NTP code I used IDE 18 if I recall correctly (4or5 releases ago). For me the code worked well enough so I shared it on the playground. Since then some changes to the code/story have been applied by me and others. The playground is exactly what the name says: a playground. Code to play with, no guarantee that the code is perfect and will work under all conditions for all arduino's but a starting point how things can be done.
The discussion in this thread is about how to get the code properly working under IDE 1.0 and not until we are sure how it should be done the playground code is not changed by me. I dont like to replace buggy code with other buggy code and pretend its better (however in practice it still happens to me too often 
)
That said I am amazed that you got 2042 as year as the NTP clock stops in 2036 afaik. I don't know what happens exactly but I think it is a buffer overrun (looking at the dump of the UDP packet). I proposed somewhere in this thread to increase the default buffer size as I think the buffer is to small for the answer of the NTP server. Therefor a part of it is stillin the socket and as the next packet is read it is "dirty"at the beginning. Compare the pattern of the first packet with the second and you will see there is a shift in the data. It is on my todolist to fix this, but it is not at the top ....
To be continued...