What BLE programs we run
We work on three shapes of BLE engagement: a clean-sheet BLE firmware build on new silicon; a BLE rescue on an existing firmware tree that is missing connection stability, OTA, or iOS background support; and a mobile-side rescue, where the firmware is fine but the iOS / Android side keeps losing the device. All three start with a written audit so you know exactly what we will do before any code changes.
BLE pieces we ship
Peripheral & central stacks
BLE 5.x peripheral and central roles, GATT server / client, custom services, Notify / Indicate, MTU negotiation, PHY switching (1M / 2M / Coded).
Pairing & bonding UX
Just Works, Numeric Comparison, Out-of-Band, LE Secure Connections. Bond list management, multi-phone bonding, and recovery when a user resets their phone.
Code-signed OTA
MCUboot or Nordic Secure DFU. A/B partition, automatic rollback on boot failure, and OTA jobs orchestrated from your cloud.
iOS quirks, handled
Core Bluetooth state restoration, background scanning, app-kill survival, and the device-cache resets nobody warns you about. Yes, we have a checklist for App Review.
Mesh & multi-device
BLE Mesh, multi-peripheral connections, and BLE-to-Wi-Fi gateways for fleets that need cloud reach without cellular.
Low-power tuning
Connection interval / latency tuning, advertisement scheduling, and event-driven duty cycling — measured on a Nordic PPK II so the battery budget is grounded in real microamps.
Common BLE problems we fix
- The phone keeps losing the device after backgrounding. Almost always a Core Bluetooth state restoration issue on iOS or a foreground service / pending intent issue on Android.
- OTA bricks units in the field. Missing A/B layout or no rollback verification. We refactor to MCUboot with verified boot.
- The battery dies in 3 days instead of 30. Connection interval too tight, advertising too aggressive, or radio not actually entering sleep. PPK II finds it in an afternoon.
- Beta testers complain about flaky pairing. Usually a missing bond list cleanup, a UUID collision, or scan filter that excludes the device on resume.
BLE stack we ship in production
| Layer | What we use |
|---|---|
| Silicon | Nordic nRF52832 / nRF52840 / nRF5340, ESP32 / ESP32-S3, Qualcomm QCC51xx, STM32WB |
| BLE stacks | Nordic SoftDevice, NimBLE, Zephyr Bluetooth, ESP-IDF Bluedroid / NimBLE |
| Bootloaders | MCUboot (signed, A/B), Nordic Secure DFU |
| Mobile | iOS Core Bluetooth (Swift), Android BluetoothGatt (Kotlin), Flutter (flutter_blue_plus), React Native (react-native-ble-plx) |
| Debug tools | nRF Connect Mobile, Wireshark over Ubertooth, Nordic PPK II for power, Saleae Logic for line capture |
Proof — BLE products we shipped
FAQ
Which BLE silicon do you ship on?
Nordic nRF52832/40 and nRF5340, ESP32 and ESP32-S3, Qualcomm QCC51xx for combined audio+sensors, and STM32WB for Cortex-M4 + BLE in one chip. We pick for your power, range, and BoM.
How do you handle BLE pairing on iOS without surprising the user?
Filter by service UUID during scan, present a single-tap pair flow, fall back to the OS-level pairing alert only when bonding is required. Core Bluetooth state restoration keeps the connection alive through backgrounding, app kill, and phone reboot.
Can you ship BLE OTA with rollback safety?
Yes. MCUboot or Nordic Secure DFU with code-signed images, A/B partitions, automatic rollback on boot failure, and version-aware OTA jobs from the cloud.
Do you write the mobile app side too?
Yes. iOS Core Bluetooth and Android BluetoothGatt are part of our weekly work. We can deliver the BLE plugin for your existing Flutter / React Native app or build the whole companion app.
BLE rescue or clean-sheet build?
Book a free 30-minute call. We will look at your stack, your pairing flow, or your OTA path and give you a written assessment within a week.
Book a free 30-min call