Hello guys, i just want to know which set time zone i have to configure to a GMT +1 (spain time zone)?
what command “show t t” means?
Also want to know why show t t give me value RTC=7827562286446 ms if unix time shold be like 1323604859…
What is the relationship between them? because i would like to know the date to make a correction time… in spain the time is changed on winter and on spring…
There is a way to do that automatically instead of coding in arduino?
Thanks!
Typing in the command
set time zone 23
sets my wifly internal clock to GMT + 1 hour, after synchronizing it to an internet timeserver
It isn’t entirely clear to me what the relationship is between the RTC value in the WiFly and unix time. For example, you can set the internal RTC to zero by typing the command:
set time raw 0
jremington:
Typing in the commandset time zone 23
sets my wifly internal clock to GMT + 1 hour, after synchronizing it to an internet timeserver
It isn’t entirely clear to me what the relationship is between the RTC value in the WiFly and unix time. For example, you can set the internal RTC to zero by typing the command:
set time raw 0
I also set to time zone 23, but my problem is when the time in spain change, my time return by the wifly shield didnt change… so i have to change the time zone entering in “SPI UART on WiFly Shield terminal tool” and when i will have finished the project i will dont want to retake anymore
It your time change when your time is changed? Should be changed by the sNTP server or that’s a work for the client to change? which TIMEADR have you got?
Here is my configuration:
get time
TimeEna=1
TIMEADR=130.206.3.166:123
Zone=23
<2.21> show t t
Time=13:38:32
UpTime=437 s
RTC=7827649608885 ms
Restarts=1
Wake=1
Since NTP time servers deliver UTC, they don’t recognize daylight savings time. This is a good thing, because the rules vary from place to place (DST is not used at all in some countries). The WiFly doesn’t keep track of the date, either, so your client will have to handle both.
jremington:
Since NTP time servers deliver UTC, they don’t recognize daylight savings time. This is a good thing, because the rules vary from place to place (DST is not used at all in some countries). The WiFly doesn’t keep track of the date, either, so your client will have to handle both.
Yeah, I understand, i have to handle it, but how can i do? Because i havent a way to get the date because i cant understand what that RTC means…
I suggest to contact technical support at Roving Networks @ http://www.rovingnetworks.com
But, I just checked my wifly, with time zone set to 0 and NTP server 129.6.15.28. It returned RTC=1323720841
According to http://www.unixtimestamp.com/index.php this corresponds to 12/12/2011 at 2:14 EST, which is off
by one hour at most.
Oh For you is working! 
Why not me, i change my ip sNTP server to the same as you and still working, I wonder if i have another firmaware…
Can you check what version you have…? you have to use command “ver”
Look:
<2.21> get time
TimeEna=1
TIMEADR=129.6.15.28:123
Zone=23
<2.21> show t t
Time=05:34:02
UpTime=22 s
RTC=7827706938943 ms
Restarts=3
Wake=6
<2.21> ver
WiFly Ver 2.21, 07-11-2010
<2.21>
Thanks!
Hey guy! I contact technical support at Roving Networks @ http://www.rovingnetworks.com as you suggested me, and they answer me in 5 minutes! also they solve my problem! 
This is their answer:
we fixed the rtc in version 2.30. please try an upgrade
“ftp u”
Michael Conrad
Roving Networks
I made that and…
<2.21> ftp u
<2.21> FTP connecting to 208.109.78.34
FTP file=31
…
FTP OK.
UPDATE OK
Save and reboot…
And now:
<2.30> show t t
Time=06:10:29
UpTime=34 s
RTC=1323753029
Restarts=2
Wake=6
RAW=e948ae62ed4b
<2.30>
Problem Fixed!!!
Thanks for your help!!!
This time thing is a mess :-/. I’ve configured the WiFly to autosend data ever x or so seconds, it sends the following
GET$/xxxxx.php?data=std&id=xxx&rtc=xxx&mac=xxx…etc
I made a php file send the data to a server, it works great, mostly, here is a sample output
Record ServerTimeStampRaw ServerTimeStampDec RealTimeClockRaw RealTimeClockDec MacAddress BatteryLevel IOStatus
4 1327097439 2012/1/19-15:10.39 3536086242 TBD 00:06:66:71:1c:3a 2997 1d10
I can’t get the WiFly’s RTC timestamp to work correctly. You can see from the post right above it is already messed up. Here is what I’ve found out playing with it.
Raw is supposed to be the internal counter (32768 counts a second), so Raw/32768 should equal RTC. Sometimes it does, sometimes it doesn’t. It appears when you run the time command (or have it auto sync to a server) it sets the RTC correctly but not the RAW RTC, look above
RAW=e948ae62ed4b
divide by 32768 (dec) and you get
7827709125 which corresponds to 1D2915CC5, now I know from experience that my sqlserver will get D2915CC5 (it cuts it to 32 bits before sending to the server) which corresponds to
Fri, 12 Dec 2081 05:10:29 GMT (http://www.onlineconversion.com/unix_time.htm)
Now if you do
Time
show t t
and then manually set rtc by
set time rtc xxxxxxx (where xxxx is the value shown after you type show t t)
then there is a direct relationship between raw and rtc
(rtc = raw/32768 converted to int)
time
show t t
Time=16:23:15
UpTime=18446729075150589 s
RTC=1327098196
Restarts=1
Wake=1
RAW=e96233ea4952
set time rtc 1327098196
AOK
show t t
Time=17:58:34
UpTime=18446722571194495 s
RTC=1327098198
Restarts=1
Wake=1
RAW=278cf4ab18ad
time
show t t
Time=16:24:10
UpTime=18446722571194542 s
RTC=1327098251
Restarts=1
Wake=1
RAW=e9623405a274
After looking at this more, it appears every time it syncs to the server it gives RAW an offset. This is what I think that offset is
2208988800
RAW/32768
0x1D2C4680B (trim 32bits or subtract 0x100000000)
0xD2C4680B - 0x83AA7E80 (2208988800)
=0x4F19E98B = 1327098251 like above (taken from my last example)
Also works on my first example. Fails on my middle one where I set RTC manually. Weird.
Cant understand your problem… please can you be more direct?
Which Firmware version do you have ???
Firmware 2.31
When time is autoset using a time server, it sets the RTC value correctly but not the RAW value. This RAW value has some operations done to it and then is appended as a timestamp on packets if you have it set to or if you are using the option formats it gets sent along with the device id, the mac address, the io etc. I’ve noticed the value it sends is off by 2,208,988,800 after using autoset. If I set the RTC value manually using set time rtc, then the raw value is set and sent correctly. The large block of quoted text is actual communication back and forth with my module.
It also is happening on your module but I don’t think you use the autoconnect and send data on connection open like I am. Look at your values
RTC=1323753029
Restarts=2
Wake=6
RAW=e948ae62ed4b
That raw value should correspond to the RTC value multiplied by 32768. Lets check the math
e948ae62ed4b = 256,498,372,635,979
divide by counts per second 32768
7,827,709,125 = 1 D291 5CC5
Now when this gets sent over tcp as a timestamp it is shortened to 32 bits (it even says this in the datasheet)
D291 5CC5 = 3,532,741,829
which is off by
2,208,988,800
and it is consistently off whenever you use the time server to set your time
Lets check when I set RTC manually to what the timeserver said it should be at the time
set time rtc 1327098196
AOK
show t t
Time=17:58:34
UpTime=18446722571194495 s
RTC=1327098198
Restarts=1
Wake=1
RAW=278cf4ab18ad
and the math
278C F4AB 18AD = 43,486,353,758,381
divide by counts per second 32768
1,327,098,198
which matches my correct RTC time.
Contact technical support at Roving Networks. I’ve found them to be very responsive, but there remain many unfixed bugs in the code.
jremington:
Contact technical support at Roving Networks. I’ve found them to be very responsive, but there remain many unfixed bugs in the code.
+1 I also recommend you to contact them!! They are so nice and professionals! I sure they will fix your problem!
Will do when I get to work monday. I’ll post their response when I get it.
Update from Tech Support:
hello Jesse,
you win what’s behind door #1 on the price is right.
that number is exactly the amount of time between 1900 and 1970 Jan 1.
NTP from the network ( you can google it ) gives the value since 1900. but linux geeks kept complaining about that, so we added 0x83AA7E80 to bump the time up to seconds since 1970
If I do the time command, then show t t and set the RTC manually with the shown value using set time raw, then the Raw value is correct and the value sent is correct.
we will store what you give us, so in that case it is correct.
if we see that the time is already > 1970, we dont adjust it
(sorry our docs need some work )
so if you just want things to be happy when you let the auto time get the time,
just add the 0x83blahblah to the time and you will get what you want.
mike
I think he is the same who answer me too!! xDD
Look they are so nice! they are so helpfull!