Running a fleet

Once you are past one site, these are the numbers that decide whether a deployment is calm or a weekly incident.

Bandwidth

16 kHz mono s16le is 256 kbit/s per direction, uncompressed. Thirty full-duplex terminals talking at once is roughly 15 Mbit/s sustained on a shared access point, which most commercial Wi-Fi will not do gracefully.

Mode A is far kinder: push-to-talk means a badge transmits only while keyed, and on a typical fleet that is a small single-digit percentage of wall time. If your concurrency climbs, Opus would cut the mode C figure roughly eightfold and is the natural upgrade path.

Reconnect storms

A site's access point reboots and thirty devices reconnect in the same second. Each reconnect costs a TLS handshake, a device lookup, a context fetch, a pipeline construction and a recognition socket. Thirty at once can wedge a process — meaning the access point reboot takes out the whole site rather than causing a five-second blip.

attempt 1: 1 s   attempt 4:  8 s
attempt 2: 2 s   attempt 5: 16 s
attempt 3: 4 s   attempt 6+: 60 s (cap)

actual delay = base × (0.75 + random() × 0.5)      # ±25 % jitter

Reset to 1 s only after a connection has survived 60 seconds.

Provisioning at volume

• Assign identities server-side rather than transcribing MACs. One typo per site is one silently broken device that nobody finds for a week.
• Generate QR payloads in bulk and print them on the boxes, not the units.
• Provision to a placement, not to a person. Staff turnover should not require a re-provision.
• Keep the payloads. A device that is factory-reset in the field is re-provisioned by rescanning the same card.

Rollout discipline

Stage firmware: a handful of units first, watch OTA_FAIL incidents and post-update health for a full operating day, then promote. Record firmware_version from every heartbeat so version distribution across a customer's fleet is a query rather than a spreadsheet.

What to alert on

In rough order of how often it will actually matter: