SNTP and xml time display on web page - quick question
![xanatos](https://forums.parallax.com/uploads/userpics/416/n3HKAG8I3I8DH.jpg)
I've got SNTP 2.01 running well and displaying (updating every second) on a few of the web pages on my Spinneret's SD card. What I've noticed are two small but curious items regarding the day of the week, and the seconds display.
The day of the week as shown is consistently two behind (Wed shows as Mon, Sun shows as Fri, etc). I've fixed that by just subtracting for now, but I know that's only going to be a fix for anything that doesn't go less than 0.
The seconds issue is more vexing - what happens is that when a minute is incremented, the seconds, 00 - 09, show up as 50 - 59, then continue as normal as below:
21:58
21:59
22:50
22:51
22:53....
22:59
22:10
22:11...
It looks to me like the buffer isn't clearing out the 5 and is just writing the single character 0 - 9 instead of replacing the 5 with a zero in the byte array... Has anyone seen this before and/or is there a known fix for this? I'm working my way through this, and it's not really affecting anything - but it looks dumb and I'd like to fix it - hopefully by this evening, since I'm installing tomorrow.
Also, it should be noted, that only on the xml page display is this evident - the emails I send out, which are time-stamped, have normal seconds 00 - 09.
Thanks if anyone can assist.
Dave
Update:
Looking at these two functions - which are called from XmlTime, it appears there should be an offset for this issue in HTTPServer.spin - but it's not doing it for the seconds:
The day of the week as shown is consistently two behind (Wed shows as Mon, Sun shows as Fri, etc). I've fixed that by just subtracting for now, but I know that's only going to be a fix for anything that doesn't go less than 0.
The seconds issue is more vexing - what happens is that when a minute is incremented, the seconds, 00 - 09, show up as 50 - 59, then continue as normal as below:
21:58
21:59
22:50
22:51
22:53....
22:59
22:10
22:11...
It looks to me like the buffer isn't clearing out the 5 and is just writing the single character 0 - 9 instead of replacing the 5 with a zero in the byte array... Has anyone seen this before and/or is there a known fix for this? I'm working my way through this, and it's not really affecting anything - but it looks dumb and I'd like to fix it - hopefully by this evening, since I'm installing tomorrow.
Also, it should be noted, that only on the xml page display is this evident - the emails I send out, which are time-stamped, have normal seconds 00 - 09.
Thanks if anyone can assist.
Dave
Update:
Looking at these two functions - which are called from XmlTime, it appears there should be an offset for this issue in HTTPServer.spin - but it's not doing it for the seconds:
PRI FillHttpDate | ptr, num, temp 'ToString(integerToConvert, destinationPointer) 'Wed, 01 Feb 2000 01:00:00 GMT ptr := @httpDate rtc.readTime temp := rtc.getDayString bytemove(ptr, temp, strsize(temp)) ptr += strsize(temp) + 2 FillTimeHelper(rtc.clockDate, ptr) ptr += 3 temp := rtc.getMonthString bytemove(ptr, temp, strsize(temp)) ptr += strsize(temp) + 1 FillTimeHelper(rtc.clockYear, ptr) ptr += 5 FillTimeHelper(rtc.clockHour, ptr) ptr += 3 FillTimeHelper(rtc.clockMinute, ptr) ptr += 3 FillTimeHelper(rtc.clockSecond, ptr) return @httpDate PRI FillTimeHelper(number, ptr) | offset offset := 0 if(number < 10) offset := 1 str.ToString(@number, @tempNum) bytemove(ptr+offset, @tempNum, strsize(@tempNum)) return
Comments
I think (not absolutely sure) you might see the same issue when the hour is incremented- the minute value will do the same as the seconds value in your example. I haven't tried it but the rtc.clockMinute/Second/etc methods don't pad single digit values with a 0 (they return decimal values, not ascii characters.) There should be two ways to fix this.
First would be to add a 0 for padding when appropriate. Something like:
Second solution would be to fill the entire httpDate buffer with ASCII 0's and then overwrite with new data as appropriate:
(This one will probably give an output in your httpdate like Wed,0010Feb02000001:00:000GMT so check closely.)
I don't remember how long the httpdate is but I think it's 29. You might want to double check this.
P.S. I'm spitballing this because I can't test it right now. Nowhere near hardware. I apologize in advance if this doesn't work!
Robert
I'll let you know if that does it, or if I have to tweak it any.
Dave
UPDATE: Option 1 worked like a charm! Thanks!!! Now I just need to figure out how that SNTP byte array gets packed... It's still Sunday :-)
Sometimes I wish we had about 98 hours in a day.
What are you trying to figure out? Something specific? Or just in general how it works?
I'm scrambling to finish up the project to install this week (was supposed to be today but I found an issue yesterday...) so unless it's a simple fix, they're just going to have to be satisfied with it being Sunday half the week! :-)
Well, the end result of the SNTP object is to get the NTP value of the transmit timestamp (unless you've decided to use one of the other timestamp methods in the object) and give that NTP value to the HumanTime method to work with. The HumanTime method does *all* of the number manipulation to convert the raw NTP value into bytes that contain decimal values that we can relate to more easily. So- if the DoW is not correct, something in that particular method is not correct in how it's determining the day of the week.
Post the exact HumanTime method you're using (remember, there's about a bazillion of them now) and I'll try to help figure it out if you'd like. I ask so many friggin questions around here the very least I can do is attempt to spit out an answer once in awhile
Here's the HumanTime Method from SNTP 2.01:
And in the post above is the DisplayHumanTime Method that's in HTTPServer.spin that actually takes the data and sets it into the rtc.
I'm still looking for anything, anywhere, in SNTP 2.01 (also posted below) that actually has the Sat, Sun, Mon... etc., abbreviations listed and associated with a number in some sort of lookup table or something. I had figured that would be the place to make the change, just chaanging the day that is associated with the number... but no such table have I found yet.
EDIT: I found the correspondence table - it's in S35390A_RTCEngine.spin
EDIT 2: However, having found that, I figured that the best line to edit was the one in the HumanTime Method:
DW := (Days-1) // 7
I just changed that from a -1 to a +1 and the day is lining up now.... so, I *may* have figured it out. Can you see any way in which that'll mess anything up?
I know how you feel about asking questions and wanting to help. It's a very rewarding feeling to be able to help with something on here, and I feel like it's the least I can do to pay tribute to the people on here who have been so helpful. I honestly could never have gotten as far as I have with microcontrollers if it wasn't for this forum's people.
Thanks again for helping. After two full months now of 10 to 12 hours days in this project (to be fair, though, the last two weeks have mostly been fabricating the housing and doing all the wiring, which I never would have guessed was going to take so long) - I'm really ready to do something that doesn't require soldering irons, magnifying glasses or keyboards. I've never wanted to spend a day doing yard work more in my life! :-)
Dave
SNTP 2.01:
DW := (Days-1) // 7
Dunno how to fix that yet- gonna watch Dexter and come back to it.
Dave
DW := (Days-1) // 7 +1
That'll do it.
Doing DW := (Days+1) // 7 will throw you off at the end of the week instead of the beginning.
However, Jan 01 1900 was a monday.
So, that means Mondays are the 1st day of the week for this line of code.
The math should interpret that as ((Days-1) // 7) +1 if I have my order of operations correct.
But then that means that the resultant 0 through 7 would now become 1 through 8, am I correct in that, or do I fundamentally not get something in the math there?
If I'm correct, then, with the days of the week corresponding to numbers 0 to 7, what does 8 yield?
Let's say Days = 6
Days-1 = 5
5 // 7 = 5
5 // 7 +1 = 6
Let's say Days = 7
Days-1 = 6
6 // 7 =6
6 // 7 +1 = 7
Let's say Days = 8
Days-1 = 7
7 // 7 = 0
7 // 7 +1 = 1 (Remember, day 8 is the first day of the second week... )
Let's say Days = 13
Days-1 = 12
12 // 7 = 5
12 // 7 +1 = 6
Let's say Days = 14
Days-1 =13
13 // 7 =6
13 // 7 +1 = 7
Let's say Days = 15
Days-1 = 14
14 // 7 = 0
14// 7 +1 = 1 (Remember, day 15 is the first day of the third week... )
The +1 is applied to the result of the modulo... modulum... modulai... moduleesis. Yeah that thing. Either way, it's always going to return a value of 0 thru 6, never seven. Since we don't have "day 0" of the week, the +1 makes the result 1 through 7.
I'm following your logic, so far, so good. So then the issue becomes which day should be 0. Here's the DAT block in the RTC Engine:
Does the change in my HumanTime line for DW mean I should change the day lineup in my DAT block so that it starts with Monday instead of Sunday? because if I use
((Days-1) // 7) +1
Then it says that today is Monday, when it's actually Tuesday... changing the DAT line to:
Does make it display the correct day of the week - but will it screw anything else up?
I was just sitting here giving myself a headache thinking through that exact change in the DAT section. I think that's the correct fix. It shouldn't mess with anything else because the only thing that uses that line of the DAT block is the getDayString method.
Here is a sample stand-alone program for playing around with this "issue" a bit. It might help if you come into more trouble with the day of week, but I think you've got it licked now.
It's nice to be down to little tweaks - especially since the (new) install date in Thursday...
Dave