Synchronization of multiple MMR
I used the MetaBase App to measure linear acceleration of two MMR that I taped back to back so that they should collect the same data.
At this point in the collection I threw the coupled MMRs into the air and caught them again to get a sharp signal. According to the data, the peaks in the z-acceleration (however are 176ms apart (which is a huge difference at 100Hz).
Here are the respective entries from the exported csv-files:
1571161675387,2019-10-15T19:47:55.387,14.340,-0.078,-1.028,-0.178
1571161675397,2019-10-15T19:47:55.397,14.350,-0.034,-1.037,-0.314
1571161675407,2019-10-15T19:47:55.407,14.360,-0.000,-1.032,-0.450
1571161675417,2019-10-15T19:47:55.417,14.370,0.016,-1.006,-0.595
1571161675427,2019-10-15T19:47:55.427,14.380,0.048,-1.084,-0.708
1571161675437,2019-10-15T19:47:55.437,14.390,7.281,-7.835,-9.310
1571161675447,2019-10-15T19:47:55.447,14.400,5.220,-0.430,-7.853
1571161675457,2019-10-15T19:47:55.457,14.410,-4.835,1.835,2.412
1571161675467,2019-10-15T19:47:55.467,14.420,0.449,-3.537,0.263
1571161675477,2019-10-15T19:47:55.477,14.430,2.022,-1.069,-2.334
1571161675487,2019-10-15T19:47:55.487,14.440,1.429,1.056,-1.575
1571161675497,2019-10-15T19:47:55.497,14.450,1.270,0.255,-1.086
1571161675507,2019-10-15T19:47:55.507,14.460,0.877,0.134,-1.072
and
1571161675563,2019-10-15T19:47:55.563,14.510,-0.842,-0.150,-0.224
1571161675573,2019-10-15T19:47:55.573,14.520,-0.837,-0.112,-0.335
1571161675583,2019-10-15T19:47:55.583,14.530,-0.812,-0.085,-0.451
1571161675593,2019-10-15T19:47:55.593,14.540,-0.801,0.024,-0.511
1571161675603,2019-10-15T19:47:55.603,14.550,0.638,0.734,1.083
1571161675613,2019-10-15T19:47:55.613,14.560,7.290,-7.133,10.801
1571161675623,2019-10-15T19:47:55.623,14.570,-3.422,-1.697,-1.054
1571161675633,2019-10-15T19:47:55.633,14.580,-4.061,6.737,-8.721
1571161675643,2019-10-15T19:47:55.643,14.590,2.023,-1.737,-1.084
1571161675653,2019-10-15T19:47:55.653,14.600,0.253,-1.331,0.539
1571161675663,2019-10-15T19:47:55.663,14.610,-1.436,-0.281,-0.191
1571161675673,2019-10-15T19:47:55.673,14.620,-0.942,-0.385,-0.825
1571161675683,2019-10-15T19:47:55.683,14.630,-0.543,0.300,-0.523
(values at peaks have different signs as I taped them back-to-back, one graph is therefore also inverted).
Synchronized values is essential for using the sensors so I wonder what is going on and how this can be improved.
I of course had a look at the tutorials (https://mbientlab.com/tutorials/Topology.html?highlight=multiple#synchronizing-multiple-datasets-in-excel) but this approach does not work here as the shift between the two datasets is around 20 samples.
Strange enough, but the offset is not even constant over the collection:
This is quite early in the capture and here, the offset is 'only' 66ms:
1571161666247,2019-10-15T19:47:46.247,5.200,-2.282,1.066,-0.320
1571161666257,2019-10-15T19:47:46.257,5.210,-2.623,1.623,-0.207
1571161666267,2019-10-15T19:47:46.267,5.220,-3.265,2.462,0.261
1571161666277,2019-10-15T19:47:46.277,5.230,-4.096,3.721,1.280
1571161666287,2019-10-15T19:47:46.287,5.240,-4.597,4.821,2.322
1571161666297,2019-10-15T19:47:46.297,5.250,-5.064,5.172,2.225
1571161666307,2019-10-15T19:47:46.307,5.260,-5.780,4.209,1.581
1571161666317,2019-10-15T19:47:46.317,5.270,-7.347,1.711,0.537
1571161666327,2019-10-15T19:47:46.327,5.280,-8.996,-0.378,-0.914
1571161666337,2019-10-15T19:47:46.337,5.290,-9.433,-2.185,-1.667
1571161666347,2019-10-15T19:47:46.347,5.300,-8.642,-4.168,-1.272
and
1571161666303,2019-10-15T19:47:46.303,5.250,-1.397,2.372,-1.467
1571161666313,2019-10-15T19:47:46.313,5.260,-1.817,2.850,-1.593
1571161666323,2019-10-15T19:47:46.323,5.270,-2.581,3.533,-1.977
1571161666333,2019-10-15T19:47:46.333,5.280,-3.930,4.588,-3.026
1571161666343,2019-10-15T19:47:46.343,5.290,-5.561,5.600,-4.256
1571161666353,2019-10-15T19:47:46.353,5.300,-6.028,6.493,-4.437
1571161666363,2019-10-15T19:47:46.363,5.310,-4.666,7.331,-3.354
1571161666373,2019-10-15T19:47:46.373,5.320,-1.567,8.568,-2.022
1571161666383,2019-10-15T19:47:46.383,5.330,1.151,9.570,-1.050
1571161666393,2019-10-15T19:47:46.393,5.340,2.895,9.319,-0.699
1571161666403,2019-10-15T19:47:46.403,5.350,4.405,8.538,-1.202
1571161666413,2019-10-15T19:47:46.413,5.360,5.995,6.572,-1.350
This means that these files cannot be synchronized by looking at the timestamps. It looks as if the clocks are drifting. I'm recording on a Galaxy S7 and the MMR have version 1.4.4 (can't upgrade with my Smartphone...) and are new (received them last week).
Comments
Any updates on this issue?
Drifting happens. This is the real world.
@FooTheBar, I am surprised that you would be seeing clock drift over such a short interval of time. Were both data captures from the same session? The clock uncertainty between two devices will be different after starting and stopping a recording.
Be certain that time and not sample count is used as the x axis during analysis -- the sensors operate on internal clocks with more frequency deviation than the logger and handset clocks.
If the time base is truly operating at a different rate, the time base would need to be scaled for the data to show strong correlation over a long period of time.
"Drifting happens. This is the real world."
You advertise your product as
"Synchronized timestamp: Supports multiple devices simultaneously"
So you are simply lying to your customers? And after they find out, you mock them? 100ms error within minutes is not 'the real world', it's simply a bug. And if you promise synchronized timestamps, you have to provide a synchronization method.
You are an engineer, so you definitely know that a drift of 100ms within 9 seconds is definitely not 'the real world' but a bug. So please stop to treat my like an idiot. This would be more than 1% error.
I can't guarantee that my analysis is correct, but that I provided the raw data that your app generated.
@Matt:
I'm using the provided MetaBase App. I used the time as x-axis and the error is clearly visible in the raw data. How is the synchronization between multiple devices implemented?
I just had a look at the data sheet and found the Oscillator specifications (6.2 OSC):
https://mbientlab.com/documents/MetaMotionR-PS3.pdf
By looking at the schematics (https://mbientlab.com/documents/MetaMotionR_0.3.pdf), I guess it's the X2-component attached at XC1 and XC2 and used at 32MHz. At this frequency it has a tolerance of 40ppm which would explain a drift of up to 0.4ms in a 10 seconds frame (10000ms*40.0/10**6=0.4ms). The observed drift of 100ms in around 9 seconds is 250 times that high.
Is there any other experiment I could run?
I did not find anything about the synchronization of the devices in the libraries. Could someone maybe tell me how the synchronization is implemented? Is there a way to get the current offset between the devices?
@FooTheBar are you logging or streaming?
The logging system records entries using the internal device clock. At the start of log readout, the present state of the device clock is tagged against real world (smartphone) time. As they are read out, the relative time (as recorded internally) of logged events is adjusted to real world time. The accuracy of synchronization is subject to radio link latency.
If you would like a better experiment to run, I would suggest using raw accelerometer data. Linear acceleration is a computed, sensor fusion output. The data models used in sensor fusion may be adding additional error to your measurements.
That is pitty! We wished to have 2-3 sensors getting raw data at 200 Hz each, with strict sync specs, 5 ms max difference. Is this delay random or constant within a connection?
@Matt if I read here http://lup.lub.lu.se/luur/download?func=downloadFile&recordOId=8884959&fileOId=8884963
the way you described your technique, that seems to be Reference Broadcast Synchronization (RBS). In the article, they are able to reach between-sensors time differences < 30 us (Table 4.1). This because the broadcast reference time message is supposed to be negligible, and equal for each sensor.
Am I correct?
My BLE knowledge is only theoretical so far though
@u0078867 yes, this technique is most similar to RBS as described. Retrieving the sensor clock value requires a BLE write and notify cycle which adds additional uncertainty to the clock synchronization.
Ok, thanks for the answer. Does the firmware implement clock drift compensation?
Hello, I am new to MMR, any solution about the Synchronization of multiple MMR? Thanks
All data is provided with a timestamp which you can use to sync the data. Please see our tutorials regarding this subject.
I am very interested in the synchronization topic. @Laura, could you please be more specific, which specific tutorial are you referring to?
All the sensor is timestamped with an epoch so you can use that to sync them.