We get asked this question regularly: “What’s the difference between SenseID, SenseBLE and SenseNFC?” The assumption behind it is usually that each line measures different things, or that one is better than another. Neither is true.
All three product lines share the same sensing core. The same temperature sensor, the same accelerometer, the same load cell, the same humidity sensor — identical hardware doing identical measurements. What differs is the communication protocol and, consequently, the infrastructure you need on the receiving end.
This post explains why we designed it this way, what the real trade-offs are, and how to decide which protocol fits your application.
1) The architecture: one core, three communication paths
A battery-free sensor tag has three jobs: harvest energy, take a measurement, and transmit the data. The first two are shared across all our product lines. Only the third one changes.
Energy harvesting. SenseID and SenseBLE both harvest energy from a UHF RF field in the 868/900 MHz band. The source of that field can be a commercial RFID reader or a dedicated RF transmitter — the tag doesn’t care which one, it just needs enough RF energy to power up. SenseNFC is different: it harvests energy from the NFC field generated by a smartphone or an NFC reader pad, operating at 13.56 MHz.
Sensing. Once the tag has accumulated enough energy, it powers the sensor, takes a measurement, and stores the result. This step is completely identical across all three lines. A temperature reading is a temperature reading, whether it’s going to travel via EPC C1G2, BLE or NFC. The sensor IC, the signal conditioning, the digitisation — all the same.
Communication. Here’s where the paths diverge:
SenseID sends the sensor data via EPC C1G2 backscatter. The tag modulates the RF signal from the reader and reflects it back with the data encoded. This happens in the same frequency band as the power transfer (868/900 MHz). The reader both powers the tag and receives the data.
SenseBLE accumulates energy from the UHF RF field, then fires a BLE advertising burst at 2.4 GHz containing the sensor data and a unique identifier. After the burst, the tag goes back to sleep until it accumulates enough energy for the next cycle. Power and data travel in separate frequency bands.
SenseNFC communicates via the NFC protocol at 13.56 MHz. The smartphone or NFC reader that provides the energy field also receives the data — much like tapping an NFC payment card, but instead of a transaction, you get a sensor measurement.
2) Why not just pick one protocol and simplify?
Because different applications have different constraints, and the protocol choice is driven by the deployment context — not by what you want to measure. Here are the real decision factors.
What infrastructure do you already have?
If your facility has UHF RFID readers deployed for track-and-trace, asset management, or inventory, then SenseID is the natural choice. Your readers, antennas, middleware, and EPC workflows already work. Adding sensor tags is incremental — you’re extending an existing system rather than building a new one. The tags respond to standard EPC C1G2 commands, so your existing software just needs to read additional memory addresses.
If you don’t have RFID infrastructure, building it solely for sensing means investing in readers that are inherently more complex and expensive. That’s where SenseBLE becomes interesting.
How cost-sensitive is the reader side?
This is where the physics of the protocols creates a meaningful economic difference. A UHF RFID reader needs to transmit power and listen for the backscatter response in the same frequency band. Transmitting at 30+ dBm and simultaneously detecting a signal that’s been attenuated by the round trip to the tag and back requires high-sensitivity receiver circuits with excellent isolation. That’s proven, mature electronics — but it’s not cheap.
With SenseBLE, the power transfer happens at 868/900 MHz and the data comes back at 2.4 GHz. Two separate bands. The transmitter doesn’t need to listen for a faint backscatter in its own band — it just needs to push enough energy for the tag to wake up. The BLE receiver is commodity hardware; any standard BLE gateway can pick up the advertising burst. The combined cost of an RF transmitter plus a BLE gateway is typically lower than a commercial RFID reader.
Do you need fixed infrastructure at all?
For applications like maintenance rounds, spot audits, quality checks, or compliance inspections, SenseNFC eliminates fixed infrastructure entirely. A technician walks up to a sensor tag, taps their smartphone, and gets the measurement. The phone provides both the energy and the data link. No readers to install, no gateways to mount, no network to configure.
The trade-off is range: NFC is a near-field technology. You need to be within a few centimetres of the tag. That’s a feature for some use cases (deliberate, auditable reads) and a limitation for others (you can’t sweep a warehouse from a forklift).
3) What about range?
This is probably the most misunderstood aspect of battery-free sensing. People compare RFID read range with BLE coverage and draw conclusions about which technology is “better.” But for battery-free sensor tags, the range bottleneck is the same regardless of the communication protocol.
The limiting factor is power transfer distance — how far from the RF source the tag can harvest enough energy to power the sensor and transmit. For SenseID and SenseBLE, this depends on the UHF RF field: transmit power, antenna gain, tag antenna design, and environmental factors (metal, water, orientation). Both lines use the same energy harvesting front end, so their operational range is essentially the same.
SenseNFC has a fundamentally shorter range because the NFC field operates in the near-field at 13.56 MHz. That’s physics, and it’s the right trade-off for applications where close proximity is acceptable or even desirable.
In short: don’t choose between SenseID and SenseBLE based on range. They’re the same. Choose based on infrastructure and cost.
4) What sensors can each line carry?
All of them. That’s the whole point.
Our evaluation boards come with specific sensors because they’re the most commonly requested ones — ambient temperature, contact temperature (NTC), relative humidity and temperature, 3-axis accelerometers, magnetometers. These cover a wide range of industrial monitoring needs out of the box and let you evaluate the technology quickly.
But the sensing core is designed to work with any sensor that fits within the tag’s energy budget. Load cells for weight monitoring. Strain gages for deformation. Pressure transducers. pH probes. Ambient light sensors. E-ink displays as actuators. If the sensor can operate within the power delivered by the energy harvesting system, it can be integrated.
When a customer’s application requires a sensor that’s not in our standard evaluation lineup, we design a custom solution around the same platform. The communication path (SenseID, SenseBLE, or SenseNFC) is chosen based on their deployment context, not based on the sensor.
5) A practical comparison
Here’s a summary to help frame the conversation:
| SenseID | SenseBLE | SenseNFC | |
|---|---|---|---|
| Energy source | UHF RF field (868/900 MHz) | UHF RF field (868/900 MHz) | NFC field (13.56 MHz) |
| Communication | EPC C1G2 backscatter | BLE advertising burst | NFC |
| Data band | 868/900 MHz (same as power) | 2.4 GHz (separate from power) | 13.56 MHz (same as power) |
| Reader/receiver | Commercial UHF RFID reader | RF transmitter + BLE gateway | Smartphone or NFC pad |
| Read pattern | Deterministic (reader-controlled) | Event-driven (tag emits when charged) | On-demand (tap to read) |
| Fixed infrastructure | Yes (readers + antennas) | Yes (RF TX + BLE gateways) | No |
| Reader-side cost | Higher (same-band TX+RX) | Lower (separate bands) | Lowest (phone) |
| Sensing capability | Any sensor | Any sensor | Any sensor |
| Operational range | Limited by UHF power transfer | Limited by UHF power transfer | Near-field (cm) |
6) How to decide
Three questions cut through the complexity:
Question 1: Do you already have UHF RFID readers? If yes, start with SenseID. You’re leveraging existing investment and your team already knows the ecosystem.
Question 2: Are you building from scratch and watching costs? Consider SenseBLE. Lower infrastructure cost, simpler receiver electronics, and BLE is already the lingua franca of most modern IoT edge platforms.
Question 3: Do your users carry smartphones and need point-of-use readings? SenseNFC. No infrastructure to deploy, no maintenance, and every technician already has the reader in their pocket.
And a fourth question that matters more than most people think: Can you combine protocols in the same deployment? Yes. The sensor data is the same across all three lines. Your middleware normalises it into the same schema. Some of the most practical deployments we see use RFID at fixed touchpoints (portals, docks) where readers are already installed, BLE in open areas where cost-per-zone matters, and NFC for ad-hoc maintenance checks. This isn’t a compromise — it’s the architecture matching the application.
7) Evaluating the technology
The fastest way to validate whether battery-free sensing works for your application is to get your hands on evaluation hardware and run it in your environment. We offer starter kits for SenseID, SenseBLE and SenseNFC that include evaluation boards with the most common sensors, along with KL-OSIRIS — our free, multi-platform software for reading, visualising, and logging sensor data.
For developers building custom applications, the SENSEID SDK provides .NET and Python libraries to integrate sensor data into your own systems.
If your application requires sensors beyond our standard evaluation range, or if you’ve evaluated the technology and want to discuss a custom solution for your specific use case, get in touch. We’ll help you figure out which protocol — or combination of protocols — fits your deployment.
Next week: “Choosing Your Protocol: EPC C1G2 vs BLE vs NFC for Battery-Free Sensing” — a deeper dive into the infrastructure and cost trade-offs with real numbers.