Accelerometer streaming rate is 2x faster than configured (Flic Duo)

estebanvalverde67

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!

Emil

@estebanvalverde67 Please try the new 2.1.1 version of the sdk.

estebanvalverde67

Hi,

Following up on your question about a duplicate listener - you were right to ask. We found and fixed a real bug on our side, and the mystery is resolved.

Root cause: our test phone had more than one Flic button paired (from earlier testing). Our code guarded against re-registering a listener on the same button by comparing against a single "last processed button" variable. Since the list of known buttons gets iterated twice, through two separate code paths, the second pass would reach an already-registered button again - but by then that single-value guard had already moved on to a different button in the list, so the comparison no longer matched, and the listener got registered a second time on that same physical button.

We confirmed this precisely by tagging each registered listener instance with an incrementing ID and logging it on every callback: two different listener instances (not one instance firing twice) were both receiving every accelerometer burst.

We fixed it (now tracking a set of already-registered button addresses instead of a single last-seen button) and re-ran the exact same test as before (outputDataRate=1, samplesPerBurst=8). With the duplicate registration gone, we now see exactly 16 samples every ~10 seconds - matching your own measurement exactly. No rate doubling at all. The only real discrepancy left is the x2 size you already confirmed and are fixing in the packet writer.

Sorry for the noise, and thanks for pointing us in the right direction. One small, low-priority thing we noticed while re-testing: those 16 samples still arrive split across several small packets (e.g. eight 1-sample bursts, one 3-sample, one 5-sample) instead of a single 16-sample packet. Doesn't affect the total count or rate, just how they're spaced out - not urgent, just mentioning it in case it's a known/expected detail on your end.

Thanks again!

estebanvalverde67

Good catch - we actually found and fixed a real bug on our side: our button listener registration was comparing Flic2Button objects by reference (===) instead of by bdAddr, and the SDK appears to sometimes hand back a different object instance for the same physical button depending on the code path (reconnect on service start vs. re-init after binding). That allowed addListener() to be called twice in some cases.

We fixed that (now comparing by bdAddr) and re-tested with the exact same config as before (outputDataRate=1, samplesPerBurst=8). However, the duplication is still there even with registration now guaranteed to happen exactly once:

onReady still fires twice, ~5ms apart, on the very first connection after a fresh install/launch.
Every onAccelerometerStreamingData burst still arrives as an identical pair (same sample count, same or ~1ms-apart timestamp) - e.g. 3 samples immediately followed by another 3 samples, then 5 samples followed by another 5 samples.

Given the ~5ms gap on onReady is far too tight to be explained by our own app code (two independent code paths racing would typically be tens-hundreds of ms apart, not 5ms), this looks like it's happening below our listener - either in the SDK's internal event dispatch or in how the button/BLE stack delivers the notification. Does that match anything you're aware of on your end?

Full config used (unchanged from before):

lowPowerMode = 0
mode = 0
outputDataRate = 1 // 1.6Hz
bandwidthFilter = 0
fullScaleSelection = 1 // +/-4G
filterDatatypeSelection = 0
lowNoise = true
highPassRefMode = false
samplesPerBurst = 8
onlyWhilePressed = false

Thanks in advance !!

Emil

@estebanvalverde67 When testing this:

button.enableAccelerometerStreaming(new AccelerometerStreamingConfig(0, 0, 1, 0, 1, 0, true, false, 8, false), new EnableAccelerometerStreamingCallback() { ... });

I notice that the samplesPerBurst is wrong by a factor 2x (this is due to a bug in the packet writer, which will be fixed), but not by the factor 4, nor that the sample rate of delivered events is doubled. That is, I see 16 samples arrive every 10 seconds. With 8 replaced by 2 above, I see 4 samples arrive every 2.5 seconds. Can you confirm this? Maybe you have registered a listener twice or something?

estebanvalverde67

@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.

Emil

@estebanvalverde67 hmm could you post your full configuration?