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:
Read More »How to implement Zephyr web applicationsHave 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.
Read More »Struggling to scale your IoT system? Simplify your data.
(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?
Read More »The Ability to ImproveThere is a popular quote in medical circles:
When you hear hoofbeats, think of horses, not zebras. — Dr. Theodore Woodward
I recently posted several debugging experiences where it was beneficial to examine simple scenarios before complex ones. Below are a few more …
Read More »Think Horses, not Zebras (Part 2)(this topic is also discussed in a podcast episode)
One of the paradoxes in product development is Open Source. How can you personally or as a company benefit from participating in Open Source projects? Why should you share your great ideas and code? How can you build a business or a career by giving things away? How can an open-source project be a reliable supplier without contractual guarantees? Most successful technology companies today participate in open-source projects. Why do they do this?
Open source is difficult to fully understand and much has been said about it. There are many approaches to licensing and funding. Many question the equity and sustainability. Many get bogged down in ethical, moral, and political arguments. There are messy problems that don’t seem to have good answers. But we need to go deeper and examine the core issues of why companies are turning to open-source.
Read More »Why Open Source for Product DevelopmentThere is a popular quote in medical circles:
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.
Read More »Think Horses, not ZebrasSee also a podcast episode where we discuss this topic.
Modern systems require the integration of technology, often from many sources. This can come in the form of processors, integrated circuits, operating systems, open-source software components, databases, messaging systems, cloud infrastructure, programming languages, build systems, frameworks, etc. All technology follows a trajectory — an example is shown below. The timeline may be short or long. Your usability threshold may be low or high, sloped right or left, etc. But the fact remains that most technology will eventually be replaced by something newer. We can debate whether or not newer is better, but the fact remains that time marches on.
As developers, we have many options for programming languages. On one hand, it is great to have choices. On the other hand, it can be a little overwhelming. Many times in life, we need to make decisions before we have the experience to know the best answer. There are many opinions as to what is best, and this article is just another one. There is no one-size-fits-all — a lot depends on your team and the task. In this article, we will examine the challenges we face in developing industrial IoT (IIoT) systems, review desirable attributes in a programming language, and discuss how Go meets these needs.
Read More »Go for IIoT SystemsWith the advent of the browser, cloud, embedded Linux systems, and networked microcontrollers, distributed systems are everywhere. There are many models for communication in distributed systems — we will look at the tradeoffs between three of them. There are many perspectives to consider — initial implementation, client libraries, maintenance, adding features now and in the future, client compute and storage requirements, network bandwidth, data structure, etc. This article will discuss a number of these concerns and present several options.
Read More »Layered, Event, and Data-Centric Architectures in Distributed IoT Systems