Octave 3.2.1 - FX30S - ULPM -Octave Time (OS Date) drifts when no NITZ available

Octave
1

Our project uses ULPM and needs reasonably accurate local time (say +/-30 seconds), so that measurements have reliable timestamps.

My current Octave edge device test project is implemented as follows (Device Path /linkwave_technologies/devices/fx30s_1 ID d5ee3a3d45dc8dd9b563f7baf):

  1. Wakes from ULPM
  2. An edge action fires after boot (implemented using an autostart one shot timer) - this causes measurement (app) to start measurement
  3. Energiya Resources takes measurement (via Energiya Legato service)
  4. Energiya measurement resource triggers my edge action which pushes measurement and timestamp data to the cloud and starts a delay resouce
  5. Delay resouces runs for x seconds - giving the system time to stabilise enough to successfully send data to the cloud
  6. Delay callback edge action requests ULPM
  7. System shutsdown
  8. ULPM

There are issues with this implementation

  1. The edge device time slips over time (see below test results)
  2. The app can’t tell if the Octave system was awake long enough to successfully send the data to the cloud. Relying on an arbitrary delay isn’t good practice - we could use a cloud action to acknowledge the receipt of the data but this seems wasteful of data resources.

It would be useful if we had

  1. Octave edge action access to the system time validity - maybe a time of last time update resource?
  2. Have Octave edge action access to the edge devices cloud data pipeline status - maybe a cloudInterface\UplinkWaitingMessages resource?

Maybe alternative edge implementation solutions exist that I’m not aware off?

Edge time slip over days

The following are the first and first last transactions from edge to cloud over a a number of days. Note that at the end of testing local time has slipped 19 minutes

Creation Date Generated Date Delta elems.virtual.straingauge1.value.value
Aug 5, 2021 21:28:53 GMT+1 Aug 5 2021 21:28:53 GMT+1 573ms 67.459375
…
Aug 9, 2021 08:44:12 GMT+1 Aug 9 2021 09:03:22 GMT+1 19 minutes 67.865625

After further investigation - If a reboot is sent over the air to the edge device, the edge device time is updated (ntp? we don’t have much NITZ in the UK).
(Oldest sample is at the top of the list)

Creation Date Generated Date Delta elems.virtual.straingauge1.value.value
Aug 9, 2021 12:23:54 GMT+1 Aug 9, 2021 12:42:28 GMT+1 19 minutes 67.78125
REBOOT OTA
Aug 9, 2021 12:23:54 GMT+1 Aug 9, 2021 12:23:29 GMT+1 24.610s 67.778125
Aug 9, 2021 12:54:58 GMT+1 Aug 9, 2021 12:54:48 GMT+1 10.251s 67.778125

Note that the “Generated date” was 19 minutes ahead of the “Creation date” (cloud real date) until the edge device was rebooted causing the edge FW or Legato or Octave code to set the edge time to the correct time.

2

Hi John,

I am taking a look at this. You are located in the UK correct?

1 Like
3

Hi David

Yes UK based
There isn’t much cellular NITZ support here. I expect that time is being set using NTP.

Looks to me like the issue is that somewhere in the Legato / Octave boot sequence, code is checking for a sane OS date/time.

If the OS date / time is not sane NTP based time setting is applied.

I think the FX30S has an RTC which is maintained during ULPM / ON / ULPM. The RTC drifts quite a lot and cannot maintain accurate time for more than one day.

Just noticed that the Delta calculation in the cloud is using some funky maths - it always produces positive Deltas. Might be worth changing it to enable +/- deltas

4

Hi John,

Our Engineering Team is looking at this now.

1 Like
5

Hi, I confirm the message from @djudkins
The issue was reproduced on our side.
We are working on it

2 Likes