5/feat/ble time syncing

[vicgwee]

Will close #11

Right now, it reads unformatted time (after current time). Comparison with millis():

Connected event, central: 6c:1b:2f:f8:23:bc
Current Time:E507090302080C05D3       11138
Disconnected event, central: 6c:1b:2f:f8:23:bc
Connected event, central: 6c:1b:2f:f8:23:bc
Current Time:E507090302081105F4       16227
Disconnected event, central: 6c:1b:2f:f8:23:bc
Connected event, central: 6c:1b:2f:f8:23:bc
Current Time:E50709030208170522       21365

[vicgwee]

What time is received:

Byte	Meaning
10	Adjust reasons (1 bit per reason)
9	Fractions of a second (256th)
8	Day of Week
7	Seconds
6	Minutes
5	Hours
4	Day of Month
3	Month
1-2	Year since 1792

Byte 1-7 is commonly known as ble_date_time_t Code here: https://github.com/iot-bus/iot-bus-bluetooth-examples-platformio/blob/7e79bdbfd48774ccd8dcc4f37b71d7f4c40255fa/temperature-monitor/src/bluetooth_time.h

According to https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/bluetooth/peripheral_cts_client/README.html

[vicgwee]

Tested

• Works with two MCUs connected to my phone
• Time taken to read CTS data ranges from 50ms to 320ms, avg is 90ms. Perhaps can disregard the high latency (>100ms) ones. http://uu.diva-portal.org/smash/get/diva2:1275298/FULLTEXT01.pdf This suggests to discard outliers and use linear regression to find the skew and drift

[vicgwee]

I compared how long it took for the onboard clock (millis) to be de-synced with the CTS clock by 1000ms:

MCU 1 took 126 seconds MCU 2 took 120 seconds

In both cases, the Arduino clock was consistently slower than the CTS clock.

Syncing with the RTC, the results are more consistent, no significant de-syncing after several minutes. Will need to test it for longer.

[vicgwee]

I synced the RTC and the CTS times at the start. Then, I plotted the RTT (blue) of each CTS packet and the time difference (red) in ms between the RTC time and the received time over several minutes. If the RTT was over 80ms, the datapoint was not plotted:

Some insights:

• The time difference consists of a consistent offset (zero error) of around 10-15 ms and a random error about between +40 to -20ms
• The consistent zero error is because the very first reading had a significant random error. Doing continuous synchronisation would allow us to identify and eliminate this zero error.
• The gradient of the time difference is close to 0. This is consistent with the previous test of no de-syncing of the RTC and CTS.
• Seems very possible to do a linear regression or even a simple filter to reduce the random error and get accuracy within several ms
• Removing datapoints with high RTTs helped to reduce the random error significantly. Otherwise, the random error could shoot up to 100s of ms.

[vicgwee]

Right now, the filter is not optimised. But the RTC updating function works. Will just merge it in and plan to enhance the filter later.