modules/woz_aliro/src/aliro_ranging.c
asxeem/openaliro
Module

aliro_ranging.c

UWB ranging bring-up and lifecycle for the Aliro reader: initializes the reader's UWB…

modules/woz_aliro/src/aliro_ranging.c7 documented symbols

Overview

UWB ranging bring-up and lifecycle for the Aliro reader: initializes the reader's UWB adapter and Cherry CCC context once, then arms, feeds, and tears down per-connection ranging sessions driven by the M1-M4 setup exchanged over the peer's L2CAP channel. Maintains process-wide singletons for the Cherry context and adapter (set up once via aliro_ranging_init) and for the single active ranging session (the DW3000 supports only one session at a time), tracking its owning secure channel for send/receive framing.

depends on aliro_ble.h aliro_crypto.h aliro_lab.h aliro_lat.h aliro_ranging.h woz_log.h aliro_uwb_adapter.h aliro_uwb_session.h cherry.h cherry_ccc.h woz_uwb_facade.h

flowchart TD
  aliro_ranging_feed --> lat_mark_sdu

API

Fstatic void lat_mark_sdu(uint8_t proto, uint8_t id)

modules/woz_aliro/src/aliro_ranging.c:90

Stamp the latency phase this SDU actually is, by identity rather than by arrival order. Order-based labelling was wrong on real hardware: the phone sends a proto-3 (supplementary-service) SDU ahead of Initiate-Ranging-Session, which shifted every device->reader label by one frame and stamped "M2 received" on the IRS, i.e. before M1 had been sent. Diagnostics only; the protocol never depended on this.

called by aliro_ranging_feed, uwb_tx_cb

Fstatic void uwb_tx_cb(struct aliro_uwb_message *message, struct aliro_uwb_session *session, void *user_data, bool timeout)

modules/woz_aliro/src/aliro_ranging.c:119

Send an adapter-built message verbatim over the peer's L2CAP channel. The bytes already carry the 4-byte Aliro header; hand them straight to the BLE send. We own the message and MUST free it (even if we don't send).

calls lat_mark_sdu

Fstatic void uwb_ev_cb(struct aliro_uwb_session_event *event, void *user_data)

modules/woz_aliro/src/aliro_ranging.c:153

Session notifications. On DEINIT the engine frees the session right after this returns, so never touch event->session here; identify via user_data. Every event must be freed.

Fint aliro_ranging_init(void)

modules/woz_aliro/src/aliro_ranging.c:187

One-time bring-up of the reader UWB adapter (cherry ctx + capabilities + reader config). Idempotent. Returns 0 on success, negative on failure (the reader still runs; ranging just won't start).

Fint aliro_ranging_start(uint16_t conn_handle, uint32_t session_id, const uint8_t *ursk, struct aliro_secchan *sc_ble)

modules/woz_aliro/src/aliro_ranging.c:260

Arm the M1-M4 ranging setup for a connection: create the session with ranging session id @session_id, bound to the 32-byte @ursk and the BleSK ranging channel @sc_ble, whose reader-direction counter is used to seal the engine's outbound SDUs (continuing from the AP-Completed message). @session_id MUST match the value the device derived from the AUTH0 transaction id (big-endian txid[12..15]); it is advertised in M1 and the device indexes its URSK by it. M1 is NOT sent here — the engine emits it when the device sends its Initiate-Ranging-Session. Returns 0 on success, negative on failure or if a ranging session is already active (the DW3000 is single-session).

Fint aliro_ranging_feed(uint16_t conn_handle, const uint8_t *data, size_t len)

modules/woz_aliro/src/aliro_ranging.c:313

Feed one inbound post-auth PLAINTEXT SDU (already BleSK-opened by the reader; proto/id/len header + payload) to the active ranging session. M4 makes the engine start the responder with the negotiated parameters. Returns 0 if consumed, negative if there is no active session or the engine rejected it.

calls lat_mark_sdu

Fvoid aliro_ranging_stop(uint16_t conn_handle)

modules/woz_aliro/src/aliro_ranging.c:348

Tear down the ranging session for a connection (on disconnect). No-op if none is active for @conn_handle.