<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Antony Mapfumo</title><link>https://mapfumo.github.io/</link><description>Recent content on Antony Mapfumo</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Tue, 28 Apr 2026 12:23:09 +1000</lastBuildDate><atom:link href="https://mapfumo.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>921 Metres Through Suburban Brisbane with a LoRaWAN Node — Here's What the Data Showed.</title><link>https://mapfumo.github.io/posts/2026/april/i-walked-921-metres-with-lorawan-node-here-is-what-the-data-showed/</link><pubDate>Tue, 28 Apr 2026 12:23:09 +1000</pubDate><guid>https://mapfumo.github.io/posts/2026/april/i-walked-921-metres-with-lorawan-node-here-is-what-the-data-showed/</guid><description>&lt;h2 id="the-setup">The Setup&lt;/h2>
&lt;p>I built a two-node LoRaWAN sensor network on STM32WL55JC1 microcontrollers running Rust/Embassy firmware — the full story is in &lt;a href="https://mapfumo.github.io/posts/2026/april/building-a-lorawan-sensor-network-in-rust-stm32wl55-embassy-and-the-bugs-that-taught-the-most/">Part 1&lt;/a>. One of the two nodes, lora-2, carries no sensor. Its only job is to send a confirmed uplink every ~10 seconds, display RSSI, SNR, and DR on its OLED, and let the gateway&amp;rsquo;s InfluxDB record tell the story later.&lt;/p>
&lt;p>You might wonder why I didn&amp;rsquo;t just use lora-1 — the sensor node — for this test. Both nodes send a 4-byte payload, so packet size is identical and makes no difference to range. What matters is transmission behaviour: lora-2 sends every uplink confirmed, so a missed ACK is detected within one cycle. lora-1 only confirms every fifth uplink, meaning gateway loss takes much longer to register. lora-2 also transmits every ~10 seconds versus lora-1&amp;rsquo;s ~30 seconds — three times the data points in InfluxDB, three times the resolution when overlaying against GPS waypoints later. Purpose-built beats repurposed.&lt;/p></description></item><item><title>Building a LoRaWAN Sensor Network in Rust — STM32WL55, Embassy, and the Bugs That Taught Me the Most</title><link>https://mapfumo.github.io/posts/2026/april/building-a-lorawan-sensor-network-in-rust-stm32wl55-embassy-and-the-bugs-that-taught-the-most/</link><pubDate>Tue, 28 Apr 2026 12:21:14 +1000</pubDate><guid>https://mapfumo.github.io/posts/2026/april/building-a-lorawan-sensor-network-in-rust-stm32wl55-embassy-and-the-bugs-that-taught-the-most/</guid><description>&lt;h2 id="from-sensor-to-dashboard--without-a-line-of-c">From Sensor to Dashboard — Without a Line of C&lt;/h2>
&lt;p>My previous projects used the STM32F446RE — a capable workhorse, but one that needs an external LoRa radio module wired up separately. When I decided to go deep on LoRaWAN, I wanted a chip where the radio was part of the silicon itself. The STM32WL55JC1 delivers exactly that: an ARM Cortex-M4 application processor and a sub-GHz radio coexisting on the same die, talking to each other over an internal SPI bus that never leaves the package.&lt;/p></description></item><item><title>Building a Multi-Protocol Industrial IoT Gateway: LoRaWAN, Modbus TCP, and BACnet/IP</title><link>https://mapfumo.github.io/posts/2026/february/building-a-multi-protocol-industrial-iot-gateway-lorawan-modbus-tcp-and-bacnet-ip/</link><pubDate>Sun, 01 Feb 2026 17:01:44 +1000</pubDate><guid>https://mapfumo.github.io/posts/2026/february/building-a-multi-protocol-industrial-iot-gateway-lorawan-modbus-tcp-and-bacnet-ip/</guid><description>&lt;p>When industrial facilities need to monitor equipment and environmental conditions, they often face a challenge: different systems speak different languages. A temperature sensor in one part of the building might use Modbus TCP, while the HVAC system uses BACnet/IP, and wireless sensors communicate via LoRaWAN. Getting all this data into one place typically requires expensive proprietary gateways or complex integration projects.&lt;/p>
&lt;p>I built a solution that brings these three protocols together on a single platform, using open-source tools and commodity hardware.&lt;/p></description></item><item><title>Week 12: Mission Accomplished - From LED Blink to Production-Grade IIoT</title><link>https://mapfumo.github.io/posts/2026/january/week-12-portfolio-complete-from-led-blink-to-industrial-iot-in-12-weeks/</link><pubDate>Mon, 26 Jan 2026 22:11:26 +1000</pubDate><guid>https://mapfumo.github.io/posts/2026/january/week-12-portfolio-complete-from-led-blink-to-industrial-iot-in-12-weeks/</guid><description>&lt;hr>
&lt;h2 id="-watch-the-full-demo">🎬 Watch the Full Demo&lt;/h2>
&lt;p>After 12 weeks of building, here&amp;rsquo;s the result: a production-grade Industrial IoT monitoring platform built from scratch.&lt;/p>
&lt;p>&lt;a href="https://youtu.be/hHb1stTLWLI">&lt;img loading="lazy" src="https://img.youtube.com/vi/hHb1stTLWLI/maxresdefault.jpg" alt="Industrial IoT Monitoring Platform" />
&lt;/a>&lt;/p>
&lt;p>&lt;strong>&lt;a href="https://youtu.be/hHb1stTLWLI">▶️ Watch on YouTube (6 minutes)&lt;/a>&lt;/strong>&lt;/p>
&lt;hr>
&lt;h2 id="what-i-built">What I Built&lt;/h2>
&lt;p>A complete Industrial IoT monitoring platform demonstrating expertise across the full stack:&lt;/p>
&lt;h3 id="hardware-4-sensor-nodes">Hardware (4 Sensor Nodes)&lt;/h3>
&lt;p>&lt;strong>LoRaWAN Nodes&lt;/strong> (STM32WL55):&lt;/p>
&lt;ul>
&lt;li>LoRa-1: SHT41 temperature/humidity sensor + SSD1306 OLED&lt;/li>
&lt;li>LoRa-2: BME680 environmental sensor + SH1106 OLED&lt;/li>
&lt;li>Native LoRa radio (no external modules)&lt;/li>
&lt;li>AU915 frequency band, OTAA join&lt;/li>
&lt;/ul>
&lt;p>&lt;strong>Modbus TCP Nodes&lt;/strong> (STM32F446):&lt;/p></description></item><item><title>Unifying the Chaos - One Dashboard for LoRaWAN, Modbus TCP, and Industrial Security - Wk11</title><link>https://mapfumo.github.io/posts/2026/january/week-11-unifying-the-chaos--one-dashboard-for-lorawan-modbus-tcp-and-industrial-security/</link><pubDate>Thu, 15 Jan 2026 20:52:25 +1000</pubDate><guid>https://mapfumo.github.io/posts/2026/january/week-11-unifying-the-chaos--one-dashboard-for-lorawan-modbus-tcp-and-industrial-security/</guid><description>&lt;h2 id="the-challenge">The Challenge&lt;/h2>
&lt;p>After 10 weeks, I had a problem. A &lt;strong>good&lt;/strong> problem, but a problem nonetheless:&lt;/p>
&lt;ul>
&lt;li>&lt;strong>Week 9&lt;/strong>: Two Modbus TCP nodes (STM32F446 + W5500 Ethernet)&lt;/li>
&lt;li>&lt;strong>Week 10&lt;/strong>: Two LoRaWAN nodes (STM32WL55 native radio)&lt;/li>
&lt;li>&lt;strong>Separate dashboards&lt;/strong>: Modbus data in one Grafana, LoRaWAN in another&lt;/li>
&lt;li>&lt;strong>Different buckets&lt;/strong>: &lt;code>modbus&lt;/code> bucket, &lt;code>lorawan&lt;/code> bucket&lt;/li>
&lt;li>&lt;strong>No unified view&lt;/strong>: Can&amp;rsquo;t compare all 4 nodes at once&lt;/li>
&lt;/ul>
&lt;p>&lt;strong>Week 11&amp;rsquo;s goal&lt;/strong>: &lt;strong>Unify everything into a single monitoring platform while analyzing what it would take to make this production-ready from a security perspective.&lt;/strong>&lt;/p></description></item><item><title>From LoRa Modules to Native LoRaWAN the STM32WL Migration - Wk10</title><link>https://mapfumo.github.io/posts/week-10-from-lora-modules-to-native-lorawan-the-stm32wl-migration/</link><pubDate>Sun, 11 Jan 2026 13:50:05 +1000</pubDate><guid>https://mapfumo.github.io/posts/week-10-from-lora-modules-to-native-lorawan-the-stm32wl-migration/</guid><description>&lt;h2 id="the-challenge">The Challenge&lt;/h2>
&lt;p>For the first 9 weeks of this project, I&amp;rsquo;ve been using RYLR998 LoRa modules - simple AT command modules that handled the radio work while my STM32 focused on sensors. They worked beautifully for point-to-point communication (600m range, 95% success rate), but they had a fundamental limitation:&lt;/p>
&lt;p>&lt;strong>They weren&amp;rsquo;t LoRaWAN.&lt;/strong>&lt;/p>
&lt;p>LoRa (the physical layer) is great for custom networks. But &lt;strong>LoRaWAN&lt;/strong> (the MAC layer protocol) is what you need for:&lt;/p></description></item><item><title>From IoT to Industrial Automation: Modbus TCP and OPC UA [Open Platform Communications Unified Architecture] - Wk9</title><link>https://mapfumo.github.io/posts/modbus-opcua-week-9/</link><pubDate>Sun, 04 Jan 2026 12:49:44 +1000</pubDate><guid>https://mapfumo.github.io/posts/modbus-opcua-week-9/</guid><description>&lt;p>Week 9 represents a fundamental shift in the project. For the past eight weeks, we&amp;rsquo;ve been building IoT systems - MQTT, InfluxDB, Grafana, cloud-oriented architectures. Week 9 is different.&lt;/p>
&lt;p>&lt;strong>Week 9 is industrial automation.&lt;/strong>&lt;/p>
&lt;p>This isn&amp;rsquo;t about publishing sensor data to the cloud. It&amp;rsquo;s about &lt;strong>PLC integration&lt;/strong>, &lt;strong>SCADA systems&lt;/strong>, and &lt;strong>factory floor protocols&lt;/strong>. It&amp;rsquo;s about Modbus TCP - the protocol that&amp;rsquo;s been running industrial plants since the 1970s. It&amp;rsquo;s about OPC-UA - the modern standard for industrial interoperability.&lt;/p></description></item><item><title>Complete IoT Telemetry Pipeline: From Sensors to Dashboards - Wk7, 8)</title><link>https://mapfumo.github.io/posts/complete-iot-telemetry-pipeline-from-sensors-to-dashboards/</link><pubDate>Sun, 28 Dec 2025 11:42:16 +1000</pubDate><guid>https://mapfumo.github.io/posts/complete-iot-telemetry-pipeline-from-sensors-to-dashboards/</guid><description>&lt;p>Week 7+8 represents &lt;strong>project completion&lt;/strong> at the infrastructure level. This isn&amp;rsquo;t about adding one more feature - it&amp;rsquo;s about building the &lt;strong>complete path from sensor to insight&lt;/strong>.&lt;/p>
&lt;p>After seven weeks:&lt;/p>
&lt;ul>
&lt;li>Week 1-3: Sensors talk via LoRa ✅&lt;/li>
&lt;li>Week 5: Gateway firmware outputs JSON ✅&lt;/li>
&lt;li>Week 6: Async service processes data ✅&lt;/li>
&lt;li>Week 7: Data goes to MQTT and InfluxDB ✅&lt;/li>
&lt;li>Week 8: &lt;strong>Professional dashboards visualize everything&lt;/strong> ✅&lt;/li>
&lt;/ul>
&lt;p>&lt;strong>This is a complete IoT monitoring system.&lt;/strong> From a temperature sensor on a breadboard to a Grafana dashboard refreshing every 10 seconds. All in Rust. All running on real hardware.&lt;/p></description></item><item><title>Async Rust Gateway From Embedded Firmware to Cloud Infrastructure - wk6</title><link>https://mapfumo.github.io/posts/async-rust-gateway-from-embedded-firmware-to-cloud-infrastructure/</link><pubDate>Sun, 21 Dec 2025 10:34:48 +1000</pubDate><guid>https://mapfumo.github.io/posts/async-rust-gateway-from-embedded-firmware-to-cloud-infrastructure/</guid><description>&lt;p>Week 6 marks a fundamental shift in the project. Up through Week 5, everything stayed within the embedded realm - microcontrollers talking to each other over LoRa. Data lived in OLED displays and defmt logs that disappeared when you closed the terminal.&lt;/p>
&lt;p>&lt;strong>Week 6 changes that.&lt;/strong> It&amp;rsquo;s the bridge between embedded and cloud, between constrained systems and abundant infrastructure, between &lt;code>no_std&lt;/code> and &lt;code>std&lt;/code>.&lt;/p>
&lt;p>This is the week I learned &lt;strong>async Rust isn&amp;rsquo;t just about performance - it&amp;rsquo;s about building systems that compose.&lt;/strong>&lt;/p></description></item><item><title>Gateway Firmware - From Wireless to Desktop, Wk5</title><link>https://mapfumo.github.io/posts/gateway-firmware-from-wireless-to-desktop-wk5/</link><pubDate>Sat, 13 Dec 2025 09:42:11 +1000</pubDate><guid>https://mapfumo.github.io/posts/gateway-firmware-from-wireless-to-desktop-wk5/</guid><description>&lt;p>Week 5 was supposed to be straightforward: add USB-CDC to Node 2, stream JSON telemetry to the desktop. Simple, right?&lt;/p>
&lt;p>&lt;strong>Spoiler&lt;/strong>: The &amp;ldquo;simple&amp;rdquo; solution was blocked by hardware. Then the &amp;ldquo;good&amp;rdquo; solution was blocked by firmware. The &lt;strong>working&lt;/strong> solution came from adapting to constraints instead of fighting them.&lt;/p>
&lt;p>This is the story of how Week 5 became a lesson in &lt;strong>engineering pragmatism&lt;/strong> - and why the best solution isn&amp;rsquo;t always the most elegant one.&lt;/p></description></item><item><title>Binary Protocols and Reliable LoRa Communication</title><link>https://mapfumo.github.io/posts/binary-protocols-and-reliable-lora-communication/</link><pubDate>Fri, 12 Dec 2025 20:14:18 +1000</pubDate><guid>https://mapfumo.github.io/posts/binary-protocols-and-reliable-lora-communication/</guid><description>&lt;p>The first two weeks of this project focused on getting data moving: sensors reading correctly, LoRa modules talking, and messages arriving at the other end. That phase was intentionally simple and text-based. It worked, but it was never meant to last.&lt;/p>
&lt;p>This week was about moving closer to how real embedded systems behave in the field: binary data, explicit integrity checks, and predictable delivery behavior.&lt;/p>
&lt;p>Human-readable messages are convenient for debugging, but they waste bandwidth and hide failure modes. Radios don&amp;rsquo;t care about readability — they care about airtime, reliability, and determinism. This week&amp;rsquo;s work was about aligning the system with those realities.&lt;/p></description></item><item><title>LoRa Sensor Fusion: When "Simple" Becomes Reliable - Wk2</title><link>https://mapfumo.github.io/posts/lora-sensor-fusion-when-simple-becomes-reliable/</link><pubDate>Fri, 05 Dec 2025 17:53:41 +1000</pubDate><guid>https://mapfumo.github.io/posts/lora-sensor-fusion-when-simple-becomes-reliable/</guid><description>&lt;p>Building a reliable embedded system involves far more than getting code to compile. It&amp;rsquo;s a process of learning where hardware limits, timing guarantees, and data representation quietly shape everything above them.&lt;/p>
&lt;p>Week 2 of the Plan focused on making those constraints explicit.&lt;/p>
&lt;p>The result is a dual-node LoRa sensor fusion system built on the STM32F446RE using Rust and RTIC 1.1 — not as a showcase, but as a foundation.&lt;/p>
&lt;hr>
&lt;h2 id="table-of-contents">Table of Contents&lt;/h2>
&lt;ol>
&lt;li>&lt;a href="#the-objective">The Objective&lt;/a>&lt;/li>
&lt;li>&lt;a href="#system-overview">System Overview&lt;/a>&lt;/li>
&lt;li>&lt;a href="#five-critical-lessons">Five Critical Lessons&lt;/a>
&lt;ul>
&lt;li>&lt;a href="#lesson-1-the-51-byte-myth-and-a-self-inflicted-limit">Lesson 1: The 51-Byte Myth&lt;/a>&lt;/li>
&lt;li>&lt;a href="#lesson-2-rtic-timing-when-helpful-code-becomes-harmful">Lesson 2: UART Timing&lt;/a>&lt;/li>
&lt;li>&lt;a href="#lesson-3-sensor-fusion-by-selection-not-averaging">Lesson 3: Sensor Fusion&lt;/a>&lt;/li>
&lt;li>&lt;a href="#lesson-4-units-displays-and-small-lies-that-matter">Lesson 4: Data Representation&lt;/a>&lt;/li>
&lt;li>&lt;a href="#lesson-5-shared-hardware-forces-honest-design">Lesson 5: Shared Hardware&lt;/a>&lt;/li>
&lt;/ul>
&lt;/li>
&lt;li>&lt;a href="#results-at-the-end-of-week-2">Results&lt;/a>&lt;/li>
&lt;li>&lt;a href="#why-this-matters-in-the-plan">Why This Matters&lt;/a>&lt;/li>
&lt;li>&lt;a href="#next-steps-week-3-preview">Next Steps&lt;/a>&lt;/li>
&lt;/ol>
&lt;hr>
&lt;h2 id="the-objective">The Objective&lt;/h2>
&lt;p>The goal for this week was deliberately narrow:&lt;/p></description></item><item><title>Building Deterministic IIoT Systems With Embedded Rust and RTIC</title><link>https://mapfumo.github.io/posts/building-deterministic-iiot-systems-with-embedded-rust-and-rtic/</link><pubDate>Tue, 02 Dec 2025 17:53:41 +1000</pubDate><guid>https://mapfumo.github.io/posts/building-deterministic-iiot-systems-with-embedded-rust-and-rtic/</guid><description>&lt;p>In the world of Industrial IoT (IIoT), reliability is everything. Sensors must read accurately, actuators must respond predictably, and communication must flow without surprises. On the embedded side, this means precise control of hardware resources, minimal overhead, and code that behaves deterministically. Enter Embedded Rust and RTIC—a pairing that gives engineers both safety and performance without compromise.&lt;/p>
&lt;hr>
&lt;h2 id="why-embedded-rust">Why Embedded Rust?&lt;/h2>
&lt;p>Rust’s focus on memory safety, zero-cost abstractions, and strict compile-time checks makes it ideal for embedded systems. Unlike C, Rust prevents &lt;strong>entire classes of bugs&lt;/strong> like null pointer dereferences or buffer overflows. When your MCU has just a few kilobytes of RAM, these protections are not optional—they’re essential.&lt;/p></description></item><item><title>Building an IIoT Sensor Node With Embedded Rust and Stm32</title><link>https://mapfumo.github.io/posts/building-an-iiot-sensor-node-with-embedded-rust-and-stm32/</link><pubDate>Tue, 18 Nov 2025 17:23:13 +1000</pubDate><guid>https://mapfumo.github.io/posts/building-an-iiot-sensor-node-with-embedded-rust-and-stm32/</guid><description>&lt;h2 id="1-introduction">1. Introduction&lt;/h2>
&lt;p>I come from a networking background. For years, my world revolved around packets, routing tables, latency, and uptime. Over time, it became clear that the boundary between IT and OT (Operational Technology) was becoming less rigid as industrial systems moved onto standard IP networks. Networks were no longer just carrying business traffic — they were increasingly responsible for transporting sensor data, telemetry, and control signals from the physical world. That realization pushed me toward Industrial IoT (IIoT) and, inevitably, embedded systems.&lt;/p></description></item><item><title>Design Science: A Disciplined Approach to Engineering Embedded Systems</title><link>https://mapfumo.github.io/posts/design-science-a-disciplined-approach-to-software-development/</link><pubDate>Mon, 20 Oct 2025 14:20:17 +1000</pubDate><guid>https://mapfumo.github.io/posts/design-science-a-disciplined-approach-to-software-development/</guid><description>&lt;p>&lt;strong>Design Science&lt;/strong> is a research methodology and problem-solving framework that focuses on the &lt;strong>creation and evaluation of artifacts&lt;/strong> designed to solve real-world problems. Rather than studying systems passively, Design Science emphasizes &lt;strong>active construction, experimentation, and rigorous evaluation&lt;/strong>. Its principles have traditionally been applied in information systems and software development, but they are equally relevant to modern embedded and IIoT engineering.&lt;/p>
&lt;p>In complex engineering domains — including &lt;strong>embedded systems, IoT, and distributed sensor networks&lt;/strong> — the challenge is not just writing code or assembling hardware. It’s about systematically creating artifacts that &lt;strong>solve practical problems effectively, reliably, and efficiently&lt;/strong>.&lt;/p></description></item><item><title>Machine Learning web application using Python, Scikit-Learn, Flask</title><link>https://mapfumo.github.io/posts/machine-learning-flask/</link><pubDate>Thu, 27 Apr 2023 12:02:35 +1000</pubDate><guid>https://mapfumo.github.io/posts/machine-learning-flask/</guid><description>&lt;p>The scikit-learn Iris data-set consists of 3 (Setosa, Versicolour, and Virginica) species (50 samples per species, for a total of 150 samples) of the iris flower. Each sample has four measurements: sepal length, sepal width, petal length, petal width. Given these measurements a machine learning model can predict the iris specie with a high degree of accuracy. Here I demonstrate a machine learning web application using &lt;em>Python&lt;/em>, &lt;em>Scikit-Learn&lt;/em> machine learning library and &lt;em>Flask&lt;/em> web framework. The application is then deployed on an Amazon EC2 instance. The source is on &lt;strong>&lt;a href="https://github.com/mapfumo/iris-flask">GitHub&lt;/a>&lt;/strong>.&lt;/p></description></item><item><title>Programming with Google Go Specialization - A Brief Course Review</title><link>https://mapfumo.github.io/posts/go_specialisation/</link><pubDate>Sat, 22 Apr 2023 17:33:35 +1000</pubDate><guid>https://mapfumo.github.io/posts/go_specialisation/</guid><description>&lt;p>Go or &lt;a href="golang.org">GoLang&lt;/a> is an open source statically typed language that was created at Google by Rob Pike, Robert Griesemer, and Ken Thompson. It first appeared in Nov 2009 and has been rapidly gaining in popularity. Some of the language&amp;rsquo;s highlights include clean and highly accessible syntax, garbage collection, amazing native concurrency, fast compilation speed, excellent tooling, builtin documentation, good cross-platform support, ORM (Object-relational mapping ) library called GORM and excellent support for micro-services.&lt;/p></description></item><item><title>Deep Learning Specialisation - A Brief Course Review</title><link>https://mapfumo.github.io/posts/deep_learning_specialisation/</link><pubDate>Fri, 21 Apr 2023 18:00:58 +1000</pubDate><guid>https://mapfumo.github.io/posts/deep_learning_specialisation/</guid><description>&lt;p>I have just completed &lt;a href="https://www.coursera.org/instructor/andrewng">Andrew Ng&amp;rsquo;s&lt;/a> &lt;a href="https://www.coursera.org/specializations/deep-learning">Deep Learning Specialisation&lt;/a> course by &lt;a href="https://www.deeplearning.ai/">deeplearning.ai&lt;/a> available through &lt;a href="http://bit.ly/2WjYrPB">Coursera&lt;/a>. This is my summary and opinion of the course offering. The specialisation consists of 5 courses and it is suggested that they be completed in 3 months by devoting 11 hours per week. It really depends on your previous knowledge, experience and how quickly you can grasp the concepts. When stuck with the assignments and concepts I found the forum to be very helpful. I found the assignments to reasonably difficult. The only thing I didn&amp;rsquo;t like is that by forcing you to complete the given code (complete missing blanks) you are a bit constrained. For example it would be nice to state the function signature and leave it to the student to implement it in their own way. The good thing is that one can always make such suggestions through the forums. The courses don&amp;rsquo;t have to be completed in any particular order but I found it more helpful to follow the suggested order.&lt;/p></description></item><item><title>Iec 61850</title><link>https://mapfumo.github.io/posts/iec-61850/</link><pubDate>Fri, 22 Apr 2022 18:30:41 +1000</pubDate><guid>https://mapfumo.github.io/posts/iec-61850/</guid><description>&lt;p>The IEC 61850 is at the heart of data communications in the smart grid. The IEC (International Electrotechnical Commission) 61850 standard outlines a framework for communication between several single devices in the power system. The standard was designed to separate the data model from method of communication, address the importance of a structured approach to the design of substation automation systems, utilise existing technologies like Ethernet and TCP/IP, simplify system configuration, device measurement sharing and to enable vendor independence. Although the scope of the IEC 61850 standard was originally substation focussed applications are already operating on wide area substation-to-substation communication using various components of IEC 61850.&lt;/p></description></item><item><title>About</title><link>https://mapfumo.github.io/about/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://mapfumo.github.io/about/</guid><description>Aut inveniam viam aut faciam - &amp;#34;I shall either find a way or make one&amp;#34;</description></item><item><title>Portfolio</title><link>https://mapfumo.github.io/portfolio/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://mapfumo.github.io/portfolio/</guid><description>portfolio</description></item><item><title>Tutorials</title><link>https://mapfumo.github.io/tutorials/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://mapfumo.github.io/tutorials/</guid><description>portfolio</description></item></channel></rss>