问题
Based on the response on this question here: What are The Unit of measurement and extrapolating, it seems that when reading the timestamps from the imu datasource (imu9), the timestamp may not be coming from the base system, but rather from some other source. Is this the case?
As an aside, has anyone had any luck syncing the time on the devices to an external device, like an ios or android device? I know the time can be set, but it always seems like I'm about a second off. Would this possibly be a function of how many ble packet sends it takes to actually send the time value over, and then process it, and return a response? If so, is there possibly a way to quantify what that time differential is?
回答1:
The Movesense sensor has one clock source (32kHz 20ppm crystal stabilized low-frequency tick counter) which runs at 1024 ticks/second. From there the "RelativeTime" [ms] is calculated (ms since reset). RelativeTime is returned as timestamp from many sensor measurements and is based on the xtal stabilized clock, so it is stable. Since especially the IMU unit (Acc/Gyro/Magn) sampling is timed by the LSM6DSL's internal RC oscillator, the diff of timestamps can vary and the real samplerate is +-10% of the nominal given in the subscription parameter. The ECG samples are accurate since that chip uses the clock signal from the stable oscillator.
The UTC clock is calculated with an offset to the RelativeTime. So internally the UTC clock is calculated in ms, while the API has microseconds in case there are future hardware with better capabilities.
When PUT /Time is performed, the sensor uses the given UTC time to calculate a new offset between the UTC clock and RelativeTime and takes it into use. The PUT request over BLE takes some time that can be estimated by PUT-GET round trip. If a more accurate setting is wanted one can use the CustomGATTService module (/Comm/Ble/GattSvc) to implement simpler time setting service that avoids all the MDS/Whiteboard protocol overhead. Typically BLE connection interval seems to be around 45ms-60ms, so that much delay is expected anyways.
The current published Movesense device lib does not offer a convenient way to find out the relation between UTC time and RelativeTime on the sensor. However the coming 1.7 release (due in few weeks) will have it and simplify multi-sensor synchronization.
Full disclosure: I work for the Movesense team
来源：https://stackoverflow.com/questions/51942289/movesense-timestamp-source-of-imu-data-and-timing-issues-in-general