Repository navigation
fix(ble): share sensor queue capacity proportionally under load - #313
Closed
TobiasRoeddiger wants to merge 11 commits into
Closed
TobiasRoeddiger wants to merge 11 commits into
TobiasRoeddiger wants to merge 11 commits into
Conversation
✅ Unit tests passed2 passed, 0 failed/error, 0 skipped — view workflow run
Download the |
|
Build output available: |
Compiler warningsThe extended-warning build completed successfully. Application compiler warningsNone. |
CodeChecker static analysis✅ No non-style issues found. |
|
Build output available: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bursty sensor publications compete for one BLE queue. Under overload, FIFO eviction disproportionately loses PPG samples even when other sensors retain much more of their input. For example, the isolated 32-entry reference delivered 8.8% of the right earphone’s offered PPG samples during playback, versus roughly 17–19% for its other sensors.
Use a shared bounded queue that compares recent delivered/offered sample fractions. Send the least represented sensor first; on overflow, discard the oldest queued publication from the most represented sensor. Count samples using the existing sensor schemes, retain publication order within each sensor, and decay history so rate changes are handled. This changes queue scheduling only.
Stacked on #312, whose current base already contains #308. Both changes are needed for a short, fair backlog; a smaller FIFO alone does not solve the imbalance. No sensor rates, wire format, radio parameters or audio codec settings are changed by this PR.
The queue policy was tested independently at the same 32-entry capacity on the pre-batching
db71350ebase before tuning capacity. Both earphones were a native LEAudio pair on one Pixel 9a, with all five advertised BLE maximum settings. Each capture lasted 45 seconds after warm-up. Fractions use actual samples offered to the BLE queue; acquisition shortfalls are not counted as BLE loss. Counter and phone windows differ slightly, so percentages are approximate.All captures retained all five streams with valid finite payloads. Quiet measurement windows had zero additional output-underrun blocks. Different connections can allocate airtime differently between ears; these fairness results are per ear, not a claim of equal left/right bandwidth or universally higher total throughput.
The default is now 32 entries in #312, allowing more transient buffering than 16. Earlier fixed-connection sizing comparisons found little sustained-throughput benefit at 32 and generally fresher readings at 16, but did not establish that 16 minimizes loss during temporary BLE stalls. Thirty-two trades some data age for additional recovery headroom; it does not solve sustained overload. The isolated policy comparison above already used 32 entries.
Earlier clean combined confirmation at 16 entries (
2.2.10+ #308 + #309 + #312 + this scheduling policy):Both earphones remained a native LEAudio pair on one Pixel 9a. All five sensors used their advertised BLE maxima: IMU 100 Hz, PPG 512 Hz, bone 800 Hz, optical temperature 64 Hz, and pressure/temperature 200 Hz. Clean confirmation captures lasted 45 seconds after warm-up, with independent raw-packet decoding, all five streams, no malformed packets and no nonfinite values. Payload rates exclude packet headers. Data ages are estimates from clock probes, not display latency. Counter observations span the initial measurement read through the post-capture snapshot; that interval is slightly longer than the packet window. No debugger access occurred between those observations.
At the earlier 16-entry revision, both pristine build variants passed. At that revision, native Zephyr/Unity tests covered overflow freshness and metadata, purge/reset, bursty sensor fairness at several service rates, changing input rates, invalid input and initialization from nonzero memory. The final combined hardware source is
8c79a36b; its application source matched the earlier 16-entry PR revision; the current queue default is 32. The combined image also uses the separate radio-core configuration. Both pristine build variants also passed on the earlier PR source835db39c. No measurement-only counters or runtime tuning controls are included.Separate digital playback spot checks on the final combined image passed with playback alone and simultaneous audio: eight coherent 20 ms windows per ear, expected channel tones, no silent windows or full-scale clipping, and tone-fit R² ≥ 0.99. Each earphone’s microphone ISO sequence advanced at approximately 100 frames/s during the simultaneous-audio check; the phone received nonzero PCM. These checks do not certify acoustic speaker output or microphone fidelity. Earlier microphone-only output-counter increases in the actual app remain documented separately; quiet collector results do not resolve their cause.
Retained setup failures: an initial combined microphone-only attempt stalled before notification setup completed; a collector-only descriptor submission check/retry was added, and the repeated case passed. Separately, the freshness-only current-base image had one right-ear Bluetooth timeout during simultaneous-audio startup; its two repeats passed. These failed attempts are excluded from the completed-capture tables and remain recorded; their causes are not established.
Earlier actual-app confirmation on the installed 16-entry combined image: both earphones stayed paired, with all five supported BLE maximum rates verified before and after every condition. The OpenWearables app displayed live sensor graphs during each 45-second video. Small timed counter reads occurred during capture; full snapshots were outside the video.
Graph changes are a pixel-based responsiveness check, not source-to-screen latency. Playback recorded four additional 1 ms output-underrun blocks on the right. Simultaneous audio recorded five on the right during the timed observations; the wider before/after interval also included one on the left. Their causes are unresolved. The quiet combined collector captures had no additional blocks, so these app observations must not be described as universally glitch-free audio. The microphone-only and simultaneous app captures delivered nonzero phone PCM, with both earphone microphone sequences progressing at about 100 frames/s. These observations do not certify acoustic output or microphone fidelity.
32-entry update: merged the capacity change from #312 while retaining the existing scheduling diff. A pristine standard build passed on
e1026e18, with generated capacity verified as 32. The earlier measurements above remain historical results, not a new hardware run.