Ever tried to pair a Bluetooth gadget and wished you had your own private wireless network instead? We did. So we built a custom ultra-low-power transceiver board using an STM32U599 microcontroller and a CC1101 RF transceiver. This article dives into why we ditched BLE, Wi-Fi, and LoRa for a homegrown RF stack, and how this combo delivers sub-GHz magic on a tiny power budget. Along the way, we’ll highlight the board’s design choices – from the CC1101’s sleepy efficiency to the STM32U5’s cryptographic brawn – with a dash of humor for every engineer who has cursed at a fickle wireless protocol.

The custom ultra-low-power transceiver board (rendered above) packs the STM32U599 microcontroller (large BGA chip at center) and the CC1101 RF transceiver (smaller chip near the antenna connector on the right). A USB C port (left) and an SMA antenna jack (right) hint at its role as a versatile wireless node. The design includes a microSD slot and plenty of supporting circuitry, all in a compact layout.

 

Ditching BLE, Wi-Fi, and LoRa: Why Go Custom?

Why not just use Bluetooth Low Energy, Wi-Fi, LoRa, or some off-the-shelf module? In theory, those standards should cover most needs. In practice, each came with deal-breakers for our ultra-low-power, no-hassle goal:

• BLE (Bluetooth Low Energy): Great for short-range and low energy when connected, but anyone who’s wrestled with BLE pairing can relate – sometimes it’s neither easy nor energy-efficient. We’ve spent too many afternoons staring at a blinking LED hoping our phone finds the device. BLE also typically operates at 2.4 GHz, which means limited range in open fields and interference from microwaves, Wi-Fi, and every other gadget. It’s fine for your smart watch, not as great for a distant sensor in a cornfield. In short, we wanted something more predictable and longer range (and to never see a “Connection Failed” popup again).
• Wi-Fi: If BLE is a picky toddler, Wi-Fi is a hungry teenager. The power budget of Wi-Fi is horrifying for battery-powered devices – we’re talking tens to hundreds of milliamps just to stay connected. In many IoT designs, Wi-Fi can gobble up ~75% of the entire power usage (Mitigating Battery Waste in IoT: The Crucial Role of Ultra-Low Power Wi-Fi Connectivity Chips). Sure, Wi-Fi gives you range (within a hotspot) and high bandwidth, but we don’t need to stream Netflix from a soil moisture sensor. The final straw? The complexity and overhead of maintaining a Wi-Fi connection (handshakes, network setup, etc.) felt like using a bulldozer to plant a flower.
• LoRa: LoRa was very tempting – long range, sub-GHz, made for IoT. But then we checked the throughput. A blazing maximum of around 27 kbps on a good day (Worth noting that the maximum bitrate of the base LoRa encoding is not going to … | Hacker News)! That’s kilobits. With LoRaWAN duty cycle limits, it’s like communicating via carrier pigeon: extremely far, but extremely slow. For many sensors that’s okay, but our applications include not just tiny telemetry packets but maybe occasional bursts of data or faster polling. We also didn’t want to be tied to LoRaWAN network servers or gateways for all deployments. LoRa’s fantastic for some cases, but here we wanted more control over the trade-off between data rate and power.

Bottom line: We craved a wireless solution that we could tune like a radio (pun intended) to our needs – ultra-low-power sleep, decent data rate when awake, good range, and no dependency on someone else’s standard. By going custom with the CC1101 transceiver, we get to be the master of our own RF protocol. No mandatory pairing rituals, no router SSIDs, no network join procedures – just turn on, speak (in packets), and turn off.

 

The CC1101 Transceiver: Sub-GHz Sorcery on a Power Budget

If our board were a buddy-cop movie, the CC1101 is the low-profile specialist who “works in the shadows” (sub-GHz frequencies) with ninja-like power consumption. We chose the Texas Instruments CC1101 for its unique strengths that perfectly fit our custom RF stack mission:

• Sub-GHz for the Win: The CC1101 operates in the sub-1 GHz ISM bands (commonly 315, 433, 868, 915 MHz). These lower frequencies travel farther and penetrate obstacles better than 2.4 GHz signals (Sub-GHz vs 2.4 GHz Communication – ShortLink). In practical terms, that means our sensors deep in a building or spread across a farm can actually reach the base station without needing a mesh network or signal repeaters. No more signal dying because a cow stood in the way – sub-GHz goes around and through things where higher frequencie struggle.
• Flexible Modulation Support: This chip isn’t married to a single modulation. It fluently speaks 2-FSK, 4-FSK, GFSK (Gaussian FSK), and even OOK (on-off keying) and ASK, plus MSK for good measure. That’s like having both AM and FM radio in one. We can trade data rate, range, and robustness by configuring modulation and data rate as we see fit. Want very low bitrate but rock-solid range? Use a narrowband FSK with a tiny data rate. Need faster transfers? Bump up to GFSK at a higher rate. The CC1101 supports data rates from a pokey 0.6 kbps up to a snappy 600 kbps, covering both extremes of long-range-low-speed and short-range-higher-speed scenarios. This flexibility is a huge reason we rolled our own stack – we’re not stuck with Bluetooth’s 1 Mbps or LoRa’s chirps; we dial in what we need.
• Ultra-Low Power Modes: Here’s where the CC1101 is downright awesome. In its deepest sleep state, it draws about 200 nA (yes, nanoamps!) of current. That’s effectively zero – you’d have to wait over a decade to drain a coin cell at that rate. It can wake up from sleep to active RX or TX in just 240 μs, so it doesn’t waste time groggily booting up. For periodic listening without staying fully on, it has a wake-on-radio feature: the CC1101 can periodically sniff the air for a preamble while the MCU sleeps. In this low-power RX polling mode, it draws on the order of only ~8–9 μA on average – basically nothing for a battery. By using wake-on-radio, our custom protocol can let the radio sleep most of the time and just peek out briefly to check if anyone’s calling. This beats the pants off a typical Wi-Fi or BLE idle where something is always drawing power to stay connected. We’re essentially getting the best of both worlds: very low duty-cycle listening like LoRa, but under our control.
• Built-in Packet Handling and SPI Control: Making a custom RF stack from scratch is non-trivial, but the CC1101 helps a ton by providing hardware support for packet-oriented communication. It has built-in FIFO buffers (64 bytes each for RX and TX) and can do preamble detection, sync word detection, CRC calculation, clear channel assessment, link quality indication – all in silicon (cc1101.pdf). This means our STM32U5 doesn’t have to bit-bang every raw symbol; the CC1101 handles a lot of the grunt work of framing the data. We interact with it over a simple SPI interface – all the radio’s registers and its FIFO are accessible via SPI, and we can even batch-configure them in one burst write (cc1101.pdf). In other words, high configurability with low overhead. We get to define our packet format and timing, but we aren’t rewriting all the radio logic from scratch – CC1101 gives a nice toolbox to build on. It’s like getting a semi-custom radio kit: you decide the protocol, it handles the RF details.
• Decent Output Power & Range: Out of the box, CC1101 can transmit up to +12 dBm (about 15 mW), which is plenty for moderate-range applications in our target bands. With good antennas and low-noise floors, a few kilometers line-of-sight is achievable. And if we ever need more range, TI offers a matching range extender (CC1190) to boost this to +20 dBm or more. It’s nice to have that upgrade path while staying in control of the protocol.

In short, the CC1101 is our secret sauce for going custom: it’s as power-frugal and versatile as advertised. We can program it to act like our own private LoRa-ish network, or a souped-up wireless UART, or anything in between. No association requests, no Wi-Fi beacons – just pure, under-our-control RF goodness.

 

STM32U599 in BGA: The Mighty (Yet Low-Power) Brain

Of course, a smart transceiver needs an equally smart brain behind it. Enter the STM32U599 – a microcontroller that’s as comfortable sipping nanoamps as it is crunching encryption algorithms. We picked this 32-bit MCU in BGA package for several reasons:

• Serious Horsepower, Tiny Package: This ultra-low-power MCU runs an Arm Cortex-M33 core at up to 160 MHz, complete with DSP instructions and a floating-point unit. In plain terms: it can process real-time data like sensor readings or run complex signal processing on incoming packets without breaking a sweat. The BGA form factor means we get tons of I/O and features (this chip can have up to 156 pins available) in a very small footprint – perfect for our board size. Yes, BGAs are a bit scary to solder, but the trade-off is a compact powerhouse at the center of our board.
• Ultra-Low-Power Expertise: Despite the performance, the STM32U5 is part of ST’s ultra-low-power lineup. It’s the kind of chip that can nap like a cat. In Standby mode (with context and registers retained), it draws on the order of 200 nA – that’s in the same ballpark as the CC1101’s sleep current! Even with the RTC running for timed wakeups, it’s under 0.5μA. In Stop modes, where some SRAM and peripherals stay powered, we’re still talking only a few microamps . This is hugely important: there’s no point having a 200 nA radio if your MCU burns 50 μA while sleeping. With the STM32U599, our entire system can hit the snooze button and barely sip power. When running, it’s also efficient – around 18.5 μA per MHz – so even moderate active periods won’t drain the battery too fast. The synergy between this MCU and the CC1101 means we can design aggressive sleep-wake cycles for maximum battery life.
• Security and Cryptography Built-In: The “U” in STM32U5 might as well stand for ultra-secure. This MCU comes with Arm TrustZone technology, allowing us to partition secure and non-secure code, which is great for protecting firmware or encryption keys. It also packs hardware cryptographic accelerators – AES encryption, HASH functions, true random number generator, and even a public-key accelerator (PKA) – all on-chip. In practice, this means we can implement strong encryption/authentication for our custom RF protocol (if we want) without tanking the CPU or power budget. The chip is designed with a root of trust and secure boot features, so if we ever deploy this commercially, we can ensure only authorized firmware runs. It’s like having a security co-processor for free. In a world increasingly conscious of IoT security, this is a big plus for our custom solution over a quick-and-dirty RF link.
• Plentiful Memory & Peripherals: The STM32U599 isn’t stingy on resources. We have multiple megabytes of Flash (up to 4 MB) and a couple megabytes of SRAM on this tiny chip. That’s enough to log data, run an RTOS, and buffer plenty of RF packets. It’s almost overkill for a sensor node – and we love it. We can double-buffer transmissions or store weeks of sensor readings if needed. Plus, this MCU gives us peripheral options galore: high-speed USB (handy for a debug/programming port), I²C, SPI (talking to our CC1101), ADCs for sensors, and even a built-in USB Type-C power delivery controller if we get fancy. The BGA package variant we chose exposes more of these goodies (including a SDMMC interface for the SD card). Essentially, the STM32U5 turned our board not just into a radio node, but a capable computing platform. We can collect data, encrypt or compress it, and make on-the-fly decisions (edge computing!) before using the CC1101 to transmit.
• Real-Time, Real Control: Unlike using a Linux-based module or something, a microcontroller gives us real-time determinism. The STM32U599 can handle precise timing – for instance, toggling the CC1101 into TX mode at exactly the right time slot, or sampling a sensor exactly every 10 seconds – without being at the mercy of a big OS. This tight timing control is crucial when you’re running a custom RF stack; we can meet protocol timing requirements (like inter-packet spacing, acknowledgments, etc.) reliably. The MCU’s high speed also means if we want to implement clever power-saving strategies (e.g., dynamically adjusting the RF data rate or doing local sensor data analysis to reduce transmissions), we have the headroom to do so.

And did we mention it’s all in a tiny BGA? Looking at the board, that gray square chip in the middle is the STM32U5 – not much larger than a fingernail – yet it’s orchestrating this entire symphony of low-power wireless communication. It’s a bit ironic: we went with a cutting-edge microcontroller partly to run an old-school simple custom protocol. But that’s the beauty of it – we have headroom to spare, which means this board isn’t a one-trick pony. It can be re-programmed to do a lot more than just forward sensor data (more on that soon).

(Yes, we had minor heart palpitations soldering the BGA. No, we don’t regret it.)

 

SD Card Slot: Because Logging and Updates Matter

One somewhat unusual feature on our board, given its low-power wireless focus, is the microSD card slot. You might ask, why does a tiny RF node need potentially gigabytes of storage? Turns out, there are some compelling reasons we included removable storage:

• Data Logging: For many use cases (environmental sensors, wildlife trackers, etc.), you might collect far more data than you can transmit frequently. An SD card allows the node to log high-resolution data locally over a long period. For example, a weather station could record detailed readings every minute to the SD card, but only send out summaries or critical alerts via radio due to bandwidth or power constraints. Later, you could physically retrieve the card or download the bulk data when convenient. This way, no data is lost due to radio limits – the SD acts as a black box recorder.
• Event Buffering & Store-and-Forward: Our custom RF network might not be always on. Suppose a field node only connects to the base station once an hour (to save power). The SD card can buffer sensor readings or user inputs in between those check-ins. If the node goes out of range or the network is down temporarily, it can queue up messages on the SD and transmit them when back in range. This adds reliability to deployments in patchy connectivity: the SD card is our node’s memory of what happened while the RF link was asleep.
• Over-the-Air (OTA) Updates Storage: Pushing a firmware update over a low- bandwidth link is tricky – you might not want to apply it on the fly. With ample storage, we can send an update in chunks, verify the complete file on the SD card, then apply the update. The STM32U5 even supports secure firmware upgrade mechanisms , which we can leverage by storing the new firmware image on the SD card first. This makes OTA updates safer – if a transmission fails halfway, the node still runs the old firmware and can retry downloading the rest later.
• Diagnostics and Debugging: In deployment, things can go wrong that are hard to capture over the air (especially if your wireless link is the thing misbehaving!). We can log diagnostic info to the SD card – error codes, RF signal stats, sensor values – which can be retrieved later for analysis. Think of it like an airplane’s flight recorder for our sensor node. It’s especially useful during development: we can deploy the node in a real environment, then pull the SD card to see a detailed history of what it experienced.
• Flexibility and Future Uses: We don’t have to populate the SD slot for every build, but having it there means this board can double as a general data logger or even a tiny server. For example, with a firmware tweak, it could collect data from other devices and save them. Or one could use the SD to store a local database of sensor thresholds, images (yes, the STM32U5 could even log pictures from a camera), or configuration files that are too large to keep in flash.

And let’s be honest: there’s something comforting about good old removable storage. It’s like giving our cutting-edge RF board a little diary to write in. If all else fails, we can still get the data the old-fashioned way. The power impact of the SD card is minimal because we only mount and write to it when needed (and the rest of the time, the card can be completely unpowered). With proper file system management and using the low-power capabilities of the MCU’s SD interface, the SD card sleeps most of the time too.

So yes, we put a microSD slot on an ultra-low-power wireless board – and we’re pretty sure future us (or other users of the board) will thank us for it when they have that crucial log of events or an easy path for updates.

 

One Board, Many Uses: From Forests to Factories

We designed this custom board as a kind of chameleon. Thanks to its flexibility, it can wear  many hats in the wild world of IoT and embedded systems. Here are just a few use cases we envision for the STM32U599 + CC1101 board:

• Remote Field Sensor Nodes: Imagine environmental monitoring stations scattered in a forest or on a farm. This board can read sensors (temperature, humidity, soil moisture, you name it) and broadcast data back periodically. With the ultra-low-power sleep, it can run on a small battery or solar cell for years. Sub-GHz RF means it can cover long distances through trees or hills. No cell towers or Wi-Fi needed in your cornfild – the nodes form their own network. And if a node has to log high-res data (rainfall every second during a storm), that microSD has it covered until it sends a summary.
• Telemetry Modules for Gadgets & Vehicles: Need to get data from point A to point B reliably? Slap this board on. Drones, RC vehicles, weather balloons, industrial machines – they can all use a custom telemetry link. For example, you could use the CC1101 link to send real-time data from a drone to a ground station, avoiding the congestion of 2.4 GHz RC channels. With the STM32’s processing, the module can also compress or encrypt that telemetry on the fly. Unlike off-the-shelf radios, you can tweak the protocol for your latency or range needs. Plus, no licensing fees or proprietary constraints – it’s all your code.
• Offline IoT Devices: Not every “Internet” of Things device needs to be on the actual Internet 24/7. Some deployments prefer a closed network for reliability or security. This board can act as an offline IoT endpoint, where devices talk to each other or to a central logger without any cloud. Think of a mining site deep underground: Wi-Fi or cellular might not penetrate, but a custom sub-GHz network could link sensors and equipment. Each device collects data and perhaps only occasionally does someone go collect the SD cards or bring a gateway node in range. It’s IoT on your terms, independent of infrastructure.
• Smart Agriculture Endpoints: Agriculture tech is a perfect playground for this board. You can monitor soil conditions, control irrigation valves, track livestock with collars – all with devices based on this design. The long range covers wide fields, the low power means devices won’t exhaust their batteries before harvest season, and the custom protocol avoids interference with other farm equipment. You could even set up a mesh or star network across a ranch. And if one day the farm wants to upgrade, the STM32U5 has the headroom to add more smarts (maybe some edge AI to detect pests via sensors?) without needing new hardware.
• Security and Alarm Systems: The CC1101 is actually used often in security sensors (motion detectors, door/window sensors) because of its low-power profile. Our board could serve as a highly secure sensor/transmitter for alarm systems that require encryption and quick responsiveness. The STM32’s TrustZone and crypto mean even a tech-savvy intruder would have a hard time spoofing or eavesdropping on the signals. Meanwhile, battery-powered sensors can last ages. Your future smart home’s obscure wireless sensors for that custom panic room could run on this (for the imaginative among us).
• Prototyping & Research: This board is also an engineering tool. Maybe you’re a researcher testing a new wireless protocol or an engineer prototyping an idea that doesn’t fit standard radios. Having a fully programmable radio+MCU platform lets you experiment: try a new modulation scheme, implement a custom MAC layer for ultra-reliable low-latency transmission, or study power consumption in various modes. The board can be a baseline module that you tweak in software to rapidly evaluate concepts. It’s like having a software-defined radio but in embedded form and battery-friendly. From university labs to hobbyists, a device like this encourages learning by doing – you can literally create your own networking stack and see it work in the real world.

These are just a few scenarios – in reality, when you give engineers a hammer (an extremely flexible one at that), they’ll find nails you never thought of. The key point is that our custom design isn’t locked into one application. Power, range, and control are universally useful. By adjusting the firmware, the same hardware can be redeployed from tracking weather on a mountaintop to monitoring machines in a factory. This versatility makes it not just a project-specific board, but a platform.

 

When Going Custom Beats Off-the-Shelf

Building a custom RF stack and hardware is definitely more work than using a pre-made module – so it’s fair to ask, when is it worth it? Based on our journey, the answer boils down to when power, control, and independence truly matter.

• Power Efficiency Above All: If you’re aiming for multi-year battery life or very small power sources, every microamp counts. Standard protocols often have background chatter or forced handshake routines that you can’t remove. A custom solution lets you strip communication down to the bare essentials. For instance, we can program the CC1101 to wake up, send a 10-byte packet, and sleep – with no additional overhead. No unnecessary advertising, no TCP/IP keep-alives, nothing. This kind of optimization can mean the difference between a sensor lasting 6 months on a battery versus 6 years. When you control the stack, you control the power budget at every layer.
• Total Control Over Protocol: Ever been frustrated that a wireless protocol doesn’t do exactly what you want? (Looking at you, BLE, with your connection intervals and pairing modes…) Going custom means if you want something weird, you can have it. Want each node to use a custom spreading code? Go for it. Need to embed sensor type in the preamble? Sure. Our board basically gives the RF legos to build whatever protocol suits the application. This is crucial for deployment independence too – we aren’t tied to Bluetooth SIG updates or Wi-Fi alliance certifications. We make the rules. For niche applications, this is a godsend. No standard protocol for underwater basket-weaving sensors? Make your own!
• Independence from Infrastructure: Perhaps you’re deploying sensors in an area without cellular or Wi-Fi coverage, or you don’t want the hassle/cost of setting up gateways for LoRaWAN. With custom radios, the devices talk to each other or a central hub that you control. There’s a certain robustness in not relying on any third-party services or crowded spectrum. Our system doesn’t need the internet – but we could hook it to one if we choose. This independence also means longevity: if a standard goes obsolete or changes, our devices don’t care. We’ll still be happily communicating on our chosen frequency, protocol intact.
• Enhanced Security or Custom Encryption: Sometimes you need to roll your own protocol for security by obscurity or because standard encryption isn’t enough or suitable. With the STM32U5’s crypto, we can implement end-to-end encryption tailored to our needs (e.g., a lightweight scheme for tiny packets). We’re not limited to WPA2 or BLE’s pairing process. In scenarios like defense or proprietary industrial systems, having a unique protocol can be an extra hurdle for attackers. And with our hardware’s security features, we can ensure even if someone gets a hold of a node, extracting keys or firmware is extremely difficult.
• Performance Tuning: A custom solution can be tuned for either ultra-low latency or maximum throughput or ultra-long range – or a balance – depending on what matters. Standards have to generalize; we can specialize. For example, if we need just one-way broadcast with no ACK to minimize power, we can do that. Or if we prefer a quick ping-pong exchange for time-critical data, we can structure that at the protocol level. This kind of tuning can improve user experience (e.g., faster response, less battery drain) in ways a one-size-fits-all protocol might not achieve.

All that said, going custom is an engineering investment. It’s not the path to choose for a one-off blinking gizmo or when Wi-Fi/BLE would do the job adequately. But for those willing to put in the development effort, the payoff is a solution precisely tailored to the problem, often with better longevity and lower recurring costs (no radios modules to buy, no subscriptions). We found the process rewarding – it’s not every day you get to play RF engineer and protocol designer in one project, and come out with a working system!

Plus, there’s the undeniable geek cred of being able to say, “Oh that? It’s running a custom RF protocol I developed,” next time someone asks why your device doesn’t show up on their phone’s Bluetooth list.

 

From Prototype to Product: An Engineer’s Playground

We’ve talked about this board in the context of our project, but it’s more than a one-off prototype. We deliberately engineered it to be a reusable module – something that could scale from the workbench to real-world deployments:

• Engineering Tool: As mentioned, the board can serve as a development platform for all kinds of wireless experimentation. With full access to the MCU and RF, an engineer can tweak everything from radio frequencies to CPU clock speeds. The USB interface on our board allows easy reflashing and PC connectivity (for debugging or acting as a gateway). Whether you’re profiling power consumption or trying out a new idea for an ad-hoc network, this board is a handy tool to have in your arsenal.
• Rapid Prototyping Platform: Got an idea for a new sensor network or gadget? You can prototype it on this board faster than designing a new PCB from scratch. Hook up sensors to the GPIOs, write some firmware, and you have a proof-of-concept device ready. The combination of an STM32 (which is widely supported by
  development tools and community code) and a popular TI RF chip means you can leverage tons of existing libraries. We’ve essentially done the hardware integration part, so others can focus on the application. This could accelerate development cycles for startups or research projects that need custom wireless tech.
• Path to Production: We didn’t slap “3FD” on the PCB in that render just for fun – we envision that a refined version of this board could become a commercial module. The design could be made into a small module or integrated core for products. Because we chose components that have long-term availability (both STM32U5 and CC1101 are from major families likely to be around for a while), the design is viable
  for production. The BGA MCU and QFN RF chip keep it compact enough to embed in larger systems. We also included ESD protection, proper RF filtering, and power management on the board with real-world use in mind. In essence, it’s not just a lab experiment; it’s built to be robust.
• Scalability: Since it’s a custom solution, adding more nodes or adapting to new frequencies (within those sub-GHz ranges) is just a matter of configuration. We could spin off variants – say, one optimized for 915 MHz and one for 433 MHz, to satisfy different regional requirements – without a complete redesign. The firmware can also be updated to support new features or protocols as needs evolve (thanks to that OTA update capability via SD). This board could live a long life, evolving through software updates even as new ideas come along.

To wrap up, our custom STM32U599 + CC1101 transceiver board is a little testament to the idea that sometimes you have to build it yourself. We bypassed the headaches of BLE pairing, the battery drain of Wi-Fi, and the throttle of LoRa’s low data rate – and in return, we gained a platform that we control end-to-end. It’s been a fun ride, with challenges ranging from RF matching to writing a MAC layer, but the result is deeply satisfying: a versatile, ultra-low-power wireless board that feels like an extension of our engineering imagination.

So, the next time you find yourself cursing at a “standard” wireless solution that just won’t do what you need, remember: there’s always the custom route. It might require a bit of soldering, a stack of datasheets, and a willingness to reinvent a few wheels – but you just might end up with exactly the vehicle you want (and learn a ton along the way). As for us, we’ll be out in the field, deploying our bespoke RF nodes and enjoying the sweet sound of packets flying through the air on our terms – no app, no dongle, no cloud required. Happy hacking!