“It’s Just a Sensor, Right?” Our Lessons Learned in Rugged, Reliable Sensor Design

In electronic design, particularly in products that operate in challenging environments, every decision is a trade-off that affects everything else. Here’s what we learned developing our RS26x LoRaWAN temperature sensor.

Published on March 2, 2026

“It’s Just a Sensor, Right?” Our Lessons Learned in Rugged, Reliable Sensor Design

Building the Perfect Sensor – A Balanced Approach

At The Things Conference 2025, our VP of Product Management Jonathan Kaye presented our journey in developing the ideal temperature sensor for industrial coolers, freezers, and kitchens. With a laser focus on developing to our customers’ real-world conditions and performance requirements, we identified valuable insights to share with The Things Conference. The video of this talk is available here

This blog post is an attempt to summarize our development process and the lessons we learned developing for this challenging use case. Our customers’ operating environments are different. They’re highly metallic and resist RF signals. They can be messy, so equipment must be easy to clean. Equipment must be easy to install and use by workers who are not IT technicians. Devices need to “just work” when installed, for a very long time without interference or maintenance. 

Along the way, we made many discoveries, but the main insight was this: every single design decision has implications for the other components on board, as well as the finished performance. And some things hardware designers might take for granted can lead to disappointments and redesigns down the line. 

Following are three major takeaways from Jonathan’s presentation at TTC 2025

#1: Reducing Technical Debt Pays Dividends

In developing our next-generation sensor, Ezurio looked inward at our existing portfolio and our long-term investments in microcontroller development. Identifying LoRaWAN as the best wireless protocol for connectivity in metallic environments with lots of RF scattering, we then looked to our RS126x series of LoRaWAN modules for ranged temperature data, as well as our Lyra 24 series for short-range configuration. 

Working with our established modules yielded benefits across multiple aspects of the product design. We were able to abandon a monolithic software architecture written in C from our previous generation of sensors and avoid the previous complexity of distributing individual SKUs for every supported regulatory region. We were also able to leverage our existing certifications work in providing a sensor that was global-ready, a big requirement for Quick Serve Restaurants who are largely global organizations. Another advantage was that our single board design was able to support those global markets without regional hardware changes, a major logistical advantage for our internal operations. 

Furthermore, we were able to reduce technical debt by leveraging our Canvas Software Suite, which provided the platform for developing Python applications on the RM126x and Lyra 24 MCUs. Canvas provides cross-chipset middleware, easy-to-use wireless APIs, and on-module scripting to simplify embedded development. Rather than reinvent the wheel, Ezurio was able to quickly cut to the app development process and rely on Canvas to spend less time addressing the underlying integration and Zephyr OS. 

In brief, leveraging our existing innovations allowed us to accelerate development toward the application itself and the other aspects of the board design, providing a familiar foundation to start coding and prototyping. 

#2: Some Givens are Not Givens

If you’re trying to design a temperature sensor that needs to run for a very long time on battery power, your first thought is probably “Design in the biggest battery that can fit,” right? Wrong. As we found out through multiple iterations, this and other design choices can actually have detrimental impacts elsewhere, and it’s important to design with a holistic view of the entire product and its performance. 

For example: that bigger battery can have a huge impact on thermal mass, causing the sensor probe to match environmental temperature much slower. We found the impact was enough to throw the sensor out of design spec quickly. A larger battery also has an effect on the radiative performance of a nearby antenna. And furthermore, batteries don’t always perform to their listed specifications either. We found that in practice, many candidate batteries didn’t meet their electrical specifications in real-world conditions like those cooler and freezer temperatures. Ultimately, you’ll need to test for yourself – in all the conditions your product is likely to encounter. A battery with a smaller milliamp hour specification may actually outperform a similar battery with a higher listed capacity. 

It's best not to assume when it comes to some of these expectations in the design process. Even something as seemingly true as “a bigger battery is better” isn’t necessarily a guarantee. In many cases, better power management on a smaller battery can yield better results not just for battery capacity but for other performance aspects. Seeing your components as part of the larger system helps make better informed decisions and a more functional end product. 

#3: Iterate, Iterate, Iterate

The truth is that the only way to prove out and validate designs is to put them to the test. Our RS26x went through 6 enclosure revisions, each attempting to improve upon performance and cater to conditions observed in real world environments. There are some things you won’t learn in the lab. One example: Our next-to-final design seemed perfect until tested in kitchen environments, when we quickly learned a concave area of the enclosure design was a perfect ketchup trap. This kind of insight is what happens when you focus on the customer, validate and test in the field, and put your product up against the challenges you’re truly attempting to solve.  

We found the same when it came to attempting to meet EN12830 certification, a crucial approval for food safety. The specification requires a device to register a 20˚C drop within 20 minutes. This requirement is to ensure timely detection of possible spoilage. And it requires careful engineering to achieve.

Multiple designs of our temperature probe were required to bring the sensor into specification. This meant removing additional PCB material around the temperature probe and changing the positioning to ensure its thermal mass was decoupled more from the main PCB, allowing it to change temperature with less resistance. Over the course of multiple designs, we were able to drop that response time from approximately 25 minutes down to approximately 11 minutes, well within the requirements of EN12830. 

Conclusion: A Good Idea is Just the Beginning

There’s more to say on the hidden complexities of designing a great temperature sensor, and the full presentation by Jonathan Kaye explains those in greater detail. But if it isn’t clear enough by now, it bears repeating: Designing great products is never an accident. Removing your own roadblocks, focusing on the customer, and thinking broader about every design component as part of a larger system is the only way to arrive at a product that truly serves its target customer. 

As we began, the answer to the question “It’s Just a Sensor, Right?” is – nothing is “just” anything. Every design has the possibility to be excellent, and cheap sensors are cheap for a reason. Even in applications that are not life-critical, proper design is crucial to serve your customers and the details matter. A product that catches ketchup is just as big of a failure as a product that can’t connect. Being thoughtful about every design decision and validating your products into the real world is the difference between failure, mediocrity, and success. 

For more on our RS126x design process, see the video below. And for more on our RS126x LoRaWAN temperature sensor, see: 

https://www.ezurio.com/rs26x-series