Time jumps on Monitor One

Cloud
1

Hi,
In the last few days an issue emerged which I have never seen before, and which is driving me nuts. On a Monitor One test unit time keeps resetting back to 00:00 Jan 1st 2018.

The symptoms are as follows:

  • The unit is put into shipping mode and then woken up by supplying power
  • It operates normally for several hours sending messages every 5 minutes
  • Then Time.now() starts reporting the wrong time (reverts back to 2018) which screws everything up because time stamps on messages are important for our application
  • executing Particle.syncTime() in the firmware does not help
  • The only way to go back to normal is to put the unit back into shipping mode and wake it up
  • Then everything repeats

I did add a timestamp check to the code which triggers Particle.syncTime() when it looks wrong, but it does not help, and the result is shown below. I am running a customized firmware and the OS version is 6.1.0

Any help is greatly appreciated…

**sync

Published by e00fce68b2d8c4905c1ae269 on 11/26/25 at 2:27:32 pm
Firmware version: 3
Private event
{**
"cmd":
"sync"
"time":
1514764809
"hash":
"103DC4F3ED09E02B0C1DEC7C4F39B31D"
}

2

I don't know the answer, but my guess is that the AM1805 external RTC oscillator is stopping, but Device OS still believes that the external RTC has the correct time and is using that instead of the cloud time. The trace logging level has some messages about time synchronization that may be helpful in narrowing it down.

3

Is there a way to explicitly get the cloud time / cell network time or whatever other time for periodic synchronization? I thought Particle.syncTime() was supposed to accomplish that.
I have put the following code into a Particle.function and executing this command though the web interface still returns the wrong time…

if (command == "synctime") {

    Particle.syncTime();

    return Time.now();

}
4

The syncTime call is asynchronous. You need to use syncTimeDone to wait for it to complete.

5

Can it be forced? How long could it take to complete? I am looking for a way to get reliable time reference in a predictable manner. This has turned into a complete showstopper after many months of developing custom extension board for the Monitor, writing firmware etc. I also do not understand where 2018 comes from. 1970 I could understand.

6

If you are cloud connected it should take no more than a few seconds.

7

Well, it does look like there was some hardware issue on the unit in question which resulted in the weird behavior.
Switching to a different Monitor One resolved the issues. There is a first time for everything, I guess…

Thank you for the help!