Revision history [back]

These time stamps are strange indeed. Keep in mind that the format is "nanoseconds since the epoch (1970-01-01), so your time stamps correspond to Tuesday, March 23, 2060. It's a bagfile from the future!

Apart from that, the difference between samples varies between 0.010999808 s and 0.029000192 s; it's not a totally fixed sampling time, but the absolute difference is not that big (0.02 s). Without knowing which IMU driver you used to record this data, it's hard to be specific, but my guess is that the IMU driver timestamps the messages on the PC instead of using the time stamp from the IMU (if there is one). Either the IMU really has a irregular sampling time, or (more likely) the variations are caused by USB jitter, delays in processing the data etc. If you know for sure that the IMU's sampling rate is more regular, this should be fixed in the driver.

These time stamps are strange indeed. Keep in mind that the format is "nanoseconds since the epoch (1970-01-01), (1970-01-01)", so your time stamps correspond to Tuesday, March 23, 2060. It's a bagfile from the future!

Apart from that, the difference between samples varies between 0.010999808 s and 0.029000192 s; it's not a totally fixed sampling time, but the absolute difference is not that big (0.02 s). Without knowing which IMU driver you used to record this data, it's hard to be specific, but my guess is that the IMU driver timestamps the messages on the PC instead of using the time stamp from the IMU (if there is one). Either the IMU really has a irregular sampling time, or (more likely) the variations are caused by USB jitter, delays in processing the data etc. If you know for sure that the IMU's sampling rate is more regular, this should be fixed in the driver.

These time stamps are strange indeed. Keep in mind that the format is "nanoseconds since the epoch (1970-01-01)", so your time stamps correspond to Tuesday, March 23, 2060. It's a bagfile from the future!

Apart from that, the difference between samples varies between 0.010999808 0.011 s and 0.029000192 0.029 s; it's not a totally fixed sampling time, but the absolute difference is not that big (0.02 s). Without knowing which IMU driver you used to record this data, it's hard to be specific, but my guess is that the IMU driver timestamps the messages on the PC instead of using the time stamp from the IMU (if there is one). Either the IMU really has a irregular sampling time, or (more likely) the variations are caused by USB jitter, delays in processing the data etc. If you know for sure that the IMU's sampling rate is more regular, this should be fixed in the driver.

These time stamps are strange indeed. Keep in mind that the format is "nanoseconds since the epoch (1970-01-01)", so your time stamps correspond to Tuesday, March 23, 2060. It's a bagfile from the future!

Apart from that, the difference between samples varies between 0.011 s and 0.029 s; it's not a totally fixed sampling time, but the absolute difference is not that big (0.02 s). Without knowing which IMU driver you used to record this data, it's hard to be specific, but my guess is that the IMU driver timestamps the messages on the PC instead of using the time stamp from the IMU (if there is one). Either the IMU really has a irregular sampling time, or (more likely) the variations are caused by USB jitter, delays in processing the data etc. If you know for sure that the IMU's sampling rate is more regular, this should be fixed in the driver.

Update: Thanks for the additional details.

Actually the zeros at the end of each time stamp is an indication that the driver some how is rounding the sample time.

Yes, it's rounding the sample time to milliseconds, but do you really need a higher resolution?

Regarding your original question about the non-fixed sample time: The driver is doing the best it can to publish the correct time, and there is simply a bit of variation. That's compounded by the fact that the driver has to combine three different sensor readings (with different time stamps) into one message (with only one time stamp). Does your application really require accuracy > 0.02 s?

Regarding the wrong timestamp: Since your timestamp is almost exactly twice the actual value, I suspect that ImuPublisher.java#L173-L175 are responsible. The code assumes that event.timestamp is in nanoseconds of uptime, but some devices (e.g., the Nexus 4) instead put the exact timestamp (since 1970-01-01) in there. You could open a new issue, but I'm not sure whether android_sensors_driver is still actively maintained.