DEV Community

Himanshu Dada
Himanshu Dada

Posted on

Designing a Custom IoT Device for Remote Monitoring: A Field Guide


We’ve spent the last decade building connected hardware. From environmental sensors in warehouses to vending machines that report their own stock, the requests always start the same way: "We need to know what’s happening on site, without sending a technician."

The default answer for most teams is to buy an off-the-shelf gateway. But when you hit the limits of generic hardware—battery life measured in days instead of years, or a form factor that doesn't fit the enclosure—you have to go custom. Here is the reality of designing a remote monitoring device, including the trade-offs we don't usually talk about.

The Core Architecture: Don't Overthink the Silicon

Before we touch KiCad, we lock the communication stack. For 90% of our remote monitoring projects, the choice comes down to a single decision: BLE for local data logging or LTE-M/NB-IoT for wide-area telemetry.

If the device is stationary and has access to a local network, we often use the ESP32-S3 for its dual-core processing and Wi-Fi/Bluetooth combo. But for true "stick it in a field and forget it" scenarios, we lean on the nRF52840 or the nRF9160 SiP (System-in-Package). The nRF9160 is a beast because it integrates the application processor, LTE modem, and GPS into a single package. This simplifies the RF layout drastically—something our PCB designers appreciate when they are fighting for space on a 40mm x 40mm board.

The Firmware Stack
We build on Zephyr RTOS for these projects. It’s not just because it’s open source; it’s because Zephyr’s power management modules are superb. We can drop the CPU to sleep modes in microseconds and wake on GPIO interrupts or RTC timers. In a recent project monitoring pump vibration, we achieved a 4-year battery life on a single 18650 cell by utilizing Zephyr's tickless kernel. The device wakes up, takes a 10-second sample, pushes data via MQTT over LTE, and goes back to sleep.

The Advantage: Total Control Over the "Last Mile"

The biggest win for a custom board is the sensor integration. Off-the-shelf loggers often force you to use their proprietary sensors. When we design in-house, we can choose the exact MEMS sensor for the job.

For example, we built a device to monitor the temperature and humidity inside vintage arcade cabinets. These machines run hot, and the humidity wreaks havoc on the original wiring. The client needed a sensor that was small enough to fit near the power supply without obstructing airflow.

By designing our own board around the SHT4x sensor, we got a 0.1°C accuracy reading in a footprint smaller than a postage stamp. We also integrated a current clamp to monitor the power draw of the machine itself. This allowed the client to detect when a machine was left on overnight or when the cooling fan failed—data that generic loggers simply cannot capture.

The Protocol Layer
We use MQTT for the uplink. It’s lightweight and handles packet loss gracefully over cellular networks. We set the QoS (Quality of Service) to Level 1 to ensure at-least-once delivery without the heavy overhead of TCP handshakes on the device side. The data hits an AWS IoT Core broker, which triggers a Lambda function to update the client’s dashboard.

The Disadvantage: The Hidden Cost of Certification

Now, for the honest part. Custom hardware is not a weekend project. The physical design is only 30% of the work. The other 70% is the grueling process of compliance.

If you are shipping a cellular device to the US and UK, you are looking at FCC Part 15 and CE marking (RED directive). This means your RF layout has to be perfect. We’ve seen projects stall for months because the antenna matching network was slightly off, causing the device to fail radiated emissions tests.

You also have to consider the mechanical engineering. The enclosure isn't just a box; it’s a thermal management system. If your PCB is inside a sealed plastic housing, that heat has nowhere to go. We spend a significant amount of time in 3D design software (we use Fusion 360) simulating airflow and heat dissipation before we ever order a prototype.

The Supply Chain Reality
In 2024, we have to design for component availability, not just performance. We often have to design the PCB with "drop-in" alternate footprints for the MCU or the power management IC. If the primary chip has a 52-week lead time, we need a second source that we can solder on without redesigning the board.

The Prototype to Production Pipeline

One of our key advantages as a full-service agency is that we don’t just hand you a schematic. We handle the full prototype shipping process. We use a combination of JLCPCB for quick-turn assembly and a local Indian fab for high-reliability boards that require tighter tolerances.

Once we have the boards, we flash the bootloader via SWD (Serial Wire Debug) and run a 72-hour burn-in test. We simulate power surges, data dropouts, and extreme temperatures to ensure the firmware resets gracefully.

The Verdict: Is It Worth It?

Yes, but only if you have the volume. If you need 10 devices to monitor a single site, buy off-the-shelf. It will be cheaper and faster.

But if you need 500 devices, or if you need to monitor something specific that generic hardware can't handle, custom is the only way to go. The unit cost drops significantly once you move past the NRE (Non-Recurring Engineering) costs.

Conclusion

Designing a custom IoT device for remote monitoring is a balance of hardware, firmware, and regulatory discipline. It’s about choosing the right radio (nRF52 vs. ESP32), the right protocol (MQTT vs. Modbus), and the right battery strategy.

If you are dealing with legacy equipment—like those arcade machines we mentioned—you might also want to consider the software side of the equation. The embedded firmware is critical, but the backend matters too. Often, clients realize that their existing arcade machine software isn't capable of parsing the new MQTT streams we are sending. In that case, we provide a translation layer or a custom API gateway to bridge the gap.

The result is a device that fits your exact footprint, reports the exact metrics you care about, and runs for years without maintenance. That is the payoff for the complexity. It’s not easy, but it works.

Top comments (0)