Three engineering problems wearing one name

BLE firmware development means solving three problems at the same time: the GATT data model your device exposes to a phone, the radio behavior that decides how fast a user can find and connect, and the power budget that decides whether the battery lasts a week or a year. A vendor sample project will get a dev board talking to an iPhone in an afternoon. Everything between that demo and a shippable product is the actual work, and almost all of it comes down to choices the sample made for you by default.

If you are still deciding whether Bluetooth is the right radio at all, start with Bluetooth vs. Wi-Fi for a product and Bluetooth Classic vs. BLE. This article assumes BLE is settled and looks at what the firmware team has to build.

Designing the GATT profile: your product's real API

The GATT structure -- services and characteristics -- is a contract between firmware and the app. Once units are in customers' hands, that contract is expensive to change, because old firmware and new app versions have to coexist for years. Treat the profile like a published API, not like a memory map.

  • Use standard services where they exist. Battery Service, Device Information, and the defined measurement profiles are recognized automatically by phones, debug apps, and test tools. Free interoperability.
  • Model characteristics around user scenarios, not registers. If the app has to read five characteristics to render one screen, the screen will feel slow. One characteristic carrying a packed struct is faster and cheaper in radio time.
  • Notify instead of poll. Repeated reads from the phone burn energy on both ends. Push a notification when a value actually changes.
  • Version the protocol on day one. A single read-only protocol-version characteristic is the cheapest insurance you will ever buy. It matters most when you add firmware updates over the air.
  • Separate control from telemetry. Commands that change device state deserve their own characteristic with explicit acknowledgment and error codes, so the app can tell "not delivered" from "rejected."

Advertising: the discovery-versus-battery trade

A BLE device that is not connected broadcasts advertising packets at a fixed interval, and that interval is a direct trade between user experience and current draw. Short intervals in the tens of milliseconds give instant discovery and connection but cost real battery. Intervals of a second or two are very cheap but leave the user staring at a spinner.

The pattern that works in most products is event-driven: advertise fast for the first half-minute or so after a wake event -- power-on, button press, motion -- then fall back to a slow interval or stop advertising entirely. Advertising payload matters too. Device name, a service UUID, and a few bytes of manufacturer data should be enough for the app to filter your product out of a crowded scan without connecting to every device it sees.

Connection parameters: the step everyone skips

After connection, the connection interval, slave latency, and supervision timeout govern both throughput and current. A product streaming sensor samples needs a short interval. A product that reports once a minute can request a long interval with high latency and cut average current by an order of magnitude. Two practical cautions: the phone is the connection master and can refuse your requested parameters, and each mobile operating system negotiates differently. Firmware that assumes its request was granted will behave differently on two phones sitting on the same desk.

The power budget, in orders of magnitude

Typical figures for a modern BLE system-on-chip: deep sleep in the single-digit microamps, slow advertising in the tens of microamps averaged over time, an active connection anywhere from hundreds of microamps to several milliamps depending on interval and payload. The implication is blunt -- a coin-cell product only reaches months of life if it is asleep almost all the time and wakes on events. That is a firmware architecture decision, covered in more depth in low-power firmware and sleep modes.

Always validate with a real current measurement across a full duty cycle, not with datasheet arithmetic. Datasheet numbers describe the radio; your product's average current is dominated by sensors, LEDs, regulators, and the code that forgot to turn something off.

How much data BLE can actually move

BLE is not a video pipe, but it is far more capable than its reputation once negotiation is done properly. With an increased MTU, data length extension, and the higher-rate PHY available in current Bluetooth versions, configuration files, log dumps, and firmware images move comfortably. Firmware images are the common case, and the mechanics of doing that safely are the same ones described in OTA firmware updates. Only genuinely continuous streams -- quality audio, video -- stay out of scope.

Pairing, bonding, and security

Decide early whether the product requires pairing, whether bonds persist, and how a user resets them when a phone is lost or a device is resold. Products that skip this end up with a device nobody else can connect to and no documented recovery path. If characteristics can change physical state, encryption plus authenticated pairing is the baseline, and key storage should be planned alongside secure boot and firmware encryption rather than bolted on later.

Testing, qualification, and the radio itself

Two layers of validation sit outside normal firmware testing. Bluetooth qualification through the Bluetooth SIG covers protocol conformance and the right to use the trademark; using a pre-certified module shortens that considerably compared with a bare chip and a custom antenna. Separately, any intentional radiator sold in the United States needs FCC authorization -- see FCC certification for electronics. Range problems, incidentally, are usually mechanical rather than firmware issues; antenna design for wireless products explains why a ground plane or a metal bracket can cost you half your range.

Budget and schedule expectations

For a straightforward sensor or controller with a clean GATT profile, notifications, and a bootloader, BLE firmware typically lands in the low tens of thousands of dollars. Costs climb when you add multi-role operation, encrypted OTA, aggressive power targets that require measurement-driven tuning, or a certification path with a custom RF front end. The corresponding app work is priced separately, and BLE app development cost covers that side.

Get the profile right before the schematic freezes

The cheapest moment to fix a GATT design, an advertising strategy, or a power budget is before the board is laid out and before the app team writes its first connection handler. Projects House develops BLE firmware alongside the electronics and the companion app, so those three decisions get made once. Tell us about your product through the contact form and we will review your radio, power, and profile assumptions with you.