Week 5 was supposed to be straightforward: add USB-CDC to Node 2, stream JSON telemetry to the desktop. Simple, right? Spoiler: The “simple” solution was blocked by hardware. Then the “good” solution was blocked by firmware. The working solution came from adapting to constraints instead of fighting them. This is the story of how Week 5 became a lesson in engineering pragmatism - and why the best solution isn’t always the most elegant one. ...
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. This week was about moving closer to how real embedded systems behave in the field: binary data, explicit integrity checks, and predictable delivery behavior. Human-readable messages are convenient for debugging, but they waste bandwidth and hide failure modes. Radios don’t care about readability — they care about airtime, reliability, and determinism. This week’s work was about aligning the system with those realities. ...
Building a reliable embedded system involves far more than getting code to compile. It’s a process of learning where hardware limits, timing guarantees, and data representation quietly shape everything above them. Week 2 of the Plan focused on making those constraints explicit. 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. Table of Contents The Objective System Overview Five Critical Lessons Lesson 1: The 51-Byte Myth Lesson 2: UART Timing Lesson 3: Sensor Fusion Lesson 4: Data Representation Lesson 5: Shared Hardware Results Why This Matters Next Steps The Objective The goal for this week was deliberately narrow: ...