No More Plastic Shells: Why Your Next Asset Tracker Will Be Paper-Thin

You’ve been asked to design a peel-and-stick BLE asset tag. Something a warehouse worker applies like a shipping label. Thin, flexible, disposable. Simple enough: BLE advertising is about the lightest workload in wireless. A few bytes of payload, broadcast every second or two.

Then you start the BOM. A Bluetooth LE SoC needs a 32 MHz crystal. And a 32.768 kHz crystal for the RTC. External flash if you want OTA configuration. An LDO or DC-DC converter with inductor and output caps. A matching network for the antenna. Decoupling capacitors. A coin cell holder for the CR2032 that’s now your tallest component at 3.2mm.

Before you’ve written a single line of firmware, you’re looking at a rigid PCB, a minimum stack height of 6mm, and a BOM that demands a plastic enclosure to hold it all together. The “peel-and-stick label” is now a puck.

This is the architectural confession hiding inside most BLE asset trackers: the plastic shell isn’t protecting the product. It’s accommodating the component overhead of a Bluetooth LE SoC that was designed for a fundamentally different class of device.

That mismatch is now solvable. Purpose-built silicon exists that eliminates the external component chain entirely. But understanding why the problem persisted this long matters more than knowing the fix.

Designed for Everything, Optimized for Nothing You Need

Take a representative conventional BLE tracker design built on a mainstream SoC: a Nordic nRF52832, a TI CC2640R2, or a Renesas DA14531. These are well-engineered, capable chips. They power millions of devices across wearables, audio peripherals, smart home sensors, and mesh networks. That breadth is the point, and the problem.

A general-purpose Bluetooth LE SoC externalizes components to give designers flexibility across dozens of use cases. Need a TCXO for tighter frequency tolerance in an industrial environment? Swap the crystal. Want to tune the power supply for a rechargeable LiPo versus a coin cell? Choose your regulator topology. Need 512KB of flash for a complex application with OTA updates? Pick your density.

For a wearable or a smart home sensor, that flexibility is a genuine asset. For a device whose entire job is broadcasting a static or semi-static advertising payload, it’s dead weight.

Here’s what a typical BLE beacon BOM looks like on a conventional SoC:

• SoC: 5mm × 5mm QFN (or similar)
• 32 MHz crystal: 1.6mm × 1.2mm, plus two load capacitors
• 32.768 kHz crystal: 1.2mm × 1.0mm, plus two more load caps
• External flash: 3mm × 2mm SOIC-8 (if configuration or logging is needed)
• Voltage regulation: LDO or DC-DC with inductor, input/output caps, 4–6 discrete components
• Matching network: 2–3 passives for antenna impedance
• Decoupling: 3–5 additional capacitors across supply pins
• Battery holder: CR2032 clip, typically 24mm diameter footprint
• Antenna: chip antenna or PCB trace, plus keep-out area

Total discrete component count: 15–25 parts. Minimum PCB footprint: roughly 15mm × 20mm, more often 25mm × 25mm to accommodate the coin cell. Minimum assembly thickness with a CR2032: 5–8mm. Rigid FR4 substrate required, because the crystal and QFN package don’t tolerate flex.

An engineer designing for a smart label form factor, adhesive-backed, sub-2mm thick, flexible substrate, cannot bend this architecture into shape. The problem isn’t layout skill. It’s that the physics of the component chain sets a floor that no amount of clever routing can breach.

Your Thickest Component Is Dictating Your Entire Design

The battery deserves its own discussion because it’s where the form factor constraint becomes physically inescapable.

Conventional Bluetooth LE SoCs draw sleep currents in the range of 1–3µA and Tx peak currents of 5–8mA. For an advertising-only beacon transmitting every second, the average current might land around 10–20µA. That sounds tiny, and it is, relative to WiFi or cellular. But it’s enough to demand a real electrochemical cell with meaningful capacity.

The CR2032 became the de facto standard for BLE beacons because it reliably delivers 225mAh at 3V in a package the size of a nickel. At 3.2mm thick, it’s also the single tallest component in most beacon assemblies, taller than the SoC, taller than the crystals, taller than anything on the PCB. The enclosure exists, in large part, to contain the battery.

Thinner coin cells exist. The CR1632 is 1.6mm. The CR1220 is 1.2mm. But their capacities drop proportionally (55mAh, 35mAh), cutting device lifetime to months rather than years. And they still require rigid holders on rigid substrates.

The relevant question isn’t “what’s the thinnest coin cell?” It’s “what if the SoC’s power budget were low enough to run on a different kind of battery entirely?” Printed batteries from manufacturers like Enfucell or Blue Spark deliver 10–30mAh in packages under 0.5mm thick, on flexible substrates. Thin-film solid-state batteries from Imprint Energy or Ilika hit similar profiles. These energy sources are real, commercially available, and sufficient, if the SoC’s total power demand, including startup transients, fits within their discharge capabilities.

That “if” is the entire bottleneck. A conventional Bluetooth LE SoC’s startup sequence, oscillator settling, voltage ramp, flash initialization, draws current spikes that printed batteries cannot supply. The architecture assumes a coin cell is present. Remove that assumption, and the architecture breaks.

Why the Semiconductor Market Didn’t Prioritize This Problem

This gap isn’t an oversight. It’s a rational market outcome.

Nordic Semiconductor, TI, Dialog/Renesas, and others optimize their Bluetooth LE SoC roadmaps for the largest addressable markets: wearables, audio (LE Audio, Auracast), smart home, industrial sensors, medical peripherals. These segments demand protocol flexibility, processing headroom, peripheral interfaces, and OTA update capability. The external component overhead is a reasonable trade-off for the versatility those markets require.

A pure advertising beacon, no GPIOs, no application processor, no firmware development environment, no OTA stack, represents a tiny fraction of the BLE silicon TAM. Building a dedicated SoC for it means designing a chip that cannot serve any other use case. That’s a hard pitch to a semiconductor company’s product planning committee.

The result: engineers who needed a beacon-only device were told to use a general-purpose SoC and simply not populate the features they didn’t need. Except the crystal oscillator is always needed. The power management is always needed. The flash, in practice, is usually needed. “Don’t populate what you don’t use” saves almost nothing when the mandatory components are the problem.

This is where InPlay’s NanoBeacon enters the picture, not as a stripped-down version of a general-purpose Bluetooth LE SoC, but as a chip designed from the outset around a single question: what if the device only needs to advertise?

What a Beacon-Only SoC Architecture Enables

InPlay’s NanoBeacon IN100 integrates the components that conventional designs externalize:

• Crystal oscillator: on-die. No external 32 MHz or 32.768 kHz crystals, no load capacitors.
• Non-volatile memory: on-chip one-time programmable (OTP) storage for beacon configuration. No external flash.
• Power management: integrated LDO with direct battery connection. No external regulator, no inductor, no output capacitor array.
• Configuration model: programmed via a PC-based tool before deployment. No firmware IDE, no JTAG, no debug interface on the production unit.

The external component count for a basic beacon implementation: effectively zero active components beyond the SoC itself. An antenna (PCB trace or printed) and a battery. That’s the BOM.

The design consequences are concrete. The PCB footprint can shrink to approximately 3mm × 3mm for the SoC, with the antenna trace and battery pad defining the overall board dimensions rather than a constellation of passives. The substrate can be flexible, polyimide or even paper-based, because there are no solder joints to ceramic crystal packages that crack under flex. Total system thickness, paired with a printed battery, drops below 1mm.

Power figures support the alternative battery path: the NanoBeacon’s average current in a typical 1-second advertising interval lands in the low single-digit µA range, with startup behavior compatible with the limited peak discharge of printed and thin-film cells. This isn’t a matter of optimizing a conventional architecture’s power profile. It’s a consequence of removing the subsystems, crystal oscillator startup, flash read cycles, voltage regulator quiescent draw, that dominate conventional beacon power budgets.

Deployment Models That Rigid Trackers Cannot Reach

A sub-1mm BLE asset tracking smart label isn’t a thinner version of a tracker puck. It enables deployment patterns that rigid enclosures structurally prevent.

Embedded in packaging. A paper-thin BLE tracker can be laminated directly into corrugated cardboard during box manufacturing. The package is the tracker. No affixing, no holder, no risk of detachment.

Applied at point of origin. A peel-and-stick BLE smart label applied alongside a shipping label at a fulfillment center adds asset-level tracking granularity without changing the packing workflow. The per-unit cost profile of a plastic-free asset tracker with a printed battery and near-zero passive count makes single-trip disposable use economically viable.

Pharmaceutical and medical packaging. A thin-battery BLE tag integrated into a blister pack or sterile device pouch provides chain-of-custody data through the last mile without adding bulk that alters packaging dimensions or shelf fit.

Pallet and container-level density. When trackers are thin enough to not stack up physically, you can tag at the item level rather than the case level, a shift from statistical sampling to census tracking.

These aren’t speculative applications. They’re engineering programs that have been attempted and stalled because the available Bluetooth LE SoC options couldn’t meet the form factor requirement. The silicon was the bottleneck.

Building This Into Your Next Design Review

If you’re currently shipping a rigid BLE tracker or evaluating a new asset tracking design, the practical next step is a side-by-side comparison at the BOM level, not the datasheet level.

Start with your current BOM. Count the discrete components supporting your Bluetooth LE SoC: crystals, regulators, flash, passives. Measure their contribution to board area and stack height. Identify which of those components exist because the SoC requires them versus because your application requires them. For a beacon-only use case, the gap between those two lists is your unnecessary overhead.

Evaluate against a purpose-built alternative. Download the InPlay NanoBeacon IN100 datasheet and map its integrated subsystems against your external component list. Request an evaluation kit and use the configuration tool to set up a basic advertising payload. The exercise of configuring a beacon without writing firmware clarifies how different this design model is. Review InPlay’s reference designs for flexible substrate layouts with printed battery integration to understand the mechanical implications.

Reassess your form factor constraints. If your product requirements currently specify a rigid enclosure, ask whether that’s a true requirement or a downstream consequence of your SoC selection. An ultra-thin BLE SoC with near-zero external components changes which form factors are feasible, and that changes which markets and deployment models your product can address.

The plastic shell around a conventional BLE tracker exists because the electronics inside demand it. When the electronics no longer do, the design space opens to product categories, smart labels, embedded packaging tags, disposable per-trip trackers, that weren’t previously reachable. The constraint was never Bluetooth. It was the assumption that every Bluetooth device needed the same silicon architecture.

Hubble Network enables these paper-thin BLE trackers to reach satellites directly — no gateways, no infrastructure, just peel-and-stick global connectivity. See how it works →