#3 What caught our engineers’ attention?
Videos, articles, posts and webinars worth sharing, selected by the LMT IoT team.
Welcome to edition #3 of Inside IoT!
As the days get shorter here in the Northern Hemisphere, a little extra inspiration can’t hurt. This time, we asked our colleagues at LMT IoT to share specific pieces of content they have found interesting or useful.
Perhaps you’ll find an idea for your next project, a clearer explanation of something familiar, or a question you hadn’t thought to ask.
Happy reading!
—
A piece of content can catch your attention for a very practical reason: it shows you how to do something you already want to try. It can also make you pause over something you thought you understood.
We asked our team to share examples of both. Here are a few of their selections, in no particular order.
#1 A new way to investigate existing hardware
Pēteris Dūka, Senior Testing Engineer at LMT IoT, shared AI CAN Bus Reverse Engineering Claude Code (https://www.youtube.com/watch?v=jQDqWuL5-nQ), a demonstration from CSS Electronics.
CAN bus allows electronic systems to exchange messages. Understanding those messages can involve working out which parts of the raw data represent particular measurements.
In the video, Martin Falch uses a CAN bus interface, Python tools and Claude Code to help decode signals such as vehicle speed and engine RPM. The workflow compares raw data with known reference values, then checks whether the decoded results agree with them.
Pēteris has a practical reason for exploring this approach.
“I follow this to reverse-engineer some of the hardware I have at home,” he writes.
His starting point is an existing piece of electronics and the wish to understand it better. The video introduces a method he could try as part of that investigation. (He is currently waiting on a delivery for some extra components to test what he’s put together.)
#2 Making electrical behaviour visible
Reinis Valters Kobitjevs, Application Engineer at LMT IoT, shared two videos covering radio-frequency concepts and PCB design.
The first asks a direct question: What does “impedance matching” actually look like? (https://www.youtube.com/watch?v=RkAF3X6cJa4)
It explores the topic through electrical waves, resistive dividers and models of how a transmission line behaves. For a concept often introduced through equations, seeing the behaviour explained visually offers another way to understand it.
His second recommendation, Rick Hartley’s How to Achieve Proper Grounding (https://www.youtube.com/watch?v=ySuUZEjARPY), takes a deeper look at PCB behaviour. It examines signal and return paths, and why the physical arrangement of a board matters.
Both selections connect with Reinis’s interests in hardware and telecommunications. They also share a useful theme: the drawing of a circuit is only part of the story. The physical system needs to make sense too.
#3 The engineering behind “PCB art”
Rūdolfs Arvīds Kalniņš, Firmware Engineer at LMT IoT, included a LinkedIn post by Tomasz Chumięcki about an RF board’s layout (https://www.linkedin.com/posts/chumiecki_pcb-art-design-activity-7501927175810564096-L4H5).
The post describes a board whose copper shapes and sections look almost like abstract art. It then explains why that appearance has an engineering purpose.
In an RF design, geometry, spacing and copper areas can influence how the circuit behaves. Looking closely at the layout becomes a way to explore the decisions behind it.
It is a short piece with a useful invitation: when a design looks unusual, ask what those shapes are doing.
#4 When the processor gets the answer wrong
Another of Rūdolfs’s selections was Laurie Kirk’s post about silent hardware errors (https://www.linkedin.com/posts/laurie-kirk_something-that-keeps-me-up-at-night-is-the-activity-7477391317644509184-PQoX).
The post recounts a debugging case at Facebook in which an application-level problem was eventually traced to a particular CPU core producing incorrect calculations. Kirk also points readers to the research paper Silent Data Corruptions at Scale.
The unsettling part is that a hardware error can appear much further up the system, as a problem with data or software, without the processor reporting an error.
For anyone debugging a system, the case raises a useful question: which parts of the system are we assuming work correctly?
Sometimes, finding the cause means examining an assumption beneath the layer where the problem first appeared.
#6 From a sensor reading to a working system
Among the webinar topics Dāvis Barkāns highlighted was From IoT to Connected Intelligence (https://www.digikey.com/en/blog/webinar-from-iot-to-connected-intelligence).
The session explores a kit-based approach to developing edge systems: capturing sensor data, building live dashboards, enabling condition monitoring and bringing processing closer to the device.
Dāvis’s interests include IoT, hardware and firmware. This topic brings those elements together around a familiar development challenge: turning individual components and data into a working application.
For someone exploring a connected product, the useful part is seeing how the pieces fit together. A sensor reading becomes more valuable when the system can interpret it and support a useful action.
Something worth passing on
These selections cover different interests, but each offers something concrete to explore: a method to try, a physical effect to understand, or an assumption to examine.
You do not need to work on the same problem to find something useful in the explanation. A detail from someone else’s design or debugging process might give you a better question for your own.
In our next edition, we’ll look at the people and sources our team regularly returns to.
What have you watched or read recently that made you think differently? Share the link in the comments. We’re always interested in a useful recommendation.