One radio at a time.

Why sequential radios. On the ESP32-S3 the Bluetooth controller, the Wi-Fi driver and the camera sensor all compete for the same internal SRAM. Running BLE and Wi-Fi together would turn that budget into a measurement instead of a guarantee. The design rule (decided 2026-09-15) is the ordinary IoT split: BLE for onboarding and control, Wi-Fi for data, never both. Switching is a full stop and de-initialisation of one stack before the other is started — nimble_port_stop/nimble_port_deinit down to an idle BT controller, and a full esp_wifi stop and deinit on the way back — so the live sets are only ever BLE + camera or Wi-Fi + camera + TLS. Timer wakes never touch a radio at all; they judge and spool to the SD card.

Where the radios come from. A button press or a cold boot opens a window: the camera advertises BLE as dc-<device> for ble_adv_s (120 s; 600 s when unprovisioned). A linked phone extends the window and can ask for a handoff to Wi-Fi at any time. If no phone links before the window ends, the camera hands itself to Wi-Fi and runs the ordinary contact — so the app is optional and the button still works on its own. Every window ends with both radios de-initialised before deep sleep.

The phone is the network. The camera's Wi-Fi credentials are the owner's phone hotspot (identity, tier 1). Whether the app asked for the handoff or the camera did it alone, the camera joins that hotspot; the phone routes it over cell to the sensorhub's Funnel endpoint (TLS, X-Token) and the blob gate forwards to ingest. The camera is the config sync agent: an edit made over BLE is pushed at the next contact, and the server wins a real conflict.

Which cameras. The BLE path is the XIAO ESP32S3 (xiaocam1). The OpenMV N6's STM32N657 has no BLE radio, so it uses only the server path on the right of the map (its LoRa reporting is a separate channel not shown here).

Going out. Tapping View over Wi-Fi (or Contact) sends wifi.up (or contact). The camera replies with {"handoff":"wifi", "expect_ip", "back_in_s"}, sends the event bye reason:handoff, terminates the link, and only then tears NimBLE down; radio.c asserts the BT controller is idle in the log at every transition. The app moves to HANDOFF and starts listening on UDP :8267.

Finding it. Once the camera has joined the hotspot and its control plane is up it broadcasts a beacon once a second — {"dc":1,"device","ip","port"} — so the owner never types an IP. The first GET /status that answers puts the app in WIFI; on the bench that is about 2 s after the tap. In WIFI the app polls /status every 2 s for radio, ble_back_in_s and the drain counters, and can fetch /spool, /thumb and /stream. HTTP goes through CamHttp, which binds to a network only when that network's subnet actually contains the camera — a Pixel can be a Wi-Fi client on one subnet and a hotspot on another at the same time.

Coming back. Bring back to Bluetooth sends POST /ble; the camera answers {"ok":true,"radio":"ble","in_s":2}, stops the HTTP server, stops and de-initialises Wi-Fi, re-initialises NimBLE and advertises on the same fixed address — measured 12 ms after Wi-Fi off. The app, now RETURNING, does a direct connectGatt to that address (3–5 s) rather than scanning: Android silently returns nothing after more than five scans in 30 s, so an address-filtered scan is only the fallback. hello/auth run again and the app is back in BLE. The camera guarantees at least 30 s of BLE after a POST /ble even if the original window has expired.

Losing it. If the camera ends the window itself — bye reason:window or live — or a rescan times out, the app shows LOST: “press the camera's button”. The camera never depends on the app; an unexpected disconnect inside the window is a 30 s address-filtered rescan.

1. Wake, judge, spool. Timer and motion wakes capture, run the on-device gate, and record kept frames and their sidecar JSON to the SD spool. No radio is started.
2. Window. A button press (a GPIO0 wake from deep sleep), a cold boot, a first boot after provisioning, or a pending-verify firmware image runs radio_window_run(). Provisioned: BLE advertises for 120 s. If a phone links it can extend the window and hand off; a linked phone that goes quiet for contact_idle_s ends it.
3. Self-contact. No phone by the deadline: BLE is stopped and contact_run(contact) joins the hotspot named in the camera's identity for up to hotspot_join_s.
4. Clock, announce, firmware. GET /config/<device> is the first request; the server's Date sets the RTC and clock_skew_s is recorded. One announce telemetry goes to POST /telemetry/<device>. GET /firmware/<device>/version is checked before any config is applied — firmware first, then config.
5. Config push or pull. If tuning was edited over BLE (cfg_src = ble) the camera does POST /config/<device> with {base, config, schema}; the server accepts only if its cfg equals base, otherwise answers 409 with the current config and the camera applies that. Otherwise the pulled config is applied and stored.
6. Drain. Ranked spool frames up to upload_cap, then debug frames, each as POST /blob/<device>/frame with the meta in X-Meta, through the blob gate to ingest; telemetry every telemetry_s meanwhile. Accepted frames are deleted from the card.
7. Serve, then leave. The :8266 control plane stays up (and keeps beaconing) until contact_idle_s passes with no request, or POST /ble, or live. Wi-Fi is stopped and de-initialised, the camera de-initialised, and the board deep-sleeps.