Connectivity & Protocols

Three serial standards, all older than most engineers using them today, all still very much alive in industrial hardware because nothing has fully displaced any of them. Picking wrong isn't usually fatal — there's almost always a converter that can bridge two of these after the fact — but picking wrong costs real integration time discovering the mismatch the hard way, usually mid-project rather than at the spec stage. Here's what distinguishes them, with real numbers, not jus

The vibration meter sitting in the parts bin was exactly the right instrument for the job — the right sensitivity range, the right form factor, already owned rather than needing a new purchase order. It had one problem that nearly disqualified it entirely: it spoke RS-232, point-to-point, no multidrop, and the project needed a bus architecture that RS-232 flatly can't provide. The RS-485 version of the same meter existed. It cost more, wasn't in stock, and the lead time didn'

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

Here's the rule: bandwidth and sample rate answer two different questions, and a scope that's generous on one while thin on the other will misrepresent a real signal in a specific, predictable way. Most bench engineers can recite that "more bandwidth is better" and "more samples per second is better," without necessarily being able to say what either number protects against — which makes it easy to overspend on the wrong spec, or underspend on the one that actually matters fo

A remote industrial site — far enough from any cellular tower or LoRaWAN gateway coverage that terrestrial connectivity simply isn't an option — still needs its sensor data to reach a central monitoring location, reliably and securely. Satellite communication is the obvious answer to the reachability problem and a genuinely non-obvious engineering problem once security and cost enter the picture, because satellite airtime is expensive per byte in a way terrestrial connectivit

The MCU selection meeting for a new battery-powered BLE wearable tends to follow a predictable pattern: someone proposes the chip the team already has experience with, someone else pulls up a deep-sleep current figure from a datasheet, and the decision gets made on incomplete information because a genuinely thorough comparison — across deep sleep current, active RX/TX current, peripheral set, toolchain maturity, and real sourcing availability — takes longer than the meeting h

A team building their first custom BLE product almost always makes the same early mistake: designing the GATT profile as a data model first — what fields does the device need to expose — and treating the power and timing consequences of that model as an afterthought to optimize later. By the time "later" arrives, the profile is baked into a mobile app's integration code and a certification submission, and the actual fix (restructuring which data lives in which characteristic,

A medical adherence wearable — a device that clips onto a bottle or sits on a patient's hand to detect and log a specific medication-use gesture — sounds, on paper, like a simple embedded project: an accelerometer, a Bluetooth radio, a battery. The first power budget spreadsheet we built for exactly this kind of device came back at 4 days of battery life on a 250mAh cell, against a target of six weeks. Getting from 4 days to 39 wasn't one clever trick — it was a systematic pa

A safety-critical device — a personal tracker with an SOS function, in the case that shaped this post — has one requirement that overrides almost every other design preference: it has to work the first time, every time, in exactly the low-connectivity conditions where a user is most likely to actually need it. A cloud-dependent architecture, with a phone app talking to a backend server that then notifies a caregiver, adds several links to a chain that all have to hold — the d

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

The Field Failure That the Bench Cannot Reproduce The system worked perfectly in the lab. Every node communicating, every message received, error counters at zero. The engineer was confident. The system was deployed into a running machine — a conveyor line, an industrial press, a pump station — and within hours, CAN error frames appeared. Within days, nodes were going bus-off. Within a week, the customer was calling. Back on the bench, everything works again. The cable is the

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

Reading Time: 25 mins Topic: IoT Architecture & Scalability Bridging the gap between academic projects and industry reality. Global IoT Network The Hook: Why Your MVP SDK Won't Survive Production Building an IoT device that connects to the cloud and sends telemetry is easy. Doing it for one device is a weekend project. Doing it for a hundred devices is a manageable pilot. But what happens when you need to deploy 1,000,000 devices across 50 countries, spanning three major clou

Author: Srihari Maddula Reading Time: 25 mins Topic: Wireless Networking & BLE Reliability Radio waves don't care about your laboratory results. Photo via Unsplash. In a development lab, Bluetooth Low Energy (BLE) feels like magic. Your device is 2 feet away from your smartphone, the connection is instant, and the data transfer is flawless. You celebrate, wrap the project, and ship it. But then, the field reports start coming in: "The connection drops as soon as I put the pho

Author: Srihari Maddula Reading Time: 18 mins The traces on your board carry more than just data; they carry physics. Photo by Unsplash. In an engineering college lab, the choice between I2C and SPI is often made based on which library is easier to include or which tutorial is more popular on YouTube. Students see them as interchangeable "serial protocols" that move data from Point A to Point B. If the sensor is detected and the value prints to the Serial Monitor, the job is

Srihari Maddula Many IoT devices fail without ever violating a single specification. They pass certification, meet datasheet limits, conform to protocol requirements, and behave exactly as they were designed to. Yet months or years after deployment, reliability degrades, data quality drops, or behaviour becomes unpredictable. Nothing dramatic breaks. Nothing obviously violates a requirement. The system simply stops being trustworthy. This is one of the most uncomfortable fail

Srihari Maddula Many IoT deployments fail in ways that are deeply frustrating to engineering and business teams alike. The device meets the protocol specification. The radio link budget checks out. Power calculations show comfortable margins. Certifications are complete. Vendors confirm compliance. And yet, in the field, the system does not behave as expected. Commands are missed. Actuators fail to respond when needed. Devices require more maintenance than planned. Reliabilit

Bluetooth Low Energy is often treated as a solved problem. A protocol stack exists. Reference designs are available. Development boards connect easily to smartphones. From the outside, BLE appears to be a mature, well-documented technology that can be dropped into an embedded product with minimal risk. This perception is precisely why BLE-related failures are so common after deployment. In real products, BLE is not just a protocol. It is a system behavior that interacts with

Most businesses believe digital transformation begins in the cloud. They talk about dashboards, analytics, automation, predictive insights, and AI-driven decisions. Boardroom conversations revolve around visibility, efficiency, compliance, and cost optimization. Somewhere in the middle of these discussions, a quiet assumption is made: that the data feeding all of this intelligence will simply “exist”. In reality, digital transformation does not start in the cloud. It starts o