InPlay vs Nordic vs TI for High-Volume BLE Tags: Cost and Power and Tooling Compared
A $0.50 per-unit BOM delta on a 1M unit/year program is $500,000. That number is bigger than most firmware engineers’ salaries, and it’s exactly the math your procurement lead is doing right now while you defend the nRF52832 in your reference design.
The catch: re-spinning firmware onto a less mature SDK can burn that savings in 6 months of engineering time and warranty risk. The real question isn’t “which BLE SoC is cheapest?” It’s where the cost savings actually clear the engineering risk.
The Three Contenders At A Glance
InPlay IN100/IN612 | Nordic nRF52832/54L | TI CC2340
-------------------+-------------------+---------------------+--------------
Unit price (1M+) | $ (lowest tier) | $$ (mid) | $$ (mid)
Active TX current | ~4-5 mA | ~5-6 mA | ~5 mA
Sleep current | <1 µA | ~1.5 µA | ~1 µA
Flash / RAM | 256KB / 32KB | 512KB / 64KB | 512KB / 36KB
SDK maturity | Developing | Excellent | Very Good
Community size | Small | Largest | Large
Lifecycle support | TBD | 10+ years | 10+ yearsInPlay’s IN100 is the flagship for simple tag and beacon designs. The IN612 bolts on more peripherals and headroom for slightly richer firmware. Both target the same thing: integrated BLE SoCs that hit a BOM number Nordic and TI structurally can’t touch.
Nordic’s nRF52832 is the workhorse of the last 7 years. The nRF54L15 is the heir apparent. TI’s CC2340R5 is the cleaner low-cost play from the SimpleLink family. Dialog/Renesas DA1453x sits in a similar low-cost bucket to InPlay (worth a look but outside this comparison).
Where Nordic Wins (Be Honest)
If you’ve shipped on Nordic, you already know this. The nRF Connect SDK with Zephyr underneath is the most mature BLE development environment in the industry. Debugging is good. Logging is good. The peripheral driver model is sane.
DevZone and Stack Overflow give you a 10-year backlog of solved problems. When something weird happens at 3am during a production ramp, somebody else has probably already hit it and posted the fix.
Multiprotocol headroom is real. If your roadmap touches Thread, Matter, or LE Audio in the next 24 months, Nordic is the safe bet. The radio and stack support is already there, and switching SoCs mid-roadmap to add Matter is more expensive than the BOM delta you’d save going with InPlay.
10+ year availability is on paper, with a track record to back it up. For a program that’s going to ship for 7 years, that matters.
Fit: complex products, mixed protocols, smaller firmware teams that lean on ecosystem support, or anything that needs to scale up in feature complexity post-launch.
Where TI Wins (Be Honest)
TI’s SimpleLink architecture is genuinely portable. If your company already ships on a CC13xx or MSP430, your engineers’ muscle memory carries over. That’s a real cost saving that doesn’t show up in a BOM line.
Production tooling is where TI quietly dominates. Gang programming, factory provisioning, automated test fixtures: the workflows are mature and well-documented. For a 1M+ unit program where line yield matters, this isn’t a footnote.
Long-term availability comes with a track record. If your end customer is asking PPAP-style questions, TI is the path of least resistance.
Fit: regulated industries, long product lifecycles (medical, industrial, infrastructure), and any design where supply continuity is worth paying for at the SoC line.
Where InPlay Wins: Cost And Power At Scale
Two anchor use cases.
Retail ESL at 1M+ units/year. The firmware is genuinely simple: advertise a payload, occasionally receive a display update, deep sleep the rest of the time. You don’t need 512KB of flash. You don’t need a Cortex-M33 with TrustZone. You need a cheap radio, enough flash to hold a bootloader and the app, and the lowest possible sleep current. InPlay’s IN100 is purpose-built for this duty cycle. Integrated radio, MCU, and flash hit a BOM number Nordic can’t match without a die shrink they haven’t done.
Asset tracking tags. Advertising-heavy, low GATT complexity, battery life measured in years. Better sleep current and TX efficiency mean a smaller coin cell, and a CR2032 instead of a CR2450 is real money at volume. If you’re building advertising-heavy firmware, the advertising packet structure on the Hubble side is the same regardless of which SoC you pick, so the porting cost is mostly the radio HAL and the sleep logic.
A realistic per-unit savings stack at 1M units/year:
SoC unit cost delta : -$0.35
External component BOM : -$0.15 (integration consolidates passives)
Smaller battery : -$0.20
-----------------------------
Total per unit : -$0.70
At 1M units/year : -$700,000These numbers are directional, not contract pricing. Your negotiated Nordic price at 1M units is probably better than distributor list, but even after that the gap is real. We’ve seen programs land in the $0.30 to $0.80 per-unit savings band depending on design complexity.
Where InPlay Loses (Set Expectations)
The SDK is less polished. Expect to debug things yourself that would be a forum post away on Nordic. If your firmware lead’s first instinct when stuck is to search DevZone, that workflow doesn’t exist yet at the same depth for InPlay.
Reference designs are thinner. You’ll do more of your own radio characterization, antenna tuning validation, and certification prep without a wide library of prior art to crib from. (For comparison, the Hubble device SDK repo ships reference apps for Nordic, Silabs, and TI, but not InPlay yet.)
Multiprotocol is narrow. If Thread or Matter is on your 2-year roadmap, this is the wrong chip. Same for LE Audio.
Procurement diligence is required. Get lifecycle commitments and second-source stories in writing before your supply chain team signs off. Don’t skip this.
Complex GATT-heavy designs (medical wearables with lots of services, multi-role concurrency) aren’t the sweet spot. The flash and RAM envelope will bite you.
Decision Framework
Grade yourself honestly, not the way you’d grade your own homework.
[ ] Volume > 500K units/year?
[ ] Firmware fits in 256KB flash / 32KB RAM?
[ ] BLE-only (no Thread/Matter/LE Audio on roadmap)?
[ ] Team can absorb a less mature SDK without melting?
[ ] BOM cost is a top-3 program constraint?
5 yes -> Evaluate InPlay seriously
3-4 yes -> Prototype on both, decide on measured data
0-2 yes -> Stay on Nordic or TI, the math doesn't clearThe 5-yes case shows up more often than Nordic and TI would like to admit: ESL programs, simple asset tags, BLE-only retail beacons. If you’re in that bucket, the per-unit savings compound fast enough to fund a dedicated firmware engineer for the lifetime of the program.
The 3-4 yes case is where most readers actually land. The answer there is data, not vendor slides.
Run A Two-Week Parallel POC
Port a minimal advertising firmware to InPlay alongside your existing Nordic or TI baseline. Same payload format, same advertising interval, same sleep strategy. If you’re going to feed packets into a network like Hubble’s, the terrestrial SDK reference shows what the firmware-side surface area looks like, and it’s small enough to port in a couple of days.
Measure:
- Active TX current at the antenna, not the datasheet figure
- Sleep current with your real peripherals attached
- Range in your actual deployment environment
- Time-to-first-blinky and time-to-first-pain in the toolchain
Then decide on numbers. Not on slides, not on this article, and definitely not on what your competitor picked.
If the numbers land in InPlay’s favor and the SDK pain is tolerable, you’ve found $500K to $1M a year. If they don’t, you’ve spent 2 engineer-weeks confirming Nordic or TI was the right call all along. That’s a cheap insurance policy either way.
Hubble Network ingests BLE advertising packets from any silicon vendor, so your chip selection stays a pure cost-and-power decision. See how it works →