While working on BLE firmware, I noticed that a surprising amount of debugging time was spent repeating the same interaction rather than actually debugging the firmware.

A typical test might be:

connect → authenticate → send command → receive notification → inspect packet → extract bytes → convert values → send response → repeat.

BLE scanner apps are great for inspecting GATT services and manually reading/writing characteristics, but once a device protocol becomes stateful or requires packet processing, I usually end up writing temporary scripts or a small test app.

I wanted something in between those two approaches, so I built BLECI.

It’s an iOS BLE debugging tool where communication and packet-processing steps can be combined into reusable workflows.

For example:

Receive notification  
→ slice bytes 6–7  
→ interpret as UInt16  
→ apply calculation  
→ IF value exceeds threshold  
→ generate packet  
→ write response

It also supports command sequences, timers, automatic receive rules, ASCII/hex/integer conversions, AES-related packet processing, RSSI/MTU information, latency logging and CSV export.

The goal isn’t really to replace a full test framework. It’s to avoid building disposable test software during firmware development.

I’m curious how embedded developers here handle this today.

Do you mostly use nRF Connect/LightBlue, Python scripts, custom mobile apps, or hardware-specific tooling?

[BLECI](https://apps.apple.com/us/app/bluetooth-ci-tracker/id6451366993)

I built a tool to automate the repetitive parts of BLE firmware debugging