These two chips show up on the same shortlist constantly, and the comparison is more interesting for how it clarifies what each one is built for than for declaring an overall winner — because once the two architectures are understood clearly, most real products don't need to choose between them at all. They need to choose which one owns which job. What the STM32WL Actually Is STMicroelectronics markets the STM32WL as the first true LoRa system-on-chip — a single die combining

A large industrial gantry crane's motor bearing fails without warning, taking the crane offline during a critical loading window and costing far more in downtime than the bearing itself was ever worth. This is the specific, recurring failure this class of monitoring system exists to prevent, and the honest engineering answer to "can we predict this" is: yes, with real confidence, but only with the right combination of sensors, edge processing, and a communication architecture

For most of embedded systems' history, firmware engineers and network engineers could work in adjacent lanes without much friction. Firmware owned the device; the network was a pipe it wrote bytes into. That separation is breaking down, and not because either discipline changed — it's breaking down because the constraints each discipline was built to solve now interact directly, and neither side's default mental model accounts for the other's failure modes. Two concrete cases

The Number on the Box Is Not a Deployment Specification Every LoRa module datasheet has a range figure. 10 km. Sometimes 15 km. The number is real — under the right conditions, LoRa can achieve that range. Those conditions are: line of sight between antennas, antennas at height, correctly matched 50-ohm antenna systems at both ends, a spreading factor of SF12 (at the cost of very low data rate), and no significant interference on the 865–867 MHz (India) band. Real deployments

Three months after deployment of a 120-node IoT network, the engineering team discovered a timing bug in the transmission scheduler. Under specific load conditions, nodes would collide on the shared RF channel, causing packet loss that cascaded into data gaps. The fix was 12 lines of firmware code. Review, test, and validation took two days. The field update took eight days, two engineers, and travel across three districts. Because there was no OTA mechanism in the firmware.

The Wrong Starting Point Most connectivity decisions in embedded IoT development begin in the wrong place. They begin with the engineer's familiarity. The team has shipped three products with a cellular module. They reach for cellular again. A developer has spent two weeks getting a LoRa gateway running on a previous project. LoRa goes on the shortlist before the deployment requirements are written. The Wi-Fi stack is already in the microcontroller. Why not use it? This is no

When you first encounter LoRaWAN, it feels almost magical. You place a tiny device in your hand, powered maybe by a coin cell, and it whispers a few bytes across a vast distance — sometimes kilometres — landing neatly in a gateway as if by telepathy. For someone who grew up in the world of Wi-Fi and 4G, the idea that a packet can travel so far with so little energy almost feels wrong. But the magic ends very quickly when you connect a real sensor to that device. Because senso

When someone builds their first IoT product — a tracker, sensor node, wearable, EV telematics device, or LoRa gateway — everything feels smooth until one point: RF certification. The PCB works perfectly. Firmware runs fine. Power efficiency looks great. And then the certification quote arrives — costing more than your entire BOM budget. That’s when most founders realize: Getting a radio to transmit is easy. Getting it legally certified is hard. RF certification isn’t about wh

The Internet of Things (IoT) is a global phenomenon. But unlike the internet, where TCP/IP creates a near-universal layer, IoT connectivity remains fragmented by region. The reason is simple: Spectrum regulations differ across countries. Telecom operator strategies vary. Industry ecosystems have evolved differently. Proprietary protocols and legacy systems remain entrenched in some markets. The result? A logistics tracker built for NB-IoT in China may not work in the US, whil

Over the past six parts of this series, we’ve explored the entire spectrum of IoT communication technologies – from cellular and satellite IoT (NB-IoT, 5G, Starlink) to short-range wireless (BLE, ZigBee, Wi-Fi), LPWAN (LoRa, Sigfox, Mioty), wired/optical systems (Ethernet, KNX, Fiber), and industrial-grade mission-critical protocols (Wireless HART, ISA100, DECT-2020, TETRA). Now, in this final part, we’ll look ahead to what’s next for IoT connectivity. Technology never stands

When we think of IoT at city-scale, agriculture fields, utility grids, or industrial campuses, we need networks that can connect devices spread over kilometers while still keeping power consumption ultra-low. This is where LPWAN (Low Power Wide Area Networks) and sub-GHz technologies shine. They fill the gap between short-range protocols (BLE, ZigBee, Wi-Fi) and cellular IoT (NB-IoT, LTE-M, 5G) by offering: Long-range coverage (1–15 km, sometimes more). Ultra-low power (batte

In the previous article, we explored the big picture of IoT communication technologies. We saw that IoT is inherently multi-protocol, with each technology optimized for a unique balance of range, power, bandwidth, and cost. In this part, we zoom in on one of the most critical pillars of IoT: cellular and satellite networks. These technologies deliver nationwide and global connectivity, allowing IoT devices to connect across cities, countries, and oceans — something short-rang

IoT (Internet of Things) is not just about smart sensors and connected devices. At its core, IoT is about communication — how billions of devices exchange data reliably, securely, and efficiently. Without the right communication technology, IoT is just “things” without the “internet.” But here’s the challenge: there is no single best protocol for IoT. Instead, we have a broad landscape of technologies — each with its own strengths, weaknesses, and use cases. From short-range

By CH Durga Prasad, Embedded Engineer at EurthTech Every embedded project starts with a decision that quietly shapes everything else that follows: Do we go with baremetal or use a Real-Time Operating System (RTOS)? It sounds like a technical formality. But in reality, this is where the architectural DNA of your product is formed. At EurthTech, we’ve lived through both sides of this debate—sometimes learning it the hard way in real deployments. This is the story of how we evo

By Srihari M, Director Product Development at EurthTech Published on March 18, 2025 With the Concept Refinement Phase completed, the next step is the System Integration Phase, which brings together hardware, firmware, and software into a fully functional, reliable, and scalable system. This phase is crucial for embedded systems development, IoT product engineering, and smart infrastructure solutions. The System Integration Phase consists of four key areas: Hardware and Firmwa