QS08 Recorder BLE Communication Protocol

• The frame header LEN and CRC fields are both little-endian.
• In the file list, count / time / size are big-endian.
• CRC uses CRC-16/XMODEM.
• The full file download request frame for command 2-2 is 36 bytes.
• CB08 requires the entire 36-byte frame in a single GATT write. Splitting it into `20 + 16` bytes reliably returns “file does not exist”.

This protocol is used by a WeChat Mini Program to control the CB08 recorder over BLE, receive real-time audio, read the device file list, and import recordings from the device as WAV or OPUS files.

If a multi-byte field is explicitly marked LE, parse it as little-endian. Integer fields in the file list structure use BE according to live packet captures. Unless otherwise stated, all command IDs are expressed in decimal.

After a successful connection, AE22 must be subscribed first. AE23 carries key and recording-state messages, and should also be subscribed. AE22 and AE23 should use independent frame buffers to avoid byte interleaving between notification channels.

Android may actively negotiate MTU with `setBLEMTU`. On iOS, MTU is negotiated by the system. Regular commands may use `MTU - 3` as payload size, but the file import request 2-2 must follow the live-device single-write constraint described in Section 7.

CRC input must contain the two raw LEN bytes from the frame header followed by DATA. It must not include `MAGIC`, `SEQ`, or the `CRC` field itself.

In the vendor document, Section 4 once described `TYPE=3` as ACK, while Section 7 defined it as key commands. Implementation should follow the Section 7 command table. If DATA contains only a single TYPE byte, treat it as ACK.

Real-time audio data may be saved directly as backup data. Actual speech-to-text requires backend OPUS decoding/transcoding plus streaming ASR. Permanent cloud service keys must not be written into the Mini Program.

The device may send the file list over multiple `CMD=1` frames. The app should accumulate all `N` records from each frame and return the full list after receiving `CMD=18`. To remain compatible with older firmware that does not send `CMD=18`, use an idle timeout of about 1.2 seconds after the final list frame.

A typical filename such as `note20260710-162938.opus` is 24 bytes long, while the file list field is only 20 bytes. The list therefore actually returns `note20260710-162938.` and the full extension must be reconstructed during download.

The complete protocol frame is 36 bytes. Live testing on CB08 devices A and B confirmed the following:

• A single 36-byte GATT write succeeds.
• If the application layer splits the frame into `20B + 16B`, the device parses the filename incorrectly and returns `CMD=5 / code=1` (file does not exist).

Do not let a generic packet splitter fragment the `2-2` frame.

1. Step 1: Read the actual MTU

After connection, `getBLEMTU` may be used to obtain `ATT_MTU`. Regular commands may use `MTU-3`, but `2-2` still requires the forced single-write rule above.

1. Step 2: Rebuild the target filename

Prefer `base.wav` so the recorder outputs a standard WAV file. If that fails, try `base.opus` and finally the raw truncated name from the file list. The `filename` field is fixed at 24 bytes and must be NUL-padded.

1. Step 3: Send the complete request

Build `TYPE=2`, `CMD=2`, `offset=0`, and the 24-byte filename, then send the full frame including the 6-byte generic header in a single write to `AE21`.

1. Step 4: Receive file data

After receiving `CMD=3`, create the transfer session and keep appending the body bytes from `CMD=4`. Each valid data chunk may refresh the idle timeout.

1. Step 5: Handle the finish code

When `CMD=5` is received:

• `code=0`: write the file to disk.
• `code=1`: try the next candidate filename.
• `code=2`: reset offset.
• `code=3`: stop and report the transfer as interrupted or stopped.

Real transmitted request frame for a successful download of `note20260710-162938.wav` captured on 2026-07-10:

5a 03 9e 20 1e 00 02 02 00 00 00 00 6e 6f 74 65 32 30 32 36 30 37 31 30 2d 31 36 32 39 33 38 2e 77 61 76 00

A valid WAV file should satisfy `bytes[0:4] = RIFF` and `bytes[8:12] = WAVE`. The `size` field in the file list is the compressed size on the device, not the transcoded WAV size. WAV progress may be estimated by `duration x 32000B/s + 44`.

`CMD 1 / 3 / 5 / 7` may also be triggered by physical buttons and reported through `AE23`. Implementations should distinguish active command responses from device-generated events based on the characteristic source and the current session state.

File deletion commands are destructive. End-to-end validation should perform read and download only by default, and should not execute `CMD=8 / CMD=9` unless validated on dedicated test recordings first. Before release, confirm that the big-endian 28-byte file entry matches the target firmware exactly.