Last week we published a post explaining that SenseID, SenseBLE and SenseNFC share the same sensing core. The sensor is identical — what changes is the communication protocol and the infrastructure on the receiving end.
This week we go one step deeper: how do you actually choose which protocol to use? Not in theory — in practice, with real constraints, real budgets, and real facilities.
The short answer: the protocol is a deployment decision, not a technology decision. The slightly longer answer requires understanding three dimensions: your existing infrastructure, your cost sensitivity, and how users will interact with the sensors.
Decision framework comparing EPC C1G2 (SenseID), BLE burst (SenseBLE) and NFC (SenseNFC) across eight criteria — energy source, communication, data band, infrastructure, reader cost, read pattern, range limit and fixed infrastructure — with three decision questions at the bottom.
1) Start with the use case, not the protocol
This might sound obvious, but it’s the mistake we see most often — including from ourselves in the early days. The temptation is to start with the technology: “We want to deploy RFID sensors” or “We need BLE.” That frames the whole conversation around a protocol choice before understanding whether it’s the right one.
The better starting point is a set of questions about the application:
What do you need to measure? Temperature, humidity, weight, vibration, strain, pressure, continuity — the answer doesn’t affect the protocol choice at all. Any sensor works with any of our three lines.
Where is the thing you’re measuring? Fixed location (mounted on a wall, embedded in a structure, attached to a pallet)? Moving through a facility (conveyor, forklift, production line)? In a location that a person visits periodically (maintenance rounds, inspections)?
Who needs the data, and how quickly? A warehouse management system that needs automatic inventory updates every shift? A maintenance team that checks equipment once a week? A compliance audit trail that needs timestamped records?
What infrastructure already exists in the facility? RFID readers from a previous track-and-trace deployment? BLE gateways for asset tracking? Nothing at all except WiFi and people with smartphones?
The answers to these questions narrow the protocol choice dramatically — often to a single option.
2) The infrastructure question: what do you already have?
This is the most powerful filter because it determines whether you’re extending an existing system or building a new one.
Scenario A: you have UHF RFID readers. Many manufacturing facilities, warehouses, and logistics operations already have RFID readers deployed — for inventory, track-and-trace, or access control. If that’s your case, SenseID (EPC C1G2) is the straightforward path. Your readers already generate the RF field needed to power the sensor tags. Your middleware already handles EPC events. Adding sensor data means reading a few additional memory addresses per tag or processing the data a bit differently. The incremental cost of deploying sensors on top of an existing RFID system is remarkably low.
Scenario B: you have BLE gateways or a BLE-ready edge platform. Some facilities already use BLE for indoor positioning, asset tracking, or environmental monitoring with battery-powered sensors. In this case, SenseBLE lets you add battery-free sensor tags that your existing BLE infrastructure can already hear. You’ll need an RF transmitter to provide the UHF energy field, but the data reception side is already in place.
Scenario C: you have nothing — except people with smartphones. If there’s no fixed infrastructure and installing it is impractical or disproportionate to the application, SenseNFC turns every smartphone into a sensor reader. No readers to install, no gateways to mount, no network infrastructure to build. The technician taps the tag, gets the reading, and the data flows through their phone to whatever system needs it.
3) The cost question: what does the receiver side cost?
This is where the physics of each protocol creates a real economic difference, and it’s worth understanding why.
EPC C1G2 reader cost. A UHF RFID reader transmits power at 868/900 MHz and listens for the backscatter response in the same frequency band. The reader is simultaneously a powerful transmitter (30+ dBm) and a very sensitive receiver — in the same band, at the same time. That requires careful isolation between the transmit and receive paths, which means more complex electronics. Commercial UHF RFID readers from established manufacturers typically cost several hundred to a few thousand euros depending on the number of antenna ports, form factor, and connectivity options. This is mature, reliable technology — but it’s not commodity hardware.
SenseBLE receiver cost. With SenseBLE, you separate the two functions: a dedicated RF transmitter handles power delivery at 868/900 MHz, and a standard BLE gateway receives the sensor data at 2.4 GHz. Because the two functions operate in different frequency bands, neither piece of hardware needs the complex same-band isolation that an RFID reader requires. BLE gateways are commodity hardware — widely available, well-supported, and inexpensive. The combined cost of an RF transmitter plus a BLE gateway is typically lower than a comparable RFID reader setup. How much lower depends on the specific hardware, but the difference is meaningful enough to influence the decision when you’re deploying infrastructure from scratch.
SenseNFC reader cost. Effectively zero for the hardware — the smartphone your technicians already carry is the reader. The cost is in the software: an app that handles the NFC read, processes the sensor data, and sends it to your backend system. For small-scale deployments or applications where readings are taken by humans during scheduled rounds, this is the most cost-effective path by a wide margin.
4) The interaction question: automated or human-driven?
Automated, continuous, no human in the loop. The system reads sensors on a schedule or continuously — dock portals, production line checkpoints, cold room monitoring. This points to SenseID or SenseBLE with fixed readers/transmitters and gateways. The choice between them comes back to Sections 2 and 3: existing infrastructure and cost.
Human-triggered, periodic. A technician visits a sensor during a maintenance round, a quality check, or a compliance audit. The reading is deliberate and documented. This is SenseNFC territory. The near-field range is actually an advantage here — you can’t accidentally read the wrong sensor from across the room. Each reading requires intentional proximity, which creates an auditable record.
Hybrid: some automated, some human. Many real deployments combine both patterns. Fixed readers at key touchpoints handle the automated layer. Technicians with phones handle the exception cases, the spot checks, and the locations where fixed infrastructure isn’t justified. This is where running multiple protocols in the same deployment makes practical sense — and it works because the sensor data schema is the same across all three lines.
5) Five questions that narrow the choice
If you’re still weighing options, these five questions will get you most of the way to a decision:
1. Do you already have UHF RFID readers in the facility? If yes, SenseID. You’re extending, not building.
2. Do you already have BLE gateways or edge devices? If yes, SenseBLE is worth evaluating. You need an RF transmitter for power, but your data path is already set up.
3. Is the deployment new with no existing infrastructure? Compare the total cost of RFID reader deployment vs. RF transmitter + BLE gateways. In many cases, the BLE path wins on cost. In some cases, the RFID path wins on capability (deterministic reads, EPC standard compatibility).
4. Will readings be taken by people during scheduled rounds? SenseNFC. No infrastructure to deploy or maintain, and the smartphone creates a natural audit trail.
5. Do you need to combine automated and manual readings? Use multiple protocols. SenseID or SenseBLE for the automated layer, SenseNFC for the human-driven layer. Same sensor data, same middleware.
6) What this means for evaluating the technology
Evaluation is where most of our customer relationships start — and the protocol choice affects how you set up your evaluation.
For SenseID evaluation, you’ll need a compatible UHF RFID reader. Our SenseID starter kits include evaluation boards that work with major commercial readers (Impinj, Zebra, Nordic ID, and others supporting EPC C1G2).
For SenseBLE evaluation, you need a UHF energy source plus any BLE-capable device to receive the beacons. Our SenseBLE evaluation boards broadcast standard BLE advertising packets that any smartphone, tablet, or BLE gateway can pick up.
Both families work with KL-OSIRIS, our free multi-platform software for reading and logging sensor data. It’s the fastest way to see battery-free sensing working in your environment before you commit to any protocol decision.
SenseNFC evaluation kits are coming soon. If your application fits the NFC profile (human-driven, point-of-use readings), let us know — we can discuss early access.
7) The honest limitations
No technology is perfect, and choosing a protocol means accepting its trade-offs:
EPC C1G2: The most mature protocol for battery-free sensing, but reader cost is higher, and the backscatter communication has inherent range limitations in environments with metal and liquids. Also, adding dense reader infrastructure in large open areas gets expensive fast.
BLE burst: Lower receiver cost, but the read pattern is event-driven — the tag emits when it has enough energy, not when you ask. For applications requiring precise timing or a guaranteed read at a specific moment, this needs careful system design.
NFC: Lowest infrastructure cost, but the near-field range means you physically walk up to every sensor. That’s fine for 20 monitoring points on a maintenance route and impractical for 2,000 pallets in a warehouse.
Being honest about these trade-offs early saves everyone time — including us. We’d rather help you design the right architecture than sell you hardware that doesn’t fit.
Not sure which protocol fits your case? Contact us with a short description of your application — what you need to measure, where, and what infrastructure you have today. We’ll tell you which protocol makes sense and whether a combination might be the practical answer.
Next week: “The Economics of Battery‑Free: RFID Reader Cost vs RF TX + BLE RX” — we go deeper into the numbers behind the infrastructure cost comparison.