The Empty PCB: Achieving Radical Simplicity with the IN120 SoC

Look at a typical BLE beacon reference design. Count the components. There’s the SoC, of course. Then the 32 MHz crystal. The 32.768 kHz crystal. Decoupling capacitors, three, maybe four. A flash chip for firmware storage. An inductor or two for the DC-DC converter. Matching network for the antenna. A few more passives scattered around for good measure. All told, you’re looking at 15 to 25 components on the board, a firmware development cycle measured in months, and a BOM that makes product owners flinch every time they run the unit economics on a disposable product.

Picture a PCB with almost nothing on it. One chip. A handful of passives. An antenna trace etched into the board itself. That’s it. That’s the whole product.

The gap between those two boards isn’t just a few components. It’s the gap between an architecture designed for complex applications being shoehorned into a simple one, and an architecture designed for the actual job. For anyone building ultra-simple Bluetooth LE beacons (smart labels, disposable wearables, asset tags, cold chain sensors) that gap represents wasted money, wasted time, and unnecessary risk at every stage from prototype to production.

The Pain Catalog: What Traditional BLE SoCs Actually Cost You

Let’s walk through the real costs of using a general-purpose Bluetooth LE SoC for a product whose entire job is to broadcast a few bytes at a set interval.

Firmware overhead you can’t escape. Even the simplest beacon needs a BLE stack. That means an SDK, a toolchain, a build environment, and a developer who knows how to configure advertising parameters, set up power management, and handle edge cases like clock drift and watchdog timers. You’re writing, testing, and validating firmware for a device that does one thing. On a Nordic nRF52 or TI CC26xx, the “simple” beacon example project still pulls in thousands of lines of stack code. You need to understand it well enough to own it, because when something breaks at 3 AM in a factory in Shenzhen, it’s your problem.

BOM bloat that kills margins. A conventional BLE SoC beacon reference design typically calls for an external 32 MHz crystal ($0.10–$0.30), a 32.768 kHz crystal ($0.08–$0.15), 3–5 decoupling capacitors, flash memory for firmware storage, and an inductor for the power supply. These seem trivial individually. At 100,000 units, an extra $0.50 in components is $50,000. At a million units, it’s half a million dollars, and that’s before you account for placement costs, solder paste, and the yield implications of every additional component on the board.

PCB real estate you don’t have. Smart labels are thin. Disposable wearable bands are narrow. Asset tags need to fit inside adhesive housings or be small enough to attach unobtrusively. Every crystal, every capacitor, every IC competes for space that’s already spoken for by the antenna, the battery, and the mechanical constraints of the enclosure. Two crystals alone can eat 4–6 mm² of board space that a coin-cell-powered label simply can’t spare.

Reliability anxiety that scales with volume. Firmware means bugs. Every embedded engineer knows this. In a product with a screen and a Bluetooth connection to a phone, you can push an OTA update. In a disposable smart label stuck to a pallet in a warehouse? There is no update path. A firmware defect discovered after 500,000 units ship means a recall, a write-off, or silent failure where tags stop advertising and nobody notices until the data goes missing. This isn’t hypothetical. It’s the scenario that keeps quality engineers awake.

Development timelines that don’t match the product’s simplicity. A competent embedded team needs 8 to 16 weeks to take a new BLE SoC from evaluation board to production-ready firmware, even for a beacon. Add certification testing, power profiling, and manufacturing test development, and you’re looking at four to six months before the first production unit ships. For a product that broadcasts a static or semi-static payload, this timeline is hard to justify to anyone holding a budget.

Power budgets that punish complexity. Disposable products run on CR2032 coin cells or, increasingly, on printed batteries with capacities under 30 mAh. A general-purpose SoC running a real-time operating system, clocking off an external crystal, and managing firmware-driven sleep/wake cycles draws more current than the application demands. Every microamp matters when the battery can’t be replaced.

To be clear: parts like the Nordic nRF52 and nRF54 series, the Renesas (Dialog) DA14xxx SmartBond line, and TI’s CC26xx family are excellent, well-supported Bluetooth LE SoCs. Their SDKs are mature. Their ecosystems are rich. They’re the right choice for connected devices that need complex application logic, GATT services, mesh networking, or OTA updates. But that’s precisely the problem. Using one for a beacon that advertises a payload every second is using a laptop as a doorstop. It works, but the mismatch costs you at every level.

A Different Architecture: The InPlay IN120 NanoBeacon Approach

The InPlay IN120 NanoBeacon is a Bluetooth LE SoC built on a fundamentally different premise: that for beacon applications, firmware is overhead, not value.

The IN120 has no user-programmable CPU in the traditional sense. There’s no SDK. No toolchain. No compiled firmware binary. Instead, the chip’s entire behavior (advertising interval, TX power, payload content, sensor integration, power modes) is defined through configuration registers stored in on-chip OTP (one-time programmable) memory. You set these parameters using InPlay’s NanoBeacon Config Tool, a GUI application. You click, you configure, you validate, you burn. The chip boots and beacons. That’s the entire development cycle.

This isn’t a limitation masquerading as a feature. For a device whose entire purpose is broadcasting BLE advertisements, removing the firmware layer removes the single largest source of cost, complexity, delay, and risk. You’re not giving up capability you need. You’re shedding weight you never should have been carrying.

The hardware architecture matches this philosophy. The IN120 integrates its own oscillator, eliminating the external 32 MHz crystal. No external flash memory is required, since there’s no firmware to store. Power management is on-chip. The result is a configurable beacon SoC that needs almost nothing externally: a few passives, an antenna, and a power source. Reference designs show total component counts in the single digits.

The “but what about changes?” question comes up immediately, and it’s fair. OTP means one-time programmable: once burned, the configuration is permanent. But the Config Tool allows full validation and testing before the OTP burn, and for high-volume products with defined beacon behavior, immutability is a feature. It means the configuration is locked at manufacturing and can’t be corrupted in the field. No firmware corruption. No accidental misconfiguration. No attack surface for malicious reprogramming. The tag does what you told it to do, every time, until the battery dies.

Power consumption reflects the architecture’s simplicity. Without an RTOS, without firmware execution overhead, and with an integrated oscillator optimized for beacon duty cycles, the IN120 operates at ultra-low-power levels that extend coin cell life into years and make printed battery-powered disposable products viable.

The Integrated Temperature Sensor Changes the Cold Chain Equation

The IN120 includes an on-chip temperature sensor whose readings can be embedded directly in the BLE advertising payload. No external thermistor. No signal conditioning circuit. No ADC configuration in firmware (because there is no firmware). Temperature data broadcasts automatically at whatever interval you configured.

Think about what this means for cold chain logistics. A smart label on a vaccine shipment, compliant with WHO and FDA temperature monitoring guidelines, continuously broadcasts temperature readings to nearby gateways. The entire sensing and communication platform is one chip, a battery, and an antenna trace. The label can be printed, laminated, and applied at the packaging line. It’s disposable by design because it costs so little that recovery isn’t worth the logistics.

For pharmaceutical transport, food safety monitoring, and warehouse environmental tracking, this eliminates the barrier that has historically kept Bluetooth-based temperature monitoring expensive and over-engineered. The IN120’s temperature sensor provides the accuracy needed for indicator-level monitoring, and for applications requiring tighter tolerances, it serves as a screening tool that flags excursions for investigation.

Where the IN120 Fits Best

Smart labels. Peel-and-stick Bluetooth labels for retail inventory, logistics tracking, and supply chain visibility. These must be cheap enough to be disposable and thin enough to adhere to packaging. The IN120’s minimal external component count and no-firmware architecture make single-digit-dollar smart labels achievable at volume, where conventional designs struggle to break below $15–$20 fully loaded.

Disposable wearables. Patient monitoring wristbands that broadcast an ID for location tracking. Event wristbands for access control and crowd analytics. Single-use fitness or clinical trial tags. These products live and die on size, cost, and reliability. A no-firmware beacon SoC eliminates the largest risk vector and the largest driver of board size simultaneously.

Asset tags. Warehouses deploy thousands of Bluetooth asset tags, many of which are never recovered. When each unit costs $3 less because you’ve eliminated crystals, flash, and firmware development amortization, the business case for large-scale deployment becomes dramatically more favorable.

Proximity and wayfinding beacons. Museum guides, retail promotional beacons, indoor navigation nodes. These are deploy-and-forget devices where reliability over years of unattended operation matters more than feature richness. No firmware means no firmware bugs, no watchdog-triggered resets, no corruption from brown-out events.

Cold chain monitoring. Temperature-broadcasting tags on perishable goods, pharmaceuticals, and biologics. The integrated sensor makes the IN120 a single-chip cold chain monitoring solution, something that simply doesn’t exist in the conventional Bluetooth LE SoC landscape.

What This Means for Your Next Board Spin

If you’re a hardware engineer evaluating Bluetooth LE SoCs for a beacon product, ask yourself honestly: does this application need firmware? Does it need an RTOS? Does it need OTA updates? If the answer is no, if the device advertises a defined payload at a defined interval, possibly with temperature data, then every hour of firmware development and every external crystal on the BOM is waste.

The InPlay IN120 NanoBeacon doesn’t ask you to compromise on capability for the sake of simplicity. It recognizes that for beacon applications, simplicity is the capability. Fewer components means fewer failure modes. No firmware means no firmware bugs. GUI-based configuration means your time goes to antenna design, mechanical integration, and manufacturing optimization, the things that actually differentiate your product.

For product owners, the math is straightforward: lower unit cost, faster time to market, reduced risk, and a manufacturing process that’s simpler to scale. The story you tell stakeholders isn’t “we cut corners.” It’s “we chose an architecture purpose-built for this application and eliminated everything that didn’t need to exist.”

The empty PCB isn’t a compromise. It’s what happens when you stop solving problems you don’t have.

Hubble Network enables these ultra-simple beacon designs to reach satellites directly from a single chip—no gateways, no infrastructure, no complexity creep. See how it works →