More accurate time recovery

[jdavid]

This has been found in a log file:

2019-03-07 06:00:20.821000 WARN unexpected ack command
2000-01-14 20:36:37.483000 WARN Wrong time detected
2019-03-07 00:03:25.054000 ERROR GPS Timeout

This proves that time recovery from TIME.TXT works. We can do better. We know the RTC restarts at 2000-01-01 00:00:00, so we just have to add the time elapsed:

new time = time from TIME.TXT + time from RTC - 2000-01-01

[jdavid]

Also check when the time is far in the future, we've seen that once.

In commands.cpp and FinseWSN_3_0.pde we call RTC.getTime(), instead print the system time.

[jdavid]

Sometimes we have this in the logs:

1578181812.719 INFO Alarm 2 at 05:00:02 mode=3 (only hour/min match)
946598400.000 WARN Wrong time detected
1578181812.001 INFO Time loaded from TIME.TXT

The 946598400 epoch time is 1999-12-31 00:00:00 but this is an impossible value. When reset the RTC represents 2000-01-01 00:00:00. See:

RTC.getEpochTime(0, 1, 1, 0, 0, 0) # 946684800 Correct
RTC.getEpochTime(0, 1, 0, 0, 0, 0) # 946598400 Bug
RTC.getEpochTime(0, 0, 0, 0, 0, 0) # 946598400 Bug

The third parameter, Date, is zero. This error happens always in early boot, we just read RTC registers.

I've not found anything suspect in the software, it's pretty simple, so my hypothesis is that this is a hardware issue. Specifically maybe a bus issue, for some reason the I2C bus sending all zeroes.

For reference this is the RTC datasheet, https://datasheets.maximintegrated.com/en/ds/DS1337-DS1337C.pdf

[jdavid]

For information, in one specific case, sw-002 from Svalbard, I've calculated the mote went off for 1 day, 13:32:46. When it woke up again it recovered the time from the TIME.TXT file, and 11 frames were off by 1 day, 13:32:46, until the correct time was set from 4G. I fixed the timestamps for these frames in the database.

In this case, if the time was fixed using the RTC as specified in this issue, the time would have been corrected by 1 day, 13:28:13, so there would be still ~ 4 minutes error, probably good enough.

From the data gathered so far I think it would be good to:

• If the RTC time is after 2000-01-01 load the time from TIME.TXT and adjust it using the difference of the RTC time since 2000-01-01, as specified.
• Schedule to run time sync from network as soon as possible.
• If the RTC time is before 2000-01-01 then assume it's a temporary I2C bus error and reboot the mote. To avoid many quick reboots, reboot after a few minutes.