Problems with epoch time for accelerometer
RTnhN opened this issue · 4 comments
- pymetawear version: 0.12.0
- Python version: 3.7.6
- Operating System: Windows 10
Description
I was getting the accelerometer data, and I noticed that there were some packet lost which is expected from bluetooth from what I hear. I was trying to find the lost packages by using the difference between epoch times, but this time is pretty sporadic and can vary between 0 ms and a couple hundred. Because of this, I don't know where the packets are being lost.
What I Did
I initially had much more complicated code that could be causing problems with the epoch numbers and data transmission, so I wrote the simplest code possible to test my problem.
Code
from pymetawear.client import MetaWearClient
from time import sleep
c = MetaWearClient('C2:B2:CE:9B:B7:C6', debug=True)
sample_rate = 25.0
c.accelerometer.set_settings(data_rate=sample_rate, data_range=8)
def callback(data):
print(data["epoch"])
c.accelerometer.notifications(callback) #Start Notifications
sleep(1.0)
c.accelerometer.notifications() #Turn off Notifications
c.disconnect()Run
python test.py
2020-04-02 12:17:44,329 DEBUG Added a logging handler to logger: pymetawear
2020-04-02 12:17:44,330 INFO Creating MetaWearClient for C2:B2:CE:9B:B7:C6...
2020-04-02 12:17:44,345 DEBUG Client started for BLE device C2:B2:CE:9B:B7:C6...
2020-04-02 12:17:49,330 DEBUG Setting Accelerometer ODR to 25.0
2020-04-02 12:17:49,330 DEBUG Setting Accelerometer FSR to 8.0
2020-04-02 12:17:49,342 DEBUG Subscribing to Accelerometer changes. (Sig#: 2791206498272)
2020-04-02 12:17:49,348 DEBUG Start Sampling (Accelerometer)
1585801069638
1585801069639
1585801069698
1585801069758
1585801069759
1585801069818
1585801069878
1585801069879
1585801069938
1585801069998
1585801069999
1585801070118
1585801070119
1585801070119
1585801070178
1585801070238
1585801070239
1585801070298
2020-04-02 12:17:50,350 DEBUG Unsubscribing to Accelerometer changes. (Sig#: 2791206498272)
To make the results more readable, I put it in the table below.
| Sample Number | epoch (ms) | Time Between Timestamps (ms) |
|---|---|---|
| 1 | 1585801069638 | |
| 2 | 1585801069639 | 1 |
| 3 | 1585801069698 | 59 |
| 4 | 1585801069758 | 60 |
| 5 | 1585801069759 | 1 |
| 6 | 1585801069818 | 59 |
| 7 | 1585801069878 | 60 |
| 8 | 1585801069879 | 1 |
| 9 | 1585801069938 | 59 |
| 10 | 1585801069998 | 60 |
| 11 | 1585801069999 | 1 |
| 12 | 1585801070118 | 119 |
| 13 | 1585801070119 | 1 |
| 14 | 1585801070119 | 0 |
| 15 | 1585801070178 | 59 |
| 16 | 1585801070238 | 60 |
| 17 | 1585801070239 | 1 |
| 18 | 1585801070298 | 59 |
Note that since the sample rate is 25 samples per second and the sample period was 1 second, the number of samples should be about 25. This also means that the time between timestamps should be about 40 ms.
While I can estimate data that is lost, but I don't know where the samples were lost.
When I use the metawear app on my iPhone, I don't notice any problems with time between samples being wrong or major differences between expected number of samples and actual number of samples, so I don't think this is a problem with the hardware.
Thanks!
I realized that my problem is with the underlying python library from Mbientlabs and not this library. Evidentially the epoch time for each measurement is not useful.
Yes, the problem is in the mbientlab package, i.e. the Python Wrapper of the C++ SDK that Mbientlab has.
If you change your script to this:
import datetime
from time import sleep
from pymetawear.client import MetaWearClient
c = MetaWearClient('C2:B2:CE:9B:B7:C6', debug=True)
sample_rate = 25.0
c.accelerometer.set_settings(data_rate=sample_rate, data_range=8)
def callback(data):
data["py_epoch"] = datetime.datetime.utcnow().timestamp() * 1000
print(data["py_epoch"])
c.accelerometer.notifications(callback) #Start Notifications
sleep(1.0)
c.accelerometer.notifications() #Turn off Notifications
c.disconnect()and run it, does the epoch times registered in the callback actually happen every 40 ms? In that case, use this type of "timestamp-on-arrival" instead. It is not exact, relative to when it was measured on the device, but probably sufficient for most applications.
Thanks for the reply. That seems like a pretty good workaround. On average for 25 samples, it seems that the timestamp is about every 41.3 ms, but the variability is pretty high (stdev ~ 4.2 ms).
Digging deeper into the official python API, I found the accounter dataprocessor that adds extra data to the data packets so that the timestamp can reliably be reconstructed. The accounter dataprocessor does all the work in reconstructing it, so there is no change in extracting the epoch from the data object. With this, the average for the same 25 samples is 40.9 ms with significantly lower variability (stdev ~ 0.6 ms).
If you are curious about the implementation code, you can find it below. It might be cool if pymetawear had a "high-accuracy / low-accuracy epoch" parameter that would add the accounter for whatever sensor it was enabled on.
from __future__ import print_function
from ctypes import c_void_p, cast, POINTER
from mbientlab.metawear import MetaWear, libmetawear, parse_value, cbindings
from time import sleep
from threading import Event
class State:
def __init__(self, device):
self.device = device
self.callback = cbindings.FnVoid_VoidP_DataP(self.add_data)
self.processor = None
def add_data(self, ctx, data):
print(data.contents.epoch)
def setup(self):
libmetawear.mbl_mw_settings_set_connection_parameters(self.device.board, 7.5, 7.5, 0, 6000)
sleep(1.5)
e = Event()
def processor_created(context, pointer):
self.processor = pointer
e.set()
fn_wrapper = cbindings.FnVoid_VoidP_VoidP(processor_created)
libmetawear.mbl_mw_acc_set_odr(s.device.board, 25.0)
libmetawear.mbl_mw_acc_set_range(s.device.board, 8.0)
libmetawear.mbl_mw_acc_write_acceleration_config(self.device.board)
acc = libmetawear.mbl_mw_acc_get_acceleration_data_signal(self.device.board)
libmetawear.mbl_mw_dataprocessor_accounter_create(acc, None, fn_wrapper)
e.wait()
libmetawear.mbl_mw_datasignal_subscribe(self.processor, None, self.callback)
def start(self):
libmetawear.mbl_mw_acc_enable_acceleration_sampling(self.device.board)
libmetawear.mbl_mw_acc_start(self.device.board)
d = MetaWear("C2:B2:CE:9B:B7:C6")
d.connect()
print("Connected to " + d.address)
s = State(d)
print("Configuring %s" % (s.device.address))
s.setup()
s.start()
sleep(1.0)
print("Resetting devices")
e = Event()
s.device.on_disconnect = lambda s: e.set()
libmetawear.mbl_mw_debug_reset(s.device.board)
e.wait()That seem like a better idea indeed. If I return to using this libary I might add something like this to the modules.
BTW, the libmetawear.mbl_mw_debug_reset method is not something that is recommended to use as a "I am done with the device" method, It should be sufficient with a disconnect.