next topic »

[on:]

Hi,

I'm intending to use the realtime clock on the WiFly bee and all's well, but the value of RTC, which I parse from this output here into a long,

Code:

<2.32> show t t
Time=21:16:53
UpTime=38 s
RTC=1337080616
Restarts=1
Wake=1
RAW=27d91d9427eb
<2.32>

...and then use the time library function setTime(RTCvalue).  But this sets the time to be precisely 2 hours ahead of the real world, despite the time output in human readable form (as per above) being accurate.  I can fix this with a

Code:

adjustTime(-7200);

but would be far happier doing so if I understood why.  It does seem like a kludge, especially when to get the Time= value accurate, I've set the WiFly bee up with

Code:

set time zone 14

This was found with trial and error, since I'm in the UTC+10 timezone.  I don't understand how the zone number works, since from the WiFly manual (p48) it states :

The default sNTP server is at
ADDR=129.6.15.28:123
ZONE=7 (GMT -7)

which you'd presume should be ZONE=-7.  I've put a ticket into Roving Networks to see if they can point me to an explanation.  Certainly Zone -10 makes the Time= value well wrong (presently at 21:49, the WiFly reports the time as 45:49 if I set the zone to -10, and 01:49 if I set it to 10, but the correct time with the zone set to 14.

So in summary : when the time is displayed correctly by the WiFly (Zone = 14), the RTC value is out by 2 hours for UTC+10.  Can anyone give me an idea why that might be?  And does it matter, or should I just put the adjustTime() line in the sketch and move on quietly?

Thanks
Geoff

[Reply #1 on:]

Have you seen this thread?

http://forum.sparkfun.com/viewtopic.php?f=13&t=30785

Seems like the RTC was broken in versions less than 2.30.

[Reply #2 on:]

Just use the default time zone and fudge it with the number of hours you need to make it correct?

[Reply #3 on:]

Have you seen this thread?http://forum.sparkfun.com/viewtopic.php?f=13&t=30785

Seems like the RTC was broken in versions less than 2.30.

Yes I'd heard that.  This is v2.32 so hoping they've not reintroduced something

Just use the default time zone and fudge it with the number of hours you need to make it correct?

Yes that's my thought - but want to be sure I'm not missing something obvious...

[Reply #4 on:]

I've written some code to set the clock and grab the time.  Seems very useful when there is no GPS!
I have another Sketch to make the Uno clock accurate to 1ppm, assuming their is little temperature change.

[Reply #5 on:]

Hi everyone

Just a short note to close this out.  I have had a response from Roving about the time zone setting, and also the 2 hour thing is explained by a rookie mistake.

From Roving Networks, regarding the setting of the Zone value:

if time_zone > 0
time zone number = 24 - (time_zone)

if time_zone < 0
time zone number = abs(time_zone)

This is good, since the 14 value for GMT+10 I found by trial and error is right

And as for the time being out by 2 hours, well of course it turns out this is a factor of 2 conspiring facts:

• The raw RTC value is not adjusted by the Zone, unlike the time that's displayed
• The clock was being displayed in 12 hr time...

So actually the clock was out by precisely 10 hours, or perhaps more accurately, my time zone!

Hope this helps the next person who falls down this hole 

Cheers ! Geoff