Hi r/esp32,

I’m the developer of OmniPulse, a project that uses ESP32 boards as external Wi-Fi survey sensors for native clients on iPhone, iPad and Mac, with a companion Apple Watch app.

The engineering problem I was trying to solve is that iOS applications do not receive unrestricted information about surrounding Wi-Fi networks. Instead of attempting to bypass the operating system restrictions, I built firmware that lets authorized ESP32 sensors collect standard Wi-Fi scan results and send the observations to the Apple device.

I found several general BLE debugging applications and ESP32 Wi-Fi scanning examples, but I wanted a workflow capable of combining measurements from multiple sensors, reviewing them before importing, and associating them with locations or floor plans.

### Try OmniPulse

- Source code and ESP firmware:
  https://github.com/tiburonns/OmniPulse

- AltStore source:
  https://raw.githubusercontent.com/tiburonns/OmniPulse/main/source.json

- Latest release — OmniPulse 1.0.1:
  https://github.com/tiburonns/OmniPulse/releases/tag/v1.0.1

In AltStore, open **Sources → +** and paste the AltStore source URL.

ESP32 implementation

The current design works as follows:

1. An ESP32 performs a standard Wi-Fi scan.
2. The firmware converts the observations into measurement batches.
3. The batches are transferred to the client through a custom BLE GATT protocol.
4. The client reviews and imports the observations.
5. The measurements can then be used for channel analysis, maps, floor plans, PDF reports and CSV exports.

The application can maintain simultaneous connections with up to eight ESP32 sensors. The firmware also includes BLE OTA support and a 4 MB OTA partition layout.

Current PlatformIO environments cover:

• ESP32
• ESP32-S3
• ESP32-C5
• ESP32-CAM
• XIAO ESP32S3 / Sense

There is also a separate local HTTP implementation for ESP8266 and Wemos/LOLIN D1 mini boards.

No custom PCB is required; the current implementation runs on off-the-shelf development boards.

Safety and privacy boundaries

This is intended only for surveying networks and locations the user owns or is explicitly authorized to analyze.

The firmware does not:

• Deauthenticate clients
• Jam or disrupt radio communications
• Inject packets
• Attempt to decrypt networks
• Capture network payload traffic
• Transmit observed MAC addresses in clear text

BLE identifiers stored by the application are converted into session-specific pseudonyms.

Source and documentation

Main repository:
https://github.com/tiburonns/OmniPulse

ESP32 firmware:
https://github.com/tiburonns/OmniPulse/tree/main/firmware/esp32-omnipulse

Firmware source:
https://github.com/tiburonns/OmniPulse/tree/main/firmware/esp32-omnipulse/src

BLE protocol specification:
https://github.com/tiburonns/OmniPulse/blob/main/docs/ESP32_PROTOCOL.md

Architecture documentation:
https://github.com/tiburonns/OmniPulse/blob/main/docs/ARCHITECTURE.md

The project is free and source-available for inspection. There is no subscription or paid plan.

I would appreciate feedback specifically on these engineering decisions:

1. Is BLE GATT a reasonable transport for batches of Wi-Fi observations, or would you choose HTTP, MQTT or ESP-NOW?
2. Is the protocol documentation sufficient for someone to implement a compatible sensor independently?
3. Which ESP32 variant would you prioritize for reliability and power-consumption testing?
4. Are there additional scan measurements that would be useful without crossing into packet capture or disruptive behavior?

I’ll monitor the comments and would appreciate honest technical criticism. Thanks!