time step in continous acceleration logging is not constant

[HotteDerZweite]

In the file data_acceleration_50Hz.txt

you see the logging result using demo_accelerometer_logging.py from develop-branch of bchwtz-fhswf/gateway from 2021-12-18. During the measurement the ruuvi tag was flipped several times from botton to top. So the z-axis was expected to show alternating +/-1g values, which it does (see graph in Excel-file). acceleration_data_50Hz.xlsx

The sampling steps which should be @50Hz, i.e. 0.02s intervals, look erroneous:

1) They are alternating between 0 and 0.04s, might be because of using a float for the date/time-value. 2) Every now and then there are bigger gaps, once 3s(!) other were seen around 0.012s.

[bchwtz]

Except two outliers, the time interval look somehow cyclic, which may indicate that this is some form of calculation error in the gateway library. Can someone please confirm that this is not firmware related? Is there the possibility to get the raw data from the sensor somehow with the actual develop codebase?

[HotteDerZweite]

With repeated measurements with the same sensor settings the described artefacts - even the position of the outliers - can be reproduced.

[HotteDerZweite]

Further details: the alternation between 0 and 0.04s occurs 31-times, followed by "another" time step. In a chat @thomas57258 gave a hint that this might be linked with blocksize of 32 samples. So inside a block the time is interpolated linearly - mutually the alternating between 0 and 0.04s comes from float-discretization. The "other" time steps with unexpected stepsize might come from interrupts not coming at the precise time, but according to @thomas57258 the 3s step is far too high for that reason.

[Marius9610]

• @HotteDerZweite: Can you also use the function get_config to provide the configuration part of the sensor? Thank you very much.
• According to the documentation , a sample consists of 32 tubles. It appears that the timestamp between the tuples is not correctly counted up. When switching between two datasets, a new start-timestamp is extracted from the new dataset. The sensor configuration is important to test the thesis.

[HotteDerZweite]

The config is this one: sensor1.set_config(sampling_rate = 50, sampling_resolution = 12, measuring_range = 4)

[HotteDerZweite]

Since 41542a5 the results show significant improvement. Now there're "very often" the correct time steps. The gaps after each block however remain the same, especially the bigger ones of ~3s and 0.5s need to be fixed.

[thomas57258]

Large timesteps are caused by garbage collection of Flash Memory. See attached Logfile line 15 and to 17. In this case the garbage collection process needs 1.2 seconds. During this time no new acceleration data can be saved. gb_log.txt

[systematiccaos]

Need to implement a timetracker on the tag itself, since there are unpredictable latencies inside the ble-protocol.

Should be a new Feature for firmware