Changelog since v1.3.0

O2 Ring connection reliability

Fixed: Phantom connections after rapid connect/disconnect

When the ring connected and immediately disconnected (within milliseconds),
the firmware lost track of the real connection ID and logged handle=65535.
The orphaned connection stayed alive on the ring's side for ~98 seconds until
the ring's internal timeout fired, wasting battery and blocking reconnection.
The firmware now saves the connection ID the instant it arrives and uses it to
clean up orphaned connections properly.

Fixed: Endless retry loop kept ring stuck

When the ring was in a bad state, the firmware retried connection every ~15
seconds for hours, preventing the ring from powering off and resetting its
Bluetooth. After 3 consecutive failures, the firmware now pauses for 130
seconds to let the ring power down and recover naturally.

Fixed: Confusing "service range empty" error on Gen2 ring

When the Gen2 ring is on a finger and actively recording, it exposes a
stripped-down Bluetooth profile that lacks the file-transfer service. The
firmware now detects this state (via MTU negotiation result) and reports a
clear message: "Ring may be in recording mode — remove from finger and retry."
A separate, distinct error is reported when the MTU exchange itself times out,
indicating the ring is unresponsive rather than in recording mode.

Improved: Disconnect reason logging

Disconnect logs now show the human-readable error name alongside the numeric
code, e.g. reason=571 / 0x3B Unacceptable Connection Parameters instead of
just reason=571. This eliminates the need for a lookup table when analyzing
logs.

Improved: Connection parameter visibility

The firmware now logs the negotiated Bluetooth connection parameters (interval,
latency, supervision timeout) immediately after connecting, and again whenever
the ring requests a parameter update mid-connection. This provides diagnostic
visibility that was previously completely absent.

Improved: Connection parameter update handling

The firmware now explicitly accepts and logs L2CAP connection parameter update
requests from the ring, rather than silently handling them via a catch-all
default case. No behavior change — just visibility.