# 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