- Wed Nov 24, 2021 7:56 am
#92897
Bill2k wrote:My sketch already has a function to get the time from an ntp server. I wanted to add this method to set the time in case the clock gets mounted in an area without wifi. It was a 'plan b'.
I think I'm gonna try to do something with mktime to see if that accomplishes what I want.
I too use both. If a station connection is available, I start the NTP process, but if the first connection comes in via SoftAP, JavaScript startup code goes out to the browser to send the time. As a backup, if a Station starts up later, I start the NTP process.
But for the problem at hand...
Client side JavaScript sends a number from
Number(new Date()). There's a myriad of ways to get it there and/or process it. Some use built-in stuff, other roll their own. In my case, I use a WebSocket and send binary back/forth between server and browsers and have my own Clock class.
My guess is you're running into an integer overflow issue. If you check the number derived from the JavaScript above, you'll find the number is far larger than an unsigned 32bit integer... (u32).
itoa() won't cut it!
Again there are multiple ways to address it.
- you can lop off the last three string digits
- while still on the browser side divide by 1000
With these two ways, you are losing the milliseconds. - I finally settled on using a 64 bit variable. (Note Serial.printf can't display these, but that's another story)
Code: Select all sint64 start = strtoll(hack, NULL, 10);
start -= millis();
_StartSeconds = (u32)(start / 1000); // Here's your seconds since
_StartFraction = (u16)(start % 1000); // Here's your milli-seconds
LOG(LL_INQCLOCK, "Manual Time Sync");
_State = MANUAL;
BTW - I find fretting about the milliseconds a waste of time. No pun intended. Expecting the browser to be accurate is a waste of time. Even NTP is very inconsistent. I've seen round trips being milliseconds to as large as seconds. Expecting the actual clock hack to be at half the round trip time is even optimistic. YMMV.
Hope this helps.
