imx93-jaguar-eink: Improv BLE advertising starved by Wi-Fi/BT coexistence when board is on Wi-Fi

[ajlennon]

Problem

On imx93-jaguar-eink, when the board is joined to Wi-Fi, the Improv BLE advertisement stops reliably reaching the air after a few minutes, while BlueZ still reports it as active (ActiveInstances=1). The device becomes effectively undiscoverable to the onboarding app even though nothing has crashed.

This is a Wi-Fi/BT coexistence effect on the shared radio, not a BlueZ registration drop (so the advertising watchdog added in #38 does not catch it — ActiveInstances stays 1).

Evidence (lab, target 25, board on GrosnyIoT)

Discoverability sampled every 30s from a separate scanner:

• Wi-Fi ON: discoverable for ~5 min, then mostly undiscoverable (rare blips) over the next 15 min. Board reports ActiveInstances=1 throughout; watchdog reads advertising=True.
• Wi-Fi OFF: 26/26 samples discoverable over 13 min, strong RSSI, zero drops.

So the primary factory-onboarding path (fresh, un-provisioned board = Wi-Fi off) is 100% reliable. The degradation only affects re-onboarding a board that is already on Wi-Fi.

Other observations:

• Advert survives connect/disconnect cleanly.
• Adapter power-cycle (bluetoothctl power off/on) and hciconfig hci0 reset do NOT restore on-air advertising from the stuck state; BlueZ auto-re-asserts registration but the radio stays starved.
• A full improv.service restart does restore it (takes ~20-40s).

Candidate mitigations to investigate

1. Set an explicit short LE advertising Min/Max interval so adverts survive coexistence gaps (BlueZ LEAdvertisement MinInterval/MaxInterval).
2. NXP combo coexistence / Wi-Fi power-save driver/firmware config (btnxpuart, moal/mlan).
3. Pragmatic belt-and-braces: periodic re-assert/bounce of advertising when idle (accepting brief gaps).

Notes

• Needs a firmware iteration + long (>15 min) soak per attempt; single-adapter scanners degrade under continuous scanning, so use a fresh/second scanner.
• Related hardening already merged/in-flight: python3-improv: self-healing BLE advertising watchdog (imx93-jaguar-eink) #38 (advertising watchdog + restart backstop).

[ajlennon]

Resolved — coexistence stall not reproducible on current firmware; watchdog is the fix for the real failure mode

Ran a controlled soak on the bench board (eink target 25 + the self-healing advertising watchdog from #38 / PR #38). To remove the biggest measurement confound, the board was driven over the serial console and adverts were measured from a separate host's Bluetooth — so zero Wi-Fi traffic was generated by the test harness itself (the board is Wi-Fi-only, so any SSH session competes with BLE on the shared antenna).

Method

• advmon: scan 6 s / sleep 24 s (30 s cadence), 24 samples per phase (~12 min), logging discoverable=True/False + RSSI.
• Board associated to a real AP; band forced via nmcli ... 802-11-wireless.band to test 2.4 GHz in-band coexistence.
• Traffic phases saturate Wi-Fi with a sustained stream to reproduce the earlier "active SSH session" condition.

Results — 96/96 samples discoverable, 0 misses

Phase	Band	Wi-Fi load	Discoverable	RSSI
A	5 GHz (ch149)	idle	24/24	-34…-42
B	5 GHz (ch149)	saturated	24/24	-35…-42
C	2.4 GHz (ch1)	idle	24/24	-35…-42
D	2.4 GHz (ch1)	saturated	24/24	-35…-42

Advertising stayed 100% discoverable in every condition, including 2.4 GHz in-band under saturation, and well past the ~5 min mark where degradation was previously seen.

Conclusion

The originally-reported on-air stall is not reproducible on the current firmware. The earlier observation is best explained by (a) the test harness's own active SSH session stealing shared-antenna airtime from BLE during measurement, and/or (b) a dirty BlueZ/advertisement state during hot-patch debugging that the watchdog + clean service start now prevent.

Board-state check while investigating: Wi-Fi power-save is already enabled (ps_mode=1, auto_ds=1, iw ... power_save on), so the "enable PS" lever was already pulled; per-advertisement interval tuning is unavailable on the shipped BlueZ 5.72 (needs ≥5.77) but is unnecessary given the above.

Resolution

• Watchdog (python3-improv: self-healing BLE advertising watchdog (imx93-jaguar-eink) #38) is the fix for the real risk here — a BlueZ advertisement registration drop / stack wedge — via timeout-bounded re-registration and a systemd-restart backstop.
• No invasive coexistence mitigations (scan suppression / interval tuning / driver coex tweaks) are needed at this time.

Reserve (only if a dense-RF field failure reappears)

• Antenna is shared; a very strong, busy 2.4 GHz AP adjacent to the board could still bite. My 2.4 GHz test was at weak signal (-87 dBm) with heavy-retransmit traffic (a fair airtime stress) but not a worst-case dense office.
• If it recurs in the field: engage NXP FAE on IW612 PTA priority / grant-rule tuning, and review antenna isolation. Keeping this closed; reopen with field evidence if needed.

Closing as completed.

[ajlennon]

Reopening — on-air advertising stall IS hit in practice (not just coexistence), and the watchdog misses it

While running a full fresh-boot Improv onboarding test (Wi-Fi connection removed, default-connections service masked, rebooted to a genuine un-provisioned state: NET=disconnected, no active Wi-Fi), I reproduced the exact failure this issue's watchdog was meant to guard against — but via a different trigger than coexistence:

What happened

1. Fresh boot, Wi-Fi disconnected, improv.service active, BlueZ ActiveInstances=1.
2. First BLE provision attempt from the host failed ("device not found / connection failed").
3. Afterwards the board was in the "ghost advertising" state: BlueZ still reported ActiveInstances=1, but the advertisement was not on-air — an independent BLE scanner (bleak) and the provisioning tool both saw nothing, repeatedly. Wi-Fi was OFF, so this is not coexistence.
4. The watchdog did not recover it — it only checks is_advertising()/ActiveInstances, which stayed 1, so it considered the stack healthy.
5. Recovery required a manual systemctl restart improv.service. After that, the advert was on-air again and provisioning succeeded on the second attempt (AUTHORIZED -> PROVISIONED, board joined Wi-Fi).

Why this matters

• This is the same "process healthy, ActiveInstances=1, advert silently gone" symptom originally reported here, now reproduced with Wi-Fi off, triggered by a failed BLE connect and/or fresh boot — i.e. it can strike a real onboarding unit, not just a provisioned board on Wi-Fi.
• In the field, a phone/app that fumbles the first connect could leave the board un-onboardable until a restart.

Correction to my earlier closure

My previous comment closed this as "coexistence not reproducible; watchdog handles the real risk." That was only half right: the registration-drop risk is handled, but the on-air stall (ActiveInstances=1 yet not radiating) is a genuine blind spot that is reachable in normal onboarding flow.

Proposed direction

Make the watchdog detect on-air stalls, not just registration drops. Candidates:

• Periodically bounce the advertisement (unregister/re-register) on an interval even when ActiveInstances=1.
• Re-initialise advertising whenever a central connect fails/aborts (not just on clean disconnect).
• Optional board self-scan to confirm its own advert is actually on-air.

Investigating the improv server's connect/disconnect + advertising handling now.

Caveat: I confirmed ActiveInstances=1 over serial right after the fresh boot but did not scan for the advert before the first provision attempt, so I can't fully separate "stalled at boot" from "stalled by the failed connect". Either way it is real and the watchdog missed it.