24-hour Timestamp in Console

Noticed in v3.19.2

Has anyone else noticed that the timestamps at midnight go to 24:mm:ss rather than 00:mm:ss ?
ConsoleTimestamps23-24

I’m currently in BST (UTC+1) but suspect that has nothing to do with the issue I see.
After 1 am it is fine.

ConsoleTimestamps24-01

I hesitate to suggest that this is a defect, but it does seem pretty odd to me!

2 Likes

Last night I were busy after 00:00 and the time stamps were correct as 00:00.

We are +2GMT.

Your uplink are also vey fast at 90sec.

@Johan_Scheepers Interesting :thinking:
I wonder if it is a consequence of having the console stream open during the rollover of the date?
I have since reduced the frequency of uplinks (it was temporary rate while commisioning a new solar powered node). I was actually trying to determine the number of uplinks at SF7 before the LiPo became exhausted following a couple of hours of sunshine earlier in the day. It is lasting longer than I expected (which is good!).

I don’t think so, as my console were active (open) way before 22h00 to 01h00.

Interesting find. The origin seems to be on the browser side actually, by following a wonky spec too closely:
https://bugs.chromium.org/p/chromium/issues/detail?id=1045791&q=hourcycle&can=1

Are you using Chrome? Seems to be happening when the browser determines en-US as host language.

I’ve created a PR to fix this issue which should be included in the next release cycle.

1 Like

Yes I was using Chrome (latest version) :smiley:
As it happens I had already setup a test for this evening to compare Chrome, Edge & Firefox side by side. Looks like you have already narrowed it down.
However just FYI, locale is en-GB as confirmed by the Dev Tools…
en-GB
Thanks for following this report up.

Please don’t - please DO measure the average mAh that’s required - typically using either a big capacitor so you only need to do a dozen uplinks properly spaced out (as sleep is the biggest power use overall) or by using a power monitor - then you can use a resistor to drain the LiPo and do the maths.

Otherwise you run the risk of disrupting the network for hours on end when you do further tests and none of them will be correct.

Excellent advice

My enthusiasm to get the node up and running was rather overtaken by the observation of the anomaly on the console time stamps! Once I had satisfied myself that the node was broadcasting the correct data I should really have just put it in a cage with a dummy load so that it was blind to the network.

The original LiPo was just something I had to hand but now I have to look more seriously at the energy requirement of the RAK10700 for a given transmit periodicity and correctly size the battery.
I have not yet determined what is the minimum supply voltage level that needs to be maintained for the node to transmit, since it has a u-blox ZOE-M8Q & Bosch BME680 sensor both providing a continual power drain.
Also, the UK is not exactly reliable with respect to solar radiation :frowning: however at this time of year the sun can be suprisingly intense even if it only makes occasional appearances.

Potentially I could illuminate the solar panel with constant daylight energy by temporarily “borrowing” the light from my wife’s hydroponic smart kitchen garden, thus mitigating the variable energy input :wink:

I suspect there will be plenty of experimentation ahead, which is ideal as this is a hobby project.

Getting the thread back on topic, regarding

… I have updated the PR with some additional data showing that it is not just Chrome that has the timestamp issue. Last night I repeated my test with FireFox, Edge & Chrome all watching the data when the new day started.

…and the result was?

rather others/anything Chromium based, perhaps?

Appreciate any update, out of general interest vs any critical need at this point :wink:

Result was Firefox is fine but the Chromium based browsers (Edge & Chrome) get it wrong (at least for en_GB). My test was purely superficial & didn’t try to exercise other locales.

That was my suspicion when you posted update - I hadnt seen the problem personally…90% FFox based, as also use other none Chromium/Chrome monoculture based browsers where I can - Safari or FFox on iPads, FFox on android, otherwise Edge (Chromium based) if I must - say on guest PC’s @ host sites etc. :wink: Thanks for update/confirmation.