Hi GregS and Ville,
Greg – sorry my original answer here was very short. I didn’t dig in to this as much as I should have and was going off numbers on the top of my head. The logging feature was designed with long intervals (seconds or minutes) in mind, so these high speed logging scenarios are not something I think a lot about.
I am still of the belief that 125Hz logging to SD card is possible but haven’t tried it myself in a while, I have a memory of making a log at this speed as a test a few firmware versions ago.
Regarding logging faster when phone disconnected: yes this is what I expected to see, but not as drastically as you’re seeing it. Ville’s description of how the meter works is correct – there’s one little processor juggling all the tasks.
Actually, as I think this through, what I believe may be happening is an interaction between the sampling thread, the SD card writing thread, and a design decision I made to make the UI cleaner. If the sampling thread misses several samples in a row because of interruption, it pitches the data buffer and starts over again. I asked you to set it to 4000Hz, 32 samples instead of 125Hz, 1 sample because I eliminated the option for setting such low buffer depths on an earlier version of firmware, as it was not useful to the vast majority of users and was causing confusion. But my suspicion is that at 4000Hz, the interleaved writing-to-SD thread is causing the sampling thread to miss samples and forcing it to restart itself several times before a buffer gets written to memory.
As a test, could you try logging on 2000Hz 32 samples, or 1000Hz 32samples? My suspicion is that one of those will give you a sample rate much closer to what you’d expect (60Hz or 30Hz). If that’s the case I will evaluate re-adding the lower buffer depth options to the user interface.
Ville: Thanks for the accurate description of the meter’s function and recommendations on documentation :)
I hope this helps, thanks