Connection failures (BLE_INIT: Malloc failed, truncated spectrum transfers,
btc_gattc_cback floods) were caused by WiFi and Bluedroid contending for heap.
The update check ran at startup while BLE was connecting, and the WiFi station
was never shut down afterwards.
- Serialise the radios: WiFi work suspends the BLE link and resumes it after.
Lossless, because the detector accumulates internally regardless.
- Wait for an acknowledgement rather than a fixed delay; a spectrum read is a
blocking round trip of up to 4 s and was still in flight otherwise.
- Tear down Bluedroid (BLEDevice::deinit(false)) rather than only deleting the
client: returns ~51 KB, without which TLS could not allocate.
- Power WiFi down after every check/install and on leaving Settings.
- Free the BLEClient, which Arduino-ESP32 allocates and never deletes. It
leaked ~4.15 KB per connect together with its discovered service tree.
Identification, from a real uranium-ore measurement that read BACKGROUND while
Bi-214 sat at 92%:
- A decay-chain member conclusive on its own now carries the chain instead of
requiring a second member.
- Lines below 110 keV can no longer identify a nuclide that also emits above
it: that region is unmodelled X-ray fluorescence and backscatter, and it was
producing phantom Ba-133.
- The ROI fallback now applies the same competitive assignment as peak
matching, which it was silently undoing.
- RESET latches until the link is up instead of being discarded.
Verified on hardware: uranium ore -> URANIUM ORE in 17 s (U-238 chain 100%);
thorium source -> THORIUM (Th-232 chain 99%, uranium 0%); four update checks
during a live measurement with heap flat to within 60 bytes.
highway
562ed0c368