# Exercise 302: microReticulum BLE announce + SINGLE destination ping-pong

This exercise is the BLE analogue of Exercise 202.

Exercise 301 proved that microReticulum `PLAIN` packets can cross the ESP32/T-Beam BLE interface. Exercise 302 adds Reticulum identity discovery: each node creates an identity, announces an inbound `SINGLE` destination over BLE, learns the peer's announced identity and destination hash, then sends encrypted `DATA` packets to that learned destination.

```text
BLE GATT connection -> Identity -> SINGLE destination -> announce -> peer learns identity/path -> encrypted DATA packet
```

For this first BLE `SINGLE` proof, roles are still explicit:

```text
AMY -> BLE central/client
BOB -> BLE peripheral/server
```

## Build, Upload, And Monitor

*Start BOB first* so the peripheral is advertising before AMY scans.

In one console:

```bash
source /home/jlpoole/rnsenv/bin/activate
cd /usr/local/src/microreticulum/microReticulumTbeam
pio run -d exercises/302_microReticulum_ble_announce_single -e bob -t upload --upload-port /dev/ttytBOB && \
pio device monitor -d exercises/302_microReticulum_ble_announce_single -e bob
```

In another console:

```bash
source /home/jlpoole/rnsenv/bin/activate
cd /usr/local/src/microreticulum/microReticulumTbeam
pio run -d exercises/302_microReticulum_ble_announce_single -e amy -t upload --upload-port /dev/ttytAMY && \
pio device monitor -d exercises/302_microReticulum_ble_announce_single -e amy
```

The `platformio.ini` maps each environment to its stable USB symlink:

```text
amy -> /dev/ttytAMY
bob -> /dev/ttytBOB
cy  -> /dev/ttytCY
dan -> /dev/ttytDAN
ed  -> /dev/ttytED
```

The shorter form should also work once the symlinks exist:

```bash
pio run -d exercises/302_microReticulum_ble_announce_single -e bob -t upload
pio device monitor -d exercises/302_microReticulum_ble_announce_single -e bob
```

## Expected Output

After the BLE GATT connection is made, each node prints its local `SINGLE` destination hash and periodically announces it:

```text
Local SINGLE destination: 2f6c...
TX ANNOUNCE: Amy
```

After the peer's announce is received, the node prints the learned destination:

```text
RX ANNOUNCE: label=Bob hash=91a4...
```

Once a peer is known, it sends encrypted `DATA` packets to that destination:

```text
TX SINGLE BLE: Amy -> Bob iter=0
RX SINGLE BLE: Bob -> Amy iter=0
```
![](../../img/20260519_141153_Tue.png)
## Notes

- This exercise uses the same ESP32 BLE interface introduced in Exercise 301.
- The BLE fragmentation header matches `/usr/local/src/ble-reticulum/BLE_PROTOCOL_v2.2.md`: `[type:1][sequence:2][total:2][payload...]`.
- The identity is generated on each boot. The destination hash can change after reset because the identity changes.
- App data in the announce carries the human-readable node label, such as `Amy` or `Bob`.
- This is still not a negotiated Reticulum `Link`; Exercise 303 should use the announced `SINGLE` destination as the target for a negotiated link over BLE.
