# PW0316 BLE Module Working Summary

This note summarizes the imported module manual [`PW0316_User_Manual_V2.9.pdf`](../Manuals/PW0316_User_Manual_V2.9.pdf) and records why it matters for `TC66C`.

## Source Snapshot

- imported file: `Documentation/Research Resources/Manuals/PW0316_User_Manual_V2.9.pdf`

- source path before import: `/Users/bogdan/Documents/Documentatie/TC66/Other/PW0316_User_Manual_V2.9.pdf`

- pages: `28`

- version label in manual: `V2.9`

- part number: `PW0316`

- SHA-1: `e325f7708f18400fd774f60219e76395797c51cc`

## Why This Matters

The current app already mapped `TC66C` to radio type `PW0316`, but until now that was only a code-level assumption.

This manual strongly supports that mapping and validates the BLE side of the current `TC66C` transport model.

## Confirmed Module Role

The manual describes `PW0316` as a BLE 4.0 transparent serial bridge:

- user MCU talks to the module over UART

- mobile app talks to the module over BLE

- the module forwards data between UART and BLE

- upper-layer meaning is defined by the host MCU and mobile app

This is a strong fit for the existing `TC66C` implementation:

- the app sends ASCII commands

- the module bridges them to the device MCU

- the device MCU returns data that the module fragments into BLE notifications

## Confirmed GATT Layout

The manual explicitly documents the following BLE services and characteristics.

### Serial data channel

- service `0xFFE0`

- characteristic `0xFFE4`

- operation: `Notification`

- payload size: `20` bytes

- meaning: UART RX input is forwarded to BLE notifications

### Bluetooth data channel

- service `0xFFE5`

- characteristic `0xFFE9`

- operation: `Write`

- payload size: `20` bytes

- meaning: BLE writes are forwarded to UART TX

### Anti-hijacking channel

- service `0xFFC0`

- characteristic `0xFFC1`

  - operation: `Write`

  - size: `12` ASCII bytes

  - meaning: current password + new password

- characteristic `0xFFC2`

  - operation: `Notify`

  - size: `1` byte

  - meaning: password operation result

Password event values documented by the module vendor:

- `0` = password accepted

- `1` = password incorrect

- `2` = password updated

- `3` = password cancelled

## Broadcast and Identity Hints

Default BLE advertise data includes partial 16-bit UUIDs for:

- `FFC0`

- `FFE0`

- `FFE5`

Default scan-response data includes:

- manufacturer-specific data with default text payload `RW-BLE`

- local name `PW0316`

This directly explains why the current app can recognize a peripheral named `PW0316` as `TC66C`.

## UART and Flow-Control Behavior

The module manual documents a hardware flow-control model around:

- `BRTS`

- `BCTS`

Relevant points:

- default UART is `9600`, `8N1`

- transparent serial payloads can be any size up to `200` bytes

- BLE wireless payloads are `20` bytes each

- the module automatically splits large UART payloads into BLE packets

- the host MCU must manage `BRTS`

- the module uses `BCTS` to tell the MCU when module-to-host data is pending

## Throughput and Timing

The manual states:

- default BLE connection interval: `20 ms`

- highest theoretical transparent throughput is achieved with `115200` UART and `20 ms` BLE interval

- reliable Bluetooth data transmission is limited to about `10 KByte/s`

This is consistent with the current app's expectation that a `TC66C` response arrives as multiple `20`-byte BLE fragments.

## AT Command Surface

The module supports UART-side `TTM:` AT commands for module management, including:

- test

- MAC read/write

- baud rate

- rename

- manufacturer data

- advertise / scan response

- TX power

- reset

- factory reset

- version

- product identification code

- advertise interval

- connection interval

- broadcast on/off

- serial send setup delay

- anti-hijack password

Important implication:

- these are module-management commands, not necessarily `TC66C` application commands

- they should not be confused with the ASCII commands already seen in the app for meter data requests

## What This Validates For `TC66C`

High-confidence validations:

- `TC66C` does not use the same BLE channel shape as the `UM` family

- the current app's `FFE0` / `FFE4` and `FFE5` / `FFE9` mapping is correct for `PW0316`

- BLE traffic is expected in `20`-byte chunks

- a separate security channel `FFC0` exists and may matter if the module password is enabled

- the peripheral name `PW0316` is a credible alias for the hardware module used inside `TC66C`

## What This Does Not Validate

The module manual does not describe:

- the `TC66C` meter's application-level ASCII commands such as `bgetva`

- the `192`-byte encrypted snapshot format used by the current app

- the AES key or packet layout of `pac1` / `pac2` / `pac3`

- the meaning of measurement fields returned by the meter MCU

So this manual validates the transport shell, not the meter payload itself.

## Practical Implications For The Codebase

- keep `TC66C` on the `PW0316` transport path

- keep `TC66C` separate from the `UM25C` / `UM34C` `HM-10` style path

- consider adding `FFC0` / `FFC1` / `FFC2` support only if we discover password-protected modules in the field

- when debugging fragmentation, assume the BLE layer naturally emits `20`-byte chunks and that larger frames are reconstructed above that layer