A weekend of protocol work gave macOS the Soundcore controls Anker ships only on phones

The protocol is small. Four magic bytes, a sequence byte, a two-byte command, a two-byte little-endian total length, the payload, and a one-byte checksum that is the sum of every preceding byte truncated to 8 bits ^[6][7]. Device replies swap the magic to `09 FF 00 00` ^[8]. The worked example in the post is `08 EE 00 00 | 00 | 06 81 | 10 00 | 00 5F 02 00 00 01 | EF` ^[6]. Its length field reads 0x0010, or 16, and the frame as printed is 16 bytes, so the length counts header, payload and checksum together ^[1]. The 15 bytes before the checksum sum to 495, and 495 modulo 256 is 239, which is 0xEF ^[2].

He tested the codec before he tested the hardware. Six packets documented for other Soundcore models went through his encoder and came back byte for byte, which he calls a five-minute investment that let him rule out the encoder later, when nothing worked ^[9].

Nothing worked for a while. `openRFCOMMChannelAsync` returned success and the delegate callback never fired, and the synchronous variant returned `kIOReturnError` immediately ^[10]. He tried channel 30, then 17, then 1, which is handsfree and definitely exists, then 2, which advertises nothing ^[11]. He opened RFCOMM to an Android phone on OBEX and phonebook access and got the identical failure, across two devices and seven channels, from a bare binary and from a signed `.app` ^[12]. `bluetoothd` logged no connect attempt reaching the air, TCC was granted, the app was not sandboxed, and the baseband link was up ^[13].

The first `openRFCOMMChannelAsync` in a process always fails, apparently because it lazily initialises IOBluetooth's run-loop source, and a retry succeeds ^[16]. The spike that eventually worked had made two throwaway attempts against the phone before the one that connected ^[17]. "It was measuring my own bug twice and I read it as corroboration," the developer wrote of his control experiment ^[18]. The Raspberry Pi bridge he had started designing would have been hardware bought to work around a missing retry ^[3].

The second problem was delivery. IOBluetooth hands delegate callbacks to the run loop of the thread that opened the channel, not to a dispatch queue, so a Swift continuation awaited on that thread never sees them and the code has to pump the run loop itself ^[19]. CoreBluetooth uses a dispatch queue, and it had worked for him throughout ^[20]. Both faults present the same way from the caller's side: a success return with no callback ^[4].

Channels 12 and 13 in the same SDP record flash device firmware and chipset firmware ^[3]. He hard-blocks both by service identity, and says to do that before writing a single byte ^[5].