BMI088 Streaming timestamps are counting slow.

[Chris89]

We have implemented the interrupt-streaming-pc example from here https://github.com/BoschSensortec/BMI08x-Sensor-API/blob/master/examples/interrupt_streaming_pc/inte...

We are using the BMI088 and the version 3 dev board.

We have both the accelerometer and the gyro configured with ODR's of 200 Hz.

The timestamps being reported are counting slow, by a factor of ~ 2X. E.g. it takes ~ 10 seconds to record 5 seconds of data with respect to the reported time stamps.

Example time stamps from a block of 6 valid samples:

valid sample count: 6

time stamps: 3073012389
time stamps: 3073015034
time stamps: 3073017702
time stamps: 3073020324
time stamps: 3073022980
time stamps: 3073025644

Time delta between the final two samples is 0.00266, where it should be closer to 0.005 for a sample rate of 200 Hz.

The timestamps are calculated as: 48bit_timstamp / 30. Is the factor of 30 correct for the BMI088? 

Something is clearly not being converted correctly as the delta between timestamps are out by a factor of ~2, but it takes approx twice as long to get a 5 second recording implying that the data is sampled at the correct rate, but the timestamps themselves are incorrect. 

Any idea what we could be doing wrong?

[FAE_CA1]

Hi,

Thanks for your inquiry.

BMI088 time stamp is 24-bit with 39.0625us each digit. It has three bytes 0x1A|0x19|0x18 to get max 16,777,216 LSBs and then it will roll over from 0 again. It is a free runner clock after BMI088 is powered on and it is not related to ODR setting. This is similar to Arduino millis() function. Therefore, after you get delta from the two time stamp values, you can simply multiply the delta by 39.0625us to get the timing.

Thanks.

[Chris89]

Thank you for your reponse,

When looking at the example (see screen shot below from https://github.com/BoschSensortec/BMI08x-Sensor-API/blob/master/examples/interrupt_streaming_pc/inte...), as well as the COINES User Manual Section 5.7 we can see that the packet returned contains a 48-bit time stamp which is enabled using the coines function:  `coines_trigger_timer(COINES_TIMER_START, COINES_TIMESTAMP_ENABLE);` - This allows for 1 timestamp per stream value. It indeed does return timestamps which are monotonically ascending, so the 48 bits do contain something sensible, it's just that we seem to be scaling the output incorrectly. So is the method provided in the example code the correct method to obtain a timestamp per sample in streaming mode?

Ultimately we wish to stream both accelerometer and gyroscope data with accurate timestamps per sample at 200 Hz, preferably with the accelerometer and gyroscope being synchronised. 

[FAE_CA1]

Hi,

Let me check and then get back to you. Thanks.

[FAE_CA1]

Hi,

The 48-bit time stamps in example code "interrupt_streaming_pc.c" are not from our sensor BMI088. The 48-bit time stamps come from the MCU timer on the APP base board.

If you would like to get timing value of our sensor, please use function "bmi08a_get_sensor_time" in "bmi08a.c", and each digit corresponds to 39.0625us as described in BMI088 datasheet.

Thanks.