Why Every Firmware Engineer Should Learn the Basics of RF

Firmware engineers learning RF fundamentals to build better wireless embedded systems

Your BLE device works perfectly on the bench. Push it across the room, it drops. Take it outside, it’s dead at 8 meters. You scope the SPI lines to the radio: clean. You check the stack logs: connection terminated, reason 0x22 (LL response timeout). You stare at it.

There’s no logic analyzer for the layer where this bug actually lives. The radio waves between your antenna and the gateway aren’t in your traces, your registers, or your debugger. And your CS degree didn’t cover them.

This is the gap. If you ship wireless products and you can’t reason about what happens after the bits leave the MAC, you’re going to spend a lot of time guessing. The good news: you don’t need to become an RF engineer. You need maybe 30 hours of study to cover the 5 concepts that resolve 80% of the day-to-day questions. Here’s the case for doing it, and the roadmap.

The RF Engineering Shortage Is Real

Walk into any wireless hardware company and ask about hiring RF engineers. You’ll get a tired laugh.

The pipeline is thin. Most universities cut deep analog and RF coursework decades ago in favor of digital and software. The senior RF folks who designed the first generation of cellular and Wi-Fi silicon are retiring. IEEE has been ringing this bell for years.

Demand is going the other way. BLE is in every consumer product. Cellular IoT (LTE-M, NB-IoT) is shipping in volume. Matter, Thread, UWB, LoRa, satellite IoT, mmWave radar in cars. Every one of these products needs someone who understands both firmware and what the radio is actually doing.

So the work has rolled downhill. Firmware engineers are now expected to own integration questions that used to belong to a dedicated RF team: antenna placement reviews, regulatory configuration, range debugging, coexistence tuning. Often there is no RF team. There’s a contractor who comes in for 2 weeks before FCC submission, and you.

That’s leverage. Firmware engineers who can also talk fluently about link budget and antenna detuning are rare, and it’s learnable. Most firmware engineers I know who picked up RF basics did it in a few weekends and a handful of project debuggings.

Why Firmware Choices Are RF Choices

Here’s the part that surprises people. Even when the radio is a sealed module with an AT command interface, your firmware is making RF decisions constantly.

+--------------------------+
|   Application Firmware   |
+--------------------------+
|   Protocol Stack (BLE)   |  <-- you live here
+--------------------------+
|   MAC / PHY Driver       |  <-- you touch here
+--------------------------+
|   Radio IC + Matching    |  <-- RF starts
+--------------------------+
|   Antenna + Enclosure    |  <-- pure RF
+--------------------------+

A few examples worth internalizing:

  • TX power and duty cycling. Going from 0 dBm to +8 dBm means +3 dB doubles, +6 dB quadruples, and +8 dB lands at about 6.3x the transmit current. It also might push you over regulatory effective radiated power limits depending on antenna gain. Both knobs live in firmware.
  • Packet size and retries. Bigger packets mean more time on air. More time on air means more chances for a bit error. On noisy channels your retry logic can collapse effective throughput to near zero. The fix is sometimes “make the packets smaller,” which is a firmware change driven by an RF reality.
  • Sleep/wake timing. Connection intervals, supervision timeouts, and PHY switching all interact with how forgiving your link is to interference. Aggressive power saving often shows up as “intermittent disconnects in the warehouse.”
  • Channel selection and coexistence. BLE and Wi-Fi share 2.4 GHz. If your firmware doesn’t blocklist channels overlapping nearby Wi-Fi APs, you get mystery packet loss in offices and not in your lab.
  • Region builds. FCC, ETSI, and Japan’s MIC have different rules. Sub-GHz duty cycle limits in the EU are enforced in firmware, not magic. Ship the wrong build to the wrong region and you fail certification.

You don’t need Maxwell’s equations. You need to know the layer exists.

The Five Concepts That Cover 80% of What You Need

1. dB Math

Every RF datasheet and every conversation with an RF engineer is in decibels. Decibels are logarithmic, which is why “+3 dB” keeps showing up: it’s a doubling.

+3 dB  = 2x power      -3 dB  = 1/2 power
+10 dB = 10x power     -10 dB = 1/10 power
+20 dB = 100x power    -20 dB = 1/100 power

dBm is power referenced to 1 milliwatt. 0 dBm = 1 mW. +20 dBm = 100 mW. dBi is antenna gain referenced to an ideal isotropic radiator. You add and subtract dB values like regular numbers, and that’s the whole point: multiplication becomes addition.

Memorize the table above. You’ll use it weekly.

2. Link Budget Basics

A link budget is the single most useful tool in your new kit. It tells you whether a radio link should work, given the physics. You add up everything that helps the signal and subtract everything that hurts it.

TX Power     +4 dBm
TX Ant Gain  +2 dBi
Path Loss   -80 dB    (free space, 2.4 GHz, ~10 m)
RX Ant Gain  +2 dBi
-----------------
RX Signal   -72 dBm
RX Sens     -95 dBm
-----------------
Margin       23 dB   ✓

23 dB of margin is healthy. Below 10 dB, you’ll see issues at edge cases (orientation, body blocking, a metal shelf in the way). Below 0 dB, the link can’t close.

When a customer says “it doesn’t work past 15 meters,” your first move is to redo this calculation with their actual conditions. 9 times out of 10 the answer is right there: not enough margin for the environment. You either need more TX power, a better antenna, a more sensitive receiver (slower PHY), or a closer gateway.

Hubble’s transmission guidance docs walk through how this math plays out for BLE-to-satellite and BLE-to-terrestrial links, where path loss can be enormous and every dB matters.

3. Antennas: Just Enough to Not Break Them

You don’t need to design antennas. You need to not destroy the one your hardware team designed.

The big rules:

  • Ground plane matters. Most chip antennas need a specific ground plane size and shape. Shrink it, and the antenna detunes. Resonant frequency moves, gain drops, range collapses.
  • Keepout zones are real. Metal traces, batteries, LCDs, and shielding cans inside the keepout will couple energy and detune the antenna. “We just moved the battery 3 mm” is a real RF bug.
  • Enclosures count. Plastic is mostly fine. Metal is mostly not. Painted enclosures sometimes contain metallic pigments that wreck performance. Always test in the production housing, not the dev kit.
  • Radiation patterns aren’t spheres. A real antenna has nulls (directions where it barely radiates). If your product is wall-mounted with the null pointing at the gateway, no firmware change will save you.

When the hardware engineer hands you a board, ask: what’s the antenna, where’s its keepout, and have we tested in the final enclosure? You’ll sound like you know what you’re doing because you do.

4. Modulation and Protocol Tradeoffs

The 3-way tradeoff in any radio link: data rate, range, power. Pick 2.

  • BLE 1M PHY: balanced default, ~-95 dBm sensitivity.
  • BLE Coded PHY (S=8): ~12 dB more sensitivity (4x range in free space) at 1/8 the data rate.
  • LoRa: designed for kilometers. Data rates measured in hundreds of bits per second.
  • Wi-Fi: fast, hungry, short range relative to power consumed.
  • LTE-M / NB-IoT: cellular range, cellular power budgets, cellular complexity.

You don’t need to know the math behind chirp spread spectrum or OFDM. You need to know that switching to Coded PHY trades throughput for range, and when that trade makes sense for your product. Protocol selection is a product decision firmware engineers should be loud in.

5. Regulatory Awareness

You will run into FCC Part 15 (US), ETSI EN 300 328 (EU 2.4 GHz), and region-specific rules in Japan, Korea, and China. The ones that bite firmware:

  • Maximum effective radiated power. TX power + antenna gain. Your firmware setting can violate this.
  • Duty cycle limits. EU sub-GHz bands cap how much of each hour you can transmit. Firmware enforces this. Get it wrong, fail certification.
  • Listen-before-talk. Some bands require you to check the channel before transmitting.
  • Frequency hopping requirements. BLE handles this for you. Custom proprietary protocols on 2.4 GHz often don’t, and you’ll need to implement it.

Read the relevant sections once. They’re shorter than you think.

A 30-Day Learning Plan 

[ ] Week 1: dB math + read your radio's datasheet end to end
[ ] Week 2: Build a link budget for your current product
[ ] Week 3: Audit antenna placement with your HW team
[ ] Week 4: Review regulatory limits for your shipping regions

Concrete starting points:

  • Microwaves101 for dB math and link budget reference. It’s free and not pretending to be a textbook.
  • Your radio’s datasheet. Yes, all of it. The Nordic nRF52 or TI CC2340 datasheets are excellent introductions to a real radio.
  • Bluetooth SIG Core Spec PHY sections if you work in BLE. Skim, don’t memorize.
  • FCC Part 15 Subpart C and ETSI EN 300 328 for regulatory.
  • ARRL Handbook antenna chapters, free online, canonical.

If you build on the Hubble Device SDK, reading through the advertising packet structure and transmission timing is a good practical exercise: it’s a real-world example of how firmware-side decisions (when to transmit, on what channels, with what payload) are RF decisions in disguise.

Build One Link Budget This Week

Engineers who write solid firmware and can also reason about RF are rare, and the senior generation is retiring. You don’t need to be great at this. You need to be competent enough that when the radio misbehaves, you have a framework instead of a shrug.

Pick one concept from above. Build a link budget for the product on your desk right now. Compare the result to what you actually see in the field. If those two numbers disagree, you’ve just found something worth understanding, and you’re already further along than most of your peers.

Hubble Network connects devices to satellites using standard Bluetooth radios, no custom RF hardware required. See how it works →