Reliability of Sampling Rate vs Absolute Timestamps

Question

I am building a system with multiple sensors and I want to sample the different sensors at different rates. For the sake of an example, I am using two MAX30102EFD-T sensors. One of the sensors I want to run at 50Hz and the other I want to sample at 1000 Hz. I have the ability to configure this sampling rate (samples per second) on the sensor and when each sensor has a new sample (supposedly at these frequencies), in the interrupt I can record this sensor value (and optionally record a timestamp like the number of milliseconds since boot.

As an example:

TIMESTAMP SENSOR VALUE
0         1      1.2
0         2      0.1
1         1      1.3
2         1      1.4
3         1      1.5
...

The issue is that storing timestamps along with the time series from both sensors can add significantly to the output file size. If the sampling rate of these sensors is reliable enough, I could just record the initial timestamp and the sampling rate and assume uniform sampling, but I'm hesitant to trust these types of sensors to have that uniform and accurate of a sampling rate. Is that distrust warranted in general?

I'm curious if anyone has any experience with such a thing and was interested to see if there was a robust approach short of storing timestamps for each sensor alongside the data.

Answer 1

If the sampling rate of these sensors is reliable enough, I could just record the initial timestamp and the sampling rate and assume uniform sampling

I spent 30 seconds looking at the datasheet (Ctrl-F "Frequency") and, well, it doesn't have an onboard crystal oscillator, so the internal clock is pretty inaccurate, and it will drift.

Therefore, using your microcontroller to create timestamps seems reasonable. So there are two isuses: the absolute accuracy of the timestamps given by your microcontroller, and the synchronization between both sensors. If all you care about is knowing when a sample from the first sensor was acquired relative to the sample from the other sensor, so your 50 Hz and your 1000 Hz line up, then the accuracy or drift of the timestamps from the microcontroller clock isn't that important, because if it drifts, then the timestamps for both sensors will be affected equally, and the order of samples will still be the same.

If you want to know the sample was acquired on monday at 12:01:00 to the microsecond, then it's another problem.

The issue is that storing timestamps along with the time series from both sensors can add significantly to the output file size.

Not really, you can compress it like time series databases do : by storing deltas. For example if you expect one sample every millisecond, and your timestamps are based on a 10MHz clock, then you store the first timestamp as a 32 bit value, then you store the difference between timestamps. And since that difference will always be close to 10000 (10MHz/1kHz) you can store deltas of deltas. This should get you down to 1 byte per timestamp.

It would probably be simpler to not use the free-running mode in the sensors and just run a 1ms timer in your micro, so you know the 1kHz sensor is synrhronized to the micro's internal clock, which presumably comes from an accurate crystal. Then every 20 samples, request a sample from the 50Hz sensor. Then you can be sure both sensors sampling times line up.