Over the past two weeks we’ve introduced two ideas. First, that splitting a cross-domain project across specialists creates hidden integration costs. Second, that not every asset actually needs battery-free sensing — and we’ll tell you honestly when it doesn’t.
This week connects both ideas with a question we get asked more often than you’d think: why does a small engineering team pour so much effort into battery-free sensors?
The answer is not what most people expect.
1) The question behind the question
When someone asks “why battery-free sensors?”, what they’re usually asking is one of two things:
“Is the market big enough to justify this?” — a business question. And the honest answer is: the market for battery-free sensing is real but still maturing. It’s a long-cycle business with complex deployments. We believe in it and we’re building it — but it’s not the only thing we do.
“Why not build something easier?” — an engineering question. And this is where the answer gets interesting.
We build battery-free sensors because they’re the hardest integration challenge we know. And solving them proves something about our team that no pitch deck or credentials list can prove: that we genuinely own the complete hardware, firmware, software and wireless/RF stack — not as a claim, but as a demonstrated, shipping capability. That same capability turns out to solve problems well beyond sensors.
2) What makes battery-free sensors hard
A battery-free sensor tag looks simple. It’s a small PCB with an antenna, a few components, and a sensor. There’s nothing obviously impressive about the hardware.
The difficulty is invisible. It lives in the interactions between domains that all have to work together within an energy budget measured in microwatts.
Antenna design affects the energy budget. The antenna captures RF energy from the reader’s field. Its efficiency, bandwidth, and impedance match to the rectifier determine how much power the tag harvests. A 1 dB difference in antenna performance changes the operational range by 10-15%. The antenna design is constrained by the PCB size, the housing materials, the proximity to metal, and the orientation in the final installation. This is RF engineering, but the constraints come from mechanical engineering and the deployment environment.
The rectifier and power management determine what the sensor can do. The harvested RF energy is AC. It needs to be rectified, filtered, and stored in a capacitor before anything useful happens. The rectifier efficiency, the capacitor type (MLCC vs supercap), the voltage monitor thresholds — these determine how much energy is available and when the system can wake up. This is analogue circuit design, constrained by the antenna performance (which determines input power) and the firmware duty cycle (which determines energy consumption).
The firmware must operate within the energy budget. The firmware controls the sequence: wake up, power the sensor, wait for the measurement to settle, read the data, format it, transmit it, go back to sleep. Every microsecond of active time costs energy. The firmware engineer needs to understand the power profile of every component on the board — not just the microcontroller, but the sensor’s settling time, the communication IC’s transmit current, the voltage regulator’s quiescent consumption. This is firmware engineering, constrained by the hardware design and the RF performance.
The sensor signal conditioning must work at extreme low power. The sensor needs to produce a reliable measurement with minimal energy. Some sensors need excitation current. Some need settling time. Some need calibration at power-up. All of this consumes energy that the firmware budget has to account for. This is sensor engineering, constrained by the power management and the firmware timing.
The communication must complete before the energy runs out. Whether it’s EPC C1G2 backscatter, a BLE advertising burst, or an NFC data exchange, the tag has to transmit the measurement data within the energy window. If the transmission takes too long or consumes too much power, the tag runs out of energy mid-transmission and the data is lost. This is wireless protocol engineering, constrained by everything above.
The housing must not destroy the RF performance. The final enclosure — which the client often specifies or constrains — affects the antenna performance, which affects the energy budget, which affects everything else. Metal nearby? The antenna detunes. Thick plastic? The dielectric changes the resonant frequency. Screws? Potential Faraday cage. This is mechanical/packaging engineering feeding back into RF engineering.
The software must tie the entire system together on the reader side. The tag is only half the system. On the other side, someone needs to connect to the reader, run inventories, decode the sensor data, and deliver it in a format the end user can work with. That’s what KL-OSIRIS does for evaluation, and what the SENSEID SDK (.NET, Python) does for custom applications. The software abstracts multiple reader manufacturers, decodes the tag data format, applies calibration, and handles the protocol differences between EPC C1G2, BLE and NFC. This is application software engineering, constrained by the tag’s data format (which comes from firmware), the reader’s API (which varies per manufacturer), and the communication protocol (which determines timing and data structure).
Every domain affects every other domain. There are no independent layers. There are no clean interfaces between disciplines. The system works as a whole or it doesn’t work at all.
3) Why this matters beyond sensors
The discipline required to build a battery-free sensor — owning all the domains simultaneously, understanding their interactions, making trade-offs that span hardware, firmware, software and RF — is the same discipline required for any cross-domain engineering project.
A test platform for a semiconductor chip? The test socket, the power delivery, the RF stimulus, the measurement accuracy, and the software that orchestrates the test all interact. Change the socket impedance and the RF measurement changes. Change the test sequence timing and the power delivery spikes. Same pattern.
A control system for industrial testing equipment? The hydraulic actuator, the force sensors, the PLC timing, and the software test patterns all interact. Change the control algorithm and the hydraulic response changes. Change the sensor sampling rate and the test pattern accuracy changes. Same pattern.
A wireless product that needs antenna, firmware and application software? Same pattern.
The specific domains change. The pattern doesn’t. A team that has learned to navigate these interactions in the most extreme case (battery-free sensing, where the energy budget is measured in microwatts and there is zero margin) can navigate them in any cross-domain system.
That’s why we build battery-free sensors. They’re a real product line that we’re committed to for the long term — and they’re also the most demanding proof of a broader engineering capability that applies to any project where hardware, firmware, software and wireless need to work together.
4) The proof you can verify
This isn’t an abstract claim. You can verify it yourself with a 50 € evaluation board and our free software.
Order a SenseID, SenseBLE, or SenseNFC evaluation tag. Place it near a reader or tap it with your phone. See the sensor data appear on screen. That reading — a temperature, a humidity value, an acceleration measurement — was captured by a sensor powered entirely by harvested RF energy, processed by firmware running on microwatts, and transmitted wirelessly without a battery.
That’s seven engineering domains (antenna, RF, power management, firmware, sensors, communication, and software) working together within a margin of error measured in microjoules. If we can make that work reliably, we can design your cross-domain system.
5) What this means for your project
If you have a project that crosses hardware, firmware, software and wireless/RF — whether or not it involves sensors — the question is the same one we posed two weeks ago: do you want to split it across specialists and own the integration risk yourself? Or do you want a team that has proven, with shipping products, that they can own the whole system?
The battery-free sensors are our credential. The engineering capability behind them is what we bring to your project.
Have a cross-domain project that needs a single team? Contact us. We’ll scope it honestly — including telling you if it’s something that can be safely split (some projects can) or if it needs a single owner.
Want to see the proof first? Evaluation kits start at 50 €. The capability is in the tag.
Next week: “Predictive Monitoring for High-Voltage Equipment: Where Owning the Whole System Is the Only Option” — our flagship application, where cross-domain capability meets a Level 1 asset.