Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sensor Data Alignment with Real Time #5

Open
mcculloh213 opened this issue Jun 7, 2024 · 3 comments
Open

Sensor Data Alignment with Real Time #5

mcculloh213 opened this issue Jun 7, 2024 · 3 comments

Comments

@mcculloh213
Copy link

Is your feature request related to a problem? Please describe.
I am currently attempting to use this firmware with a Python application. I would like to align the sensor data with the time coming from an NTP server to make this easier.

Describe the solution you'd like
Would it be possible to push a UTC timestamp to the sensor through a GATT service and receive that timestamp along with the data from the ECG and IMU GATT services?

Describe alternatives you've considered
I've tried several means of compensating and offsetting the time, but I have consistently found myself +- 1.5 seconds off from a video recording of an event, which is aligned with our NTP server.

@JonasPrimbs
Copy link
Owner

That's a good idea!

Unfortunately, the Movesense device shuts down entirely when it goes off and stops counting on the internal time.
Therefore, the timestamp transferred in the ECG Voltage Characteristic is the internal time with millisecond precision starting at the time when the sensor wakes up. This changes whenever the sensor is restarted, so the value needs to be re-synchronized after every restart!

As you seem to have figured out yet, the delay between the sensor and the end device is hard to predict.
Therefore it is not reliable to set the UTC time via a characteristic (which seemed impossible for performance reasons on the old firmware basis, but maybe this changed with the last release) because the delaying problem will also exist there.

My personal recommendation to solve this issue is: Use the fact that the sampling rate is very reliable.
That follows to solutions:

  1. Compute the UTC time on the end device by using multiple packets as data basis:
    Collect timestamps (the more packets, the more reliable) transferred from multiple notify events (e.g., ECG Voltage Characteristic) and its measurement interval (e.g., 4ms = 250Hz) and assume that the last sample of the n^th packet was measured 4ms before the first sample of the (n+1)^th packet. Compute the difference between the UTC timestamp when the packet was received and the transferred timestamp from the packet. To compute the UTC timestamp of when the device was started. Because of different delay times you might get multiple UTC timestamps for this point in time. Choose the lowest one (most in past) and subtract another d ms where d is a delta based on experience.
  2. Synchronize the device timestamp with other sensors (e.g., your video), e.g., by clapping in your hands and detect the timestamp of the acceleration peak (when your hands clap) and synchronize this time with the camera's frame timestamp when your hands touch each other. Obviously this only works when you wear the sensor on your arms or hands.

If you have found a better solution or have another idea, please let me know and I will test it.

@mcculloh213
Copy link
Author

Guten Morgen!

Thank you for your proposed solutions -- I am trying to utilize both methods you have suggested, but I am also working on implementing a GATT service to push the current UTC timestamp over to the sensor. I wanted to ask if you had any recommended methods to debug firmware aside from Movesense's debug jig?

@JonasPrimbs
Copy link
Owner

I don't have the debug jig, so I was debugging with the try&error and sometimes used the LED to debug. But afaik there is no wasy to have something like a serial communication for logs without the debug jig.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants