BT201 Bluetooth module (Jieli KT1025A)

Dual-mode Bluetooth 5.0 module: classic Bluetooth (EDR) audio plus BLE with a transparent data service. The host MCU controls it with AT commands on a UART (115200 8N1).

Source: BT201 Module KT1025A/B User Manual V2.3 (Shenzhen Qingyue Electronics), cited as [M].

Status at a glance

Aspect	Status
Model	`crates/core/src/peripherals/components/bt201.rs` (hand-written kit)
Bus	UART, any UART model that hosts stream devices (generic `Uart`, i.MX RT LPUART)
Type id	`bt201`
Tests	unit tests `bt201_tests.rs`; end to end `crates/cli/tests/e2e_bt201.rs`
Tier	modeled (AT interface, link state, BLE transparent data)

Attach

external_devices:
  - id: "bt"
    type: "bt201"
    connection: "lpuart5"
    config:
      ble_name: "MY-BLE"       # names in module flash at power-on (optional)
      edr_name: "MY AUDIO"
      boot_ms: 500             # power-on to ready (not in [M])
      reply_delay_us: 1000     # command to reply (not in [M])
      status_period_ms: 500    # TS+ repeat period, 0 = on change only

Other keys: edr, ble (radio switches in module flash, default on), packet_gap_us (idle time that ends a data packet from the MCU, default 1000), banner (start-up block, default on).

AT commands

Replies end with \r\n. A control command answers OK, a query answers with its data, an unknown command answers ER+2, a bad parameter ER+4 [M 2].

Command	Reply	Effect
`AT+TM`	`TM+<ble name>`	BLE name in use
`AT+TD`	`TD+<edr name>`	EDR name in use
`AT+BD<name>`	`OK`	EDR name (1..32 bytes), used after reset
`AT+BM<name>`	`OK`	BLE name (1..32 bytes), used after reset
`AT+CN00` / `01`	`OK`	prompt tone off / on (saved)
`AT+QN`	`QN+00` / `01`	prompt tone
`AT+B500` / `01`	`OK`	EDR off / on, used after reset [M 6.1]
`AT+B400` / `01`	`OK`	BLE off / on, used after reset [M 6.1]
`AT+TS`	`TS+0n`	EDR status
`AT+TL`	`TL+0n`	BLE status
`AT+CR00` / `01`	`OK`	status pushes off / on
`AT+CZ`	`OK`	soft reset: links drop, saved settings apply, start-up again

Start-up block (after boot_ms): AT+VER2.3-20190517, QA+30, QM+00, QN+0n, QK+01, QG+01, Q1+01 [M 5], then TS+00 (EDR on) and TL+02 (BLE on).

Status pushes: EDR TS+00 waiting for pairing, 01 connected, 02 music, 03 call; BLE TL+02 advertising, 03 connected, 04 disconnected [M 5]. A change is pushed at once; TS+ repeats every status_period_ms.

Drive the phone from a test script

What	How
EDR link	stimulus `target: {component: bt, channel: edr_link}`, value 0..3 (the `TS` code)
BLE link	stimulus `target: {component: bt, channel: ble_link}`, value 0 / 1
Phone sends data	`uart_injections: [{uart: lpuart5, device: bt, bytes: [...]}]`
What the phone got	`peripheral_log: {peripheral: lpuart5, log: air, contains: "mcu->phone ..."}`

A link is refused while the module boots or while that radio is off. Phone data reaches the MCU only while BLE is connected. MCU bytes that are not an AT line go to the phone in packets of at most 128 bytes [M 7]; without a BLE link they are dropped.

Logs

Read on the hosting UART with peripheral_log:

Log	Line
`at`	`12.345000s AT+TM -> TM+BT201-BLE`
`link`	`12.345000s TL+03 ble connected`
`air`	`12.345000s phone->mcu aa 55 01 00 00 c8 cf`, `mcu->phone ...`, `... dropped (no ble link) ...`

The time is the module's device time since power-on.

Limitations

Not modelled: audio (A2DP, the I2S output), SPP data, calls, the TF/U-disk player, AT commands over BLE (characteristic FFF3), baud-rate change (AT+CT), BLE MTU negotiation, RF. A host byte stream that starts with AT is always taken as a command. Reply latency and boot time are not in [M]; they are config values with assumed defaults.