SparkFun Forums 

Where electronics enthusiasts find answers.

All things pertaining to wireless and RF links
By SICOPOLY
#136820
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!
By jremington
#136849
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
By SICOPOLY
#136863
jremington wrote: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
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
By jremington
#136872
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.
By SICOPOLY
#136874
jremington wrote: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....
By SICOPOLY
#136910
Oh For you is working! :O
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!
By SICOPOLY
#136913
Hey guy! I contact technical support at Roving Networks @ http://www.rovingnetworks.com as you suggested me, and they answer me in 5 minutes! :O 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!!!
By Colecago
#138576
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.
By SICOPOLY
#138579
Cant understand your problem.... please can you be more direct?
Which Firmware version do you have ????
By Colecago
#138589
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.
By Colecago
#138590
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.
By jremington
#138614
Contact technical support at Roving Networks. I've found them to be very responsive, but there remain many unfixed bugs in the code.
By SICOPOLY
#138623
jremington wrote: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!