@Emil said in Accelerometer streaming rate is 2x faster than configured (Flic Duo):

could you post your full configuration?

Sure! Here's the full AccelerometerStreamingConfig used in both test cases (Android SDK), field by field:

lowPowerMode = 0 mode = 0 outputDataRate = 1 // 1.6Hz (LIS2DW12 table 29) bandwidthFilter = 0 fullScaleSelection = 1 // ±4G filterDatatypeSelection = 0 // low-pass lowNoise = true highPassRefMode = false samplesPerBurst = 8 (or 2 in the second test — everything else identical) onlyWhilePressed = false

I also re-ran the samplesPerBurst = 8 case with lowNoise = false and got an identical result (same burst size, same timing), so that parameter doesn't seem to be the cause. Everything else (lowPowerMode, mode, bandwidthFilter, filterDatatypeSelection, onlyWhilePressed) was left at the most conservative/default value in both tests. Full-scale was ±4G in both cases.

Hi all,

I'm using AccelerometerStreamingConfig on a Flic Duo button (Android SDK) with outputDataRate = 1, which the javadoc says maps to 1.6Hz per the LIS2DW12 datasheet, table 29. But when I measure the actual data arriving over BLE, it consistently comes in at about double that rate — and the burst size is also about 4x bigger than the samplesPerBurst value I requested.

Measured examples:

• samplesPerBurst = 8 requested → I receive bursts of 32 samples, about every 10.2s
• samplesPerBurst = 2 requested → I receive bursts of 8 samples, about every 2.55s

Both cases work out to ~3.14 samples/second delivered — exactly double 1.6Hz, regardless of the requested burst size.
I tried toggling lowNoise (true/false) and got identical results either way, so that doesn't seem to be the cause.
Is this expected behavior? Is there some other parameter (lowPowerMode, mode, bandwidthFilter?) that affects the actual delivery rate independently of outputDataRate, or is there a known firmware reason the button delivers roughly double the configured rate? Any insight would be appreciated.

Thanks!