What is the accuracy and stability of the sampling clocks in MetaMotionR - modules ? This is important in the light of synchronising two or three MetaMotion's data over the measurement period, which can be as long as 4 hours.
@Timo_at_Myontec the low frequency clock on MMR is 250ppm typical, 500ppm worst case. It is trimmed against the high frequency crystal, and retrimmed if the temperature changes more than 2 degrees. This only applies if you are using the logging system. The IMU has its own internal clock which determines its sampling rate. If your application is partially online, you can sync the sensor clock with a master's clock many times over the measurement period.
@Matt said: @Timo_at_Myontec the low frequency clock on MMR is 250ppm typical, 500ppm worst case. It is trimmed against the high frequency crystal, and retrimmed if the temperature changes more than 2 degrees. This only applies if you are using the logging system. The IMU has its own internal clock which determines its sampling rate. If your application is partially online, you can sync the sensor clock with a master's clock many times over the measurement period.
I developed a Python application that is running on Linux (Raspberry Pi board) with a BLW dongle and two MetationR devices. Can I sync the sensor clock of the two MMR with clock of the Raspberry PI (master clock)? If yes, what Python API are available?
The clock doesn't get "synced" until the data is downloaded. The MMR itself has no concept of "WORLD TIME", just a very accurate crystal that it uses to COUNT.
As soon as you start logging, the COUNTER starts.
Then when you finally stop logging and download the data, it uses that COUNTER's current value and works its way backwards from the current WORLD TIME to determine TIME (ie epoch).
REALLY SIMPLE EXAMPLE:
counter = 0, acc data = x,y,z
....
....
counter = 24800, acc data = x,y,z
we know the time between counter counts is .1ms so between the time you started logging and the time you stopped logging it's been 24800*1ms. We also know it's currently April 8th at 9:42:10AM.
So now:
counter = 0, acc data = x,y,z, timestamp = April 8th at 9:42:2520 AM.
....
....
counter = 24800, acc data = x,y,z, timestamp = April 8th at 9:42:5000 AM.
What Matt was referring to is that you can get the current count from the MMS anytime you want and keep it as a reference point for when you download data. You can do this in Python: mbl_mw_logging_get_time_data_signal()
You can also take a look at this: mbl_mw_logging_set_reference_time(). Again this is done in software, not in firmware (the MMR has no references to a WORLD TIME at all).
Comments
@Timo_at_Myontec the low frequency clock on MMR is 250ppm typical, 500ppm worst case. It is trimmed against the high frequency crystal, and retrimmed if the temperature changes more than 2 degrees. This only applies if you are using the logging system. The IMU has its own internal clock which determines its sampling rate. If your application is partially online, you can sync the sensor clock with a master's clock many times over the measurement period.
I developed a Python application that is running on Linux (Raspberry Pi board) with a BLW dongle and two MetationR devices. Can I sync the sensor clock of the two MMR with clock of the Raspberry PI (master clock)? If yes, what Python API are available?
Thank you.
The clock doesn't get "synced" until the data is downloaded. The MMR itself has no concept of "WORLD TIME", just a very accurate crystal that it uses to COUNT.
As soon as you start logging, the COUNTER starts.
Then when you finally stop logging and download the data, it uses that COUNTER's current value and works its way backwards from the current WORLD TIME to determine TIME (ie epoch).
REALLY SIMPLE EXAMPLE:
counter = 0, acc data = x,y,z
....
....
counter = 24800, acc data = x,y,z
we know the time between counter counts is .1ms so between the time you started logging and the time you stopped logging it's been 24800*1ms. We also know it's currently April 8th at 9:42:10AM.
So now:
counter = 0, acc data = x,y,z, timestamp = April 8th at 9:42:2520 AM.
....
....
counter = 24800, acc data = x,y,z, timestamp = April 8th at 9:42:5000 AM.
If you are curious, you can read the code here (it is in our CPP library and not in Python): https://github.com/mbientlab/MetaWear-SDK-Cpp/blob/master/src/metawear/core/cpp/logging.cpp
What Matt was referring to is that you can get the current count from the MMS anytime you want and keep it as a reference point for when you download data. You can do this in Python: mbl_mw_logging_get_time_data_signal()
You can also take a look at this: mbl_mw_logging_set_reference_time(). Again this is done in software, not in firmware (the MMR has no references to a WORLD TIME at all).