Without knowing the sample rate, it is not possible to calculate time-dependent properties.
It's not ideal, but you have the start time, end time, and the sample count. You can calculate the sample rate using all of them
Oh, nice! That should suffice then. I didn't see anything about these properties in the docs but I guess they are attributes of AnalogData?
EDIT: Fixed my silly bug...
Original text: gist.github.com/jonathangjertsen/a2fe912dd3403bd317359fcd7531ddc7 This measurement always outputs 33.339ms for the duration (and a garbage sample rate as a result). What am I missing?
Is process_data() guaranteed to be called in chronological order such that the above gist will always work?
No, wait, the problem is still there if I do a measurement that's shorter than 33.3 ms. And even for longer measurements, the calculated sample rate is being underestimated (it converges to the correct sample rate when the measurement duration is increased). The duration seem to be quantized to multiples of 33.3ms, I guess that is the size of one chunk? Are you sure the timestamps are being correctly adjusted to the measurement range?
This might be the size of a single chunk, what sample rate are you using btw?
3.125 MHz, but I still get roughly 33-34 ms when using 781.25 kHz, or 50 MHz.
We'll look into this and keep you posted