Internet Of Things Devices

Why is Bluetooth more common than Wi-Fi in battery-powered IoT devices? The answer is high cost and high power consumption of Wi-Fi. But why is that? Despite Wi-Fi having many advantages over Bluetooth such as higher range, significantly higher throughput, WPA3 security, and being IP addressable, Bluetooth still prevails in certain use cases. The primary reason for higher power consumption in Wi-Fi is because of the OFDM-based PHY layer, which has a high peak to average power ratio (PAPR). This leads to operating the power amplifier (PA) very inefficiently, with the PA efficiency during Wi-Fi transmission being less than 10% whereas Bluetooth PA efficiency is 50%. To transmit 1 mW Wi-Fi frame, we need to spend 10 mW of DC power, whereas to transmit 1mW Bluetooth frame, we burn only 2 mW DC power. Especially, consider the fact that after Wi-Fi 6 the number of OFDM subcarriers have quadrupled (256 subcarriers in 20 MHz bandwidth). Bluetooth on the other hand uses constant envelope modulation scheme ( papr=0 db) such as FSK. LORA, Zigbee and 802.11ad are few other standards using constant envelope modulation schemes. If only Wi-Fi had defined a constant envelope modulation PHY, the game may have been different in IoT. Another major issue is cost, and in my opinion, that is because of unnecessary baggage of features being required by IEEE and Wi-Fi alliance for certification purposes. Several Wi-Fi features are not really needed for battery powered IOT devices such as wireless door lock for example. Finally, the RX power consumption of Wi-Fi is higher owing to higher RX bandwidth, higher ADC sampling rate, and uncertainty in listen state duration owing to no guarantee service periods during power save operation. While Target Wake Time (TWT) made an attempt, it wasn’t really successful because TWT service periods are not reserved, and any client can barge into another client’s TWT service period for sending its uplink traffic. Overall, the high cost and power consumption of Wi-Fi make Bluetooth a more attractive option for battery-powered IoT devices.

Edge capability and conditional transmission ... How edge computing on LPWAN devices extends the battery life by factor of 4 As industrial IoT systems continue to scale across critical infrastructure—pipelines, reservoirs, remote assets, and urban utilities—one question persists across all engineering teams: "How do we make the device smarter without draining the battery faster or make the firmware more complex?" The answer is not in more power—it’s in more intelligence at the edge. > What Is #EdgeCapability in #LPWAN Devices? Edge capability refers to the ability of the device to process and analyze data locally, before deciding whether to transmit it over the network. This is a critical advancement in the design of battery-powered LPWAN devices—whether #LoRaWAN, #NB-IoT, or #LTE-M. Instead of blindly transmitting data at fixed intervals, smart edge devices evaluate conditions such as: - Threshold violations (e.g., pressure above X bar) - Anomalous patterns (e.g., sudden temperature spike) - Predictive failure signals (via trend detection) Only when action is needed, do they transmit. > Why Conditional Transmission Changes the Game Let’s take a real-world example from our deployments at Ellenex: - Scenario A: Traditional Mode Transmit every 15 minutes (fixed schedule) 96 transmissions/day Average battery life: < 1 year - Scenario B: Edge Mode with Conditional Transmission Sample every 5 minutes Transmit only when threshold conditions are met or at max once per day 1–5 transmissions/day depending on conditions Average battery life: 3.5–4 years By eliminating unnecessary network sessions, power-hungry radio activations, and overhead from MAC layer interactions, energy usage drops dramatically. > Implications for Industrial Use Cases Water Utilities can detect leaks without flooding the network with data. Smart Agriculture devices react only to critical soil moisture levels, not morning dew. Asset Monitoring for pressure, level, vibration, or flow becomes cost-effective in remote areas. And most importantly: maintenance intervals are extended dramatically. Battery replacements become rare events, not monthly line items. > What This Means for Product Designers When we design LPWAN devices at Ellenex, edge intelligence is not optional—it’s a core requirement. Every mA-hour counts. We, at Ellenex Industrial IoT, design products with: - Smart wakeup logic - Configurable edge thresholds - Modular firmware to enable OTA updates of local logic Because the edge is not just about faster insights—it’s about operational viability. Final Thought Nowadays, data is only valuable when it's actionable—and battery life is only long when data knows when not to leave the device. Edge capability + conditional transmission provides longer life, smarter systems, and scalable deployments. If you're still pushing data every 15 minutes—it is time to re-think 🤔 . #monitoring #IoT #ellenex #EdgeComputing #LPWAN #batterylife

🔋 The Unsung Hero of IoT Devices: Power Management Done Right When discussing IoT devices, most people focus on connectivity (Wi-Fi, BLE, LoRa), sensors, and firmware features. But the factor that truly determines whether your product succeeds in the field is power management. Without it, even the most advanced design can fail. ⚡ Why Power Management Matters A typical ESP32-CAM or Wi-Fi-based IoT board can draw 120–240mA during active transmission. Without optimization, a standard Li-ion battery may last just a few hours. With sleep modes, efficient power regulation, and smart duty cycling, you can extend runtime to days, weeks, or even months depending on the use case. 👉 In IoT, battery life = product usability. 🔑 Practical Power Optimization Strategies ✅ Use Deep Sleep Aggressively Most MCUs (ESP32, STM32, RP2040) can drop to tens of µA in deep sleep. Wake up, capture data, send it, then return to sleep. ✅ Choose the Right Regulator Select low-dropout regulators (LDOs) with low quiescent current. For battery applications, a switching regulator (buck converter) often provides higher efficiency than an LDO. ✅ Design PCB for Power Efficiency Place decoupling capacitors close to high-current devices like radios and cameras. Separate analog and digital grounds to minimize noise and wasted power. ✅ Select Communication Wisely Wi-Fi: High power, short bursts — best for images or larger data packets. BLE / Zigbee / LoRa: Much lower average power — ideal for periodic sensor data. 📊 Real-World Lesson In one IoT monitoring project: Initial design (Wi-Fi + no sleep): battery drained in under a day. Optimized design (deep sleep + burst Wi-Fi + efficient regulator): runtime extended to several weeks on the same cell. That’s the difference between a prototype and a deployable solution. 🎯 Key Takeaway Power management is not an afterthought — it’s the foundation of IoT design. Great firmware and sensors don’t matter if your device shuts down after a few hours. 👉 For every IoT or embedded project, treat power as a first-class design parameter — plan for it, measure it, and optimize it. 💬 What’s the biggest challenge you’ve faced in low-power IoT design? Let’s share real-world lessons 👇 #IoT #EmbeddedSystems #PowerManagement #ESP32 #PCBDesign #LowPowerIoT #FirmwareDevelopment #ElectronicsEngineering #HardwareDesign #EmbeddedEngineering #IoTDevelopment Disclaimer:This image was generated using AI for illustrative and educational purposes only. While it represents engineering concepts at a high level, certain technical details, dimensions, or component behaviors may not be fully accurate. Always consult official datasheets, manufacturer documentation, and domain experts before making design, hardware, or firmware decisions. This content is intended to raise awareness and share general insights, not to replace professional engineering guidance.

There's a temptation in IoT to push out more data just because you can - the assumption being more updates equal better insights. But the real win isn’t in collecting data; it’s knowing when to send it. This challenge isn’t just a software problem or a hardware problem - it’s both. You might ship a device with excellent low-power hardware, yet the software doesn’t fully leverage its capabilities. Or the hardware might be built assuming constant connectivity because the team hasn't set clear thresholds for when data actually matters. The result? Unnecessary data transfers, wasted battery, and system underperformance.  The best-performing IoT products get it right from the start. Hardware and software teams align early on: ↳ What data truly matters? ↳ What can be processed at the edge? ↳ And when should the data be transmitted? By shifting from real-time updates to time-based or event-driven updates, devices can power down connectivity during idle periods - we’ve seen power savings of 50% in some cases.  Looking ahead, AI-driven scheduling will be a major focus in 2025. We’re going to use software to smartly predict the best moments to transmit - balancing power constraints with real-world   conditions - while not overcomplicating algorithms that operate at the edge.  Ultimately, it’s not about constant connection - it’s about constant awareness. Deliver the right data at the right time, and your devices will last longer, perform better, and yield smarter insights. Like, Comment or Follow for more IoT insights.

In IoT and battery-operated embedded systems, power efficiency is often just as critical as processing capability. The ESP32-C6, a RISC-V-based MCU from Espressif, is equipped with multiple sleep modes that enable designers to finely control power usage depending on the system’s activity levels. This guide delves into the effective use of Modem Sleep, Light Sleep, and Deep Sleep modes on the ESP32-C6, providing practical code examples and configuration tips that utilize the ESP-IDF framework and FreeRTOS.

👩🎓 Energy consumption with #LPWAN nodes 👩🎓. Articles on energy consumption in the LPWAN world are often written by marketing staff with no knowledge of electrical engineering, radio technology or physics. This often results in incorrect texts that editors repeat without specialised knowledge. 🔋 Energy = voltage x current x time. Looking only at the peak current is technically incorrect. Due to its 23 dBm transmission power, #NBIoT automatically has a higher peak current than 14 dBm with #LoRaWAN or Sigfox. The peak currents of LPWAN SoCs have fallen in recent years due to improvements in the power amplifiers. 🔋 The standby currents for all LPWAN technologies are now so low that they are no longer so important compared to the energy consumption for TX. A standby current of 2 to 3 uA is required to store data in RAM and keep the MCU in operation. In addition, there are currents for sensors and self-discharge of the battery. In total, this is often 8 to 10 uA. ‼️ As NB-IoT has to reattach before transmitting, and there is no reattachment with #Mioty, #Sigfox and #LoRaWAN, #NBIoT requires the most energy. LPWAN technologies in the licence-free band transmit without synchronisation (Aloha principle). 😀 As Mioty requires approximately 3.5 times less time for 13 bytes than LoRaWAN, Mioty is the benchmark in energy consumption. With the #STM32WL3 SoC, energy consumption during transmission has been reduced again. The result is 24 mWs with a 161 dB link budget. LoRaWAN requires 220 mWs, Sigfox approximately 800 mWs and NB-IoT approximately 12000 to 24000 mWs. 🌐 Globally, Mioty is the most modern LPWAN. Its energy consumption is the lowest, it has the widest range of functions and the largest frequency range. It also provides the longest range and the best forward correction. 💰 Because the battery is the most expensive component in an LPWAN sensor and Mioty SoC only costs approximately 1 Euro, a Mioty sensor is unbeatable in price. If you combine Mioty with NBIoT /LTEM you get the largest area with the lowest energy consumption. Mioty with drones and aircraft enables the cheapest NTN networks worldwide. 📉 The peak current of LPWAN SoCs (NB-IoT, LTE-M, Mioty, Sigfox and LoRaWAN) has fallen several times in recent years. The time requirement is constant for the LPWAN because nothing has changed in the modulation and the protocol for 13 bytes has remained constant for almost 10 years. LPWAN 13 bytes: 🔹 NB-IoT (164 dBm) 53000 mWs 🔹 NB-IoT (154 dBm): 5300 mWs 🔹 Sigfox (156 dBm): 810 mWs 🔹 LoRaWAN (161 dBm): 222 mWs 🔹 Mioty ER (167 dBM): 196 mWs 🔹 Mioty Standard (161 dBm): 49 mWs 🔹 Mioty Standard with STM32LW3 (161 dBm): 24 mWs If you use newer LoRa SoCs, it becomes slightly less than 222 mWs. LoRa will never reach 24 mWs. 🏫 In the "Beyond LPWAN" webinar, we go into the innovations explained by experts. Be part of it. Register without obligation in the comments below. harald.naumann (at) antennity .com

We obsess over shaving microamps in firmware while ignoring the real power vampire: power integrity collapse. After debugging three field failures in battery-powered medical devices, I’ve learned the hard way: Your firmware optimizations mean nothing if your power delivery network (PDN) is lying to you. Case Study 1: A "5µA sleep mode" IoT sensor kept dying overnight. Root cause? A 4.7µF ceramic capacitor’s resonant frequency (150MHz) coincided with the DC-DC converter’s switching frequency. Result: 200mA current spikes every 10ms, draining the battery in 6 hours instead of 6 months. Case Study 2: An automotive ECU resetting during cold starts. Issue? Voltage droop (-1.2V below nominal) when the fuel injector fired. The 3.3V rail dipped to 1.8V for 500ns, just enough to corrupt the RTC’s shadow registers. Why We Ignore PDN: Toolchain Blindness: Most embedded IDEs can’t simulate PDN impedance. We optimize code in a vacuum. Component Myopia: We select MCUs for "low power specs" but ignore that 80% of power issues stem from passive components. Frequency Illusion: We assume DC-DC converters "just work" without checking: Control loop stability (phase margin <45° = oscillations) Output capacitor ESR (too low = ringing; too high = ripple) Layout inductance (via stubs adding 2nH = 20mV overshoot) The Fix: PDN-First Design Step 1: Simulate PDN impedance (e.g., Keysight ADS) from DC to 1GHz. Target: <0.1Ω up to 50MHz. Step 2: Use mixed capacitor types: Bulk electrolytics (100µF+) for low-frequency stability X7R ceramics (1-10µF) for mid-frequency decoupling NP0/C0G (100nF) for high-frequency noise (>100MHz) Step 3: Layout rules: Place decoupling caps <3mm from MCU power pins Use 20mil+ power traces (reduce inductance by 40%) Split ground planes? NO. Use solid ground under switching components. The Ugly Truth: Most "low-power" designs fail because we treat power as an electrical problem, not a system-level physics problem. Your firmware’s sleep mode is irrelevant if your PDN is a noise generator. Question: What’s your worst power integrity horror story? Bonus points if it involved a capacitor resonance or ground bounce. #PowerIntegrity #EmbeddedDesign #PDN #EMI #Hardware

 𝗘𝗺𝗯𝗲𝗱𝗱𝗲𝗱 𝗙𝗶𝗿𝗺𝘄𝗮𝗿𝗲 𝗨𝗽𝗱𝗮𝘁𝗲 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀 🔄 One of the scariest moments in embedded systems: pushing a firmware update to 1 million devices in the field. 𝗔 𝗳𝗮𝗶𝗹𝗲𝗱 𝘂𝗽𝗱𝗮𝘁𝗲 𝗰𝗮𝗻 𝗺𝗲𝗮𝗻:  • Devices that won't boot (bricking)  • Security vulnerabilities exposed  • Revenue loss (smart home devices going offline) Here's how professional firmware engineers handle this:  • 𝗗𝘂𝗮𝗹-𝗕𝗮𝗻𝗸 𝗕𝗼𝗼𝘁𝗹𝗼𝗮𝗱𝗲𝗿 - Keep running firmware on Bank A, update to Bank B, validate, then switch  • 𝗥𝗼𝗹𝗹𝗯𝗮𝗰𝗸 𝗠𝗲𝗰𝗵𝗮𝗻𝗶𝘀𝗺 - Always maintain the previous working version  • 𝗗𝗲𝗹𝘁𝗮 𝗨𝗽𝗱𝗮𝘁𝗲𝘀 - Send only changed bytes (reduce bandwidth by 90%)  • 𝗦𝘁𝗮𝗴𝗲𝗱 𝗥𝗼𝗹𝗹𝗼𝘂𝘁 - Deploy to 1% of devices, monitor, then 100% 𝗟𝗲𝘀𝘀𝗲𝗿-𝗞𝗻𝗼𝘄𝗻 𝗙𝗮𝗰𝘁: The infamous Jeep hack (2015) was possible because the entertainment system's firmware could be remotely updated without proper authentication. Embedded devices need firmware security as much as application security. #FirmwareUpdates #IoT #Bootloader #Security #EmbeddedFirmware #TechTips

⚡🔋𝐑𝐞𝐝𝐮𝐜𝐞 𝐏𝐨𝐰𝐞𝐫 𝐂𝐨𝐧𝐬𝐮𝐦𝐩𝐭𝐢𝐨𝐧 𝐢𝐧 𝐄𝐦𝐛𝐞𝐝𝐝𝐞𝐝 𝐒𝐲𝐬𝐭𝐞𝐦𝐬⚡🔋 "Engineering is the art of doing that well with one dollar which any bungler can do with two." When your Embedded/IoT project is powered by a wall plug, power consumption might not be your biggest concern. But when running on batteries, every milliamp counts! Optimizing for low power is a critical design goal in embedded systems, especially in battery-operated and remote IoT applications. Efficient power management can significantly extend battery life, reduce heat, and improve overall system reliability. 𝑯𝒐𝒘 𝒕𝒐 𝑴𝒊𝒏𝒊𝒎𝒊𝒛𝒆 𝑷𝒐𝒘𝒆𝒓 𝑪𝒐𝒏𝒔𝒖𝒎𝒑𝒕𝒊𝒐𝒏 𝒊𝒏 𝑬𝒎𝒃𝒆𝒅𝒅𝒆𝒅 𝑫𝒆𝒔𝒊𝒈𝒏𝒔:- 🔹 1. 𝐎𝐩𝐭𝐢𝐦𝐢𝐳𝐞 𝐒𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐟𝐨𝐫 𝐏𝐨𝐰𝐞𝐫 𝐄𝐟𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐲 Use interrupt-driven programming instead of polling. Utilize DMA (Direct Memory Access) to offload CPU tasks. Implement dynamic duty cycling to reduce active processing time. 🔹 2. 𝐔𝐬𝐞 𝐋𝐨𝐰-𝐏𝐨𝐰𝐞𝐫 𝐌𝐨𝐝𝐞𝐬 𝐄𝐟𝐟𝐢𝐜𝐢𝐞𝐧𝐭𝐥𝐲 Modern ARM Cortex-M MCUs provide multiple sleep modes, allowing developers to balance power consumption and responsiveness: Sleep Mode – CPU halts while peripherals remain active. Deep Sleep Mode – System clocks & unused peripherals are disabled. Stop Mode – Almost all clocks stop, but RAM is retained. Standby Mode – Most of the system is powered down, only wake-up sources remain active. Shutdown Mode – The lowest power state with minimal retention. Example: In Cortex-M3/M4, using Deep Sleep with an RTC wake-up can reduce power consumption to microamps while maintaining scheduled tasks. 🔹 3. 𝐒𝐦𝐚𝐫𝐭 𝐏𝐞𝐫𝐢𝐩𝐡𝐞𝐫𝐚𝐥 & 𝐈/𝐎 𝐌𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 Turn off unused peripherals when not in use. Use low-power timers instead of high-frequency system clocks. Optimize communication protocols (e.g., BLE over Wi-Fi, LPWAN for IoT). 🔹 4. 𝐃𝐲𝐧𝐚𝐦𝐢𝐜 𝐂𝐥𝐨𝐜𝐤 𝐒𝐜𝐚𝐥𝐢𝐧𝐠 & 𝐕𝐨𝐥𝐭𝐚𝐠𝐞 𝐎𝐩𝐭𝐢𝐦𝐢𝐳𝐚𝐭𝐢𝐨𝐧 Lower the CPU clock frequency when full performance isn't needed. Use dynamic voltage scaling (DVS) to adjust power consumption based on processing load. Select low-power external oscillators to reduce idle power consumption. 🔹 5. 𝐈𝐝𝐞𝐧𝐭𝐢𝐟𝐲 & 𝐑𝐞𝐝𝐮𝐜𝐞 𝐋𝐞𝐚𝐤𝐚𝐠𝐞 𝐂𝐮𝐫𝐫𝐞𝐧𝐭 Use MOSFET-based power gating to disconnect unused circuits. Optimize PCB design to reduce leakage paths and unnecessary current flow. Choose low-power components (e.g., switching regulators instead of LDOs). Reducing power consumption isn't just about making devices run longer on a battery—it also enables smaller form factors, lower heat dissipation, and better overall efficiency. Whether you're working on an IoT device, industrial sensor, or consumer gadget, smart power optimization can make a huge difference. What are some of your favorite techniques for power optimization in embedded systems? Let's discuss! 👇🚀 #ShivamCDAC #embeddedsoftware #firmware #lowpower #programming #armcortex #embeddedsystems #iot

Azure Firmware Analysis - heads up to everyone working in IoT, OT, cybersecurity, and embedded systems: Azure Firmware Analysis is GA! 🚀 Thousands of sensors, IoT, OT, and even network devices scattered all over facilities, with long patch cycles and even longer development cycles. Unlike traditional IT endpoints which often run security agents, IoT/OT and network devices frequently function as “black boxes”: you have little visibility into what software they’re running, which patches are applied, or what vulnerabilities might exist within them. This is the challenge many organizations face with IoT/OT and networking equipment - when a critical vulnerability is disclosed, how do you know which devices are at risk? Firmware is one of the last true blind spots in most environments. Devices look healthy on the surface, but underneath can live hard-coded creds, outdated libs, and insecure builds. Vulnerabilities here don’t just create risk, they often bypass a lot of the traditional detection layers. Azure Firmware Analysis gives security teams, integrators, and builders a way to "see inside the box", shifting from a “black box” to an auditable, testable surface area. ✅ Automated firmware unpacking and analysis (no reverse engineering!) ✅ SBOM generation with CVE lookup and severity tagging ✅ Detection of hard-coded credentials, keys, and certificates ✅ Binary hardening checks (NX, ASLR, stack protections, etc.) ✅ Detection of outdated or vulnerable libraries and components ✅ Support for embedded Linux images up to 1 GB ✅ Clear, actionable security findings in the Azure Portal ✅ Continuous updates for new signatures and parsing improvements Making firmware visible, measurable, makes for an even stronger IoT/OT story on Azure. Good stuff! 🔗 https://lnkd.in/euMXfZry #Azure #MicrosoftAzure #IoT #OT #Cybersecurity #OTSecurity #Firmware #SecurityArchitecture