ff55 Protocol (NCH700)

Channel 14 uses a distinct framing format with ff 55 as its magic header. This protocol has no equivalent in the QC35 documentation and appears to be NCH700-specific (or at least specific to the newer Bose headphone generation, codename Goodyear).

Initial handshake

On connection, the device immediately sends:

ff 55 02 00 ee 10

Packet structure analysis:

ff 55   - Magic header (NCH700-specific)
02      - Message type (02 = ACK/status?)
00      - Subtype or sequence number?
ee 10   - Payload (2 bytes)

The ee 10 question

The trailing ee 10 bytes were analyzed against multiple checksum algorithms to determine whether they serve as an integrity check:

• Simple sum of 02 00: 0x02 — does not match ee 10
• XOR of 02 00: 0x02 — does not match
• CRC-16 of 02 00: does not produce ee 10
• CRC-CCITT of 02 00: does not produce ee 10

None of the standard checksum algorithms produce ee 10 from the preceding bytes. The working hypothesis is that ee 10 is status data or a device state indicator rather than a checksum.

Probing results

Several request types were tested by sending ff 55 <type> 00 to channel 14:

Type byte	Response
00	No response
01	ff 55 02 00 ee 10
02	No response
03	No response
04	ff 55 02 00 ee 10
05	ff 55 02 00 ee 10
06	No response

Types 01, 04, and 05 elicit responses. Types 00, 02, 03, and 06 are silently ignored. All responses observed so far are identical: ff 55 02 00 ee 10. The uniform response suggests either:

• A minimal handshake protocol where the device ACKs certain message types without acting on them
• A state machine that requires a specific initialization sequence before accepting real commands
• The probes are syntactically valid but semantically incomplete (missing required payload data)

Session-limited behavior

Channel 14 only accepts the first RFCOMM connection after a power cycle. Subsequent connection attempts return “Connection refused” until the headphones are powered off and on again. This is fundamentally different from channels 8, 9, and 27, which remain available across unlimited connection cycles.

This session-limited behavior has several implications:

1. Testing is slow — each probe attempt requires a full power cycle
2. The protocol may be session-oriented — perhaps designed for a persistent connection from the Bose Music app
3. There may be a teardown handshake that properly closes the session and allows reconnection without power cycling

The grab_ch14.py tool was created to handle this constraint. It polls rapidly so you can power-cycle the headphones and catch the connection window.

Comparison to QC35

The QC35 uses 05 as its magic byte per the based-connect documentation. The NCH700’s ff 55 is a completely different framing — two bytes instead of one, with no overlap in the byte values. This is not an extension of the QC35 protocol but a separate protocol entirely.

The coexistence of both protocols on the same device (QC35-compatible on channels 8/9, ff55 on channel 14) suggests that Bose maintained backward compatibility while adding a new control layer for NCH700-specific features.

Open questions

• What is the full ff55 command set? Only three request types (01, 04, 05) produce responses.
• Does ff55 control NC levels 0-10? The QC35-compatible SET command on channel 8 doesn’t appear to work.
• Is there a handshake sequence needed before the device accepts real commands?
• Can the session be properly closed to allow reconnection without a power cycle?
• Does the Bose Music app connect to channel 14 on every launch, or only during initial pairing?
• What do the ee 10 bytes represent? Device state, firmware build identifier, or something else?