Synchronous sampling / acquisition / record from the multiple MMR
Hello,
When connecting multiple MMRs and acquiring multiple acceleration data simultaneously from the multiple MMRs, are the acquired acceleration data synchronized? Is there an instruction or steps or command to direct the multiple MMRs to synchronously sample / acquire / record the data?
Comments
No, MMRs are independent of one another. The clock is resolved when the data is downloaded to a specific device. So if all the data is downloaded to your laptop, all the MMRs will sync to your laptop clock.
Just write code to connect and set them up synchronously.
However you really don't care because all data is timestamped with a date down to the millisecond so you can always get your data and then "sync" them up on post processing VERY easily. Even if one sensor start one minute early, you don't care, just throw out that extra minute of data into the trash when you sync it with the other sensors.
We wrote a code to simultaneously record the acceleration data from two MMRs. As you can see from the attached data, the time difference between the two sampled acceleration data are quite different. The difference even changes during the measurement.
Is there a function to specify to start and sample at the exactly the same time for multiple MMRs?
Post-processed synchronization is an artificial or mathematical data (by interpolation or other means). We want to get actual synchronous data from measurement, not mathematicaly.
@qpal1012,
That is not how it works in real life. Real data is not perfect. Post processing is always required.
My data has the same behaviour, the difference changes through the measurement. And it is quite a big difference for my study. Shall I just ignore it? or try to adjust it to make that time difference as small as possible.
It makes me wonder as well how accurate is the time stamp of each sensor. I mean con I relly on it, or is it better to use an event for synchronization?
Good idea to use an event to sync, that's a great way to go.
There's always going to be latency in the BLE so that epoch will never be perfect but thats ok. The error rate is low/minimal and you can do some post processing to minimize it.