Are you implementing an IoT system that requires you to identify many connected devices? This post reviews different types of IDs and provides some technical details to help you decide if any of these are appropriate for your application.
Are you considering implementing a web UI in your Zephyr RTOS application and perplexed by the endless number of web technologies available today? This article traces my journey through trying several options and presents some of the tradeoffs.
Modern microcontrollers (MCUs) have many connectivity options (Ethernet, WiFi, Bluetooth, Cellular, etc.), and when coupled with the Zephyr OS, implementing a web application on these devices often makes sense. Once you start doing this, you soon realize that this is not Ruby-on-Rails. Rather, Zephyr is still a very constrained environment (see my article on the differences between MPUs and MCUs). While we can still leverage modern web technologies, we need to be selective because of the constraints of MCU systems. An example of a web UI in the Zephyr SimpleIoT project is shown below:
Have you struggled with adapting your IoT system to new applications and requirements? Is handling configuration updates at both the cloud and edge a challenge? Is synchronizing required data between cloud and edge instances a challenge? This article describes a simple way to model data that eliminates many of these difficulties.
We can scale an IoT system both horizontally (deploy more units) and vertically (add features and address new applications). While the ideas presented in this essay are focused on vertical scale, any simplification will likely help with horizontal scale as well.
Previously, we explored data-centric architectures in IoT systems. This post expands on this by describing how to represent data using Nodes and Points in a way that drastically simplifies IoT data storage, exchange, and synchronization. This is in contrast to encodings and mechanisms used in traditional web and cloud systems.
(while this article contains many general ideas, it is written from the perspective of product development.)
If you don’t continually improve, you soon lose the ability to do so …
This thought came after an associate described a company that is struggling to manufacture one of their products:
They have been making a product since way back in the last century. EOL (end-of-life) is catching up with them. The circuit is really hairy analog stuff with ridiculously high precision. Pots everywhere to get it dialed in. But their voltage regulator is drifting in value significantly, whereas the old parts are rock steady.
How do we get into situations like this, and how can they be avoided?
When you hear hoofbeats, think of horses, not zebras. — Dr. Theodore Woodward
“Zebra” is the American medical slang for arriving at a surprising, often exotic, medical diagnosis when a more commonplace explanation is more likely.1 What does this have to do with product development? Like the medical profession, we often diagnose problems — we call it debugging. Below are three recent cases where I would have been helped by applying this approach a little more rigorously.