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!

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 !!

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?

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.