Why build hardware at a software company?

Golioth is a Cloud company that operates a Software-as-a-Service (SaaS) model for its customers and does not sell any hardware…so why do we build hardware?

Well, let’s get the obvious one out of the way: As a hardware engineer, it is just something I do. Rightly or wrongly for any particular situation, I just love building hardware. It is the hammer that I have applied to many, many technical nails that I have encountered over the years.

As it so happens, this also is a benefit to a software company that serves the IoT market. Putting together solutions that mirrors our customers’ challenges reveals gaps in explanations or services that we offer. It also allows us to empathize with the difficulties of bringing a connected hardware product to market in large volumes. Let’s look at how our internal hardware has evolved and the reasons why we build actual hardware.

It starts with a development board

All of our getting started guides are built on top of development kits / boards from our hardware partners.

This is for good reason: development boards are broadly available hardware that is reliably manufactured, available for sale at our partner distributors, and have upstream Zephyr support for those boards. It is the best option for getting a user started with a known setup. Even then, things can be difficult! Troubleshooting firmware is easier when the Golioth team has the same board as the one that is sitting on a customer’s bench.

All Golioth platform capabilities are showcased in the “examples” section of our SDK. This serves two purposes:

1. Having a standard set of tests that the Golioth firmware team regularly tests (see our posts on hardware-in-the-loop for more details)
2. Providing a standalone example of that feature working without any distraction

For these purposes, development boards work great. Users have a proven, tested set of samples that can run on supported hardware like our Continuously-Verified Boards (CVB).

Doing more to show more

As we enter another trade show season, capturing engineers’ attention is on my mind. Nestled in a booth among other compelling demos, it can be hard to stand out. There are many things to see at a trade show, and IoT demos don’t benefit from things like cameras, large screens, or the impressive scale of something like an industrial robot. And as tough as standing out at a trade show can be, it might be even more difficult on the internet. How do we showcase complex and abstract topics to a crowd that will click away after a split second?

If you want to build a compelling demo (as we often want to do), you need to add other elements to development boards. If I am trying to show the layers and layers of cloud, firmware, and hardware all to showcase how I blink an LED from the internet…that demo falls flat. Don’t get me wrong, I have done this and sometimes all we have is an LED. If you do happen to snag the attention of an engineer who has struggled with the stacks of software required to build an IoT system, the LED will suffice. But they are the exception not the rule.

Users eventually want to see all capabilities of Golioth in a coherent demo. This is the origin of our Reference Design Template and more generally our Reference Designs. In order to showcase each of those capabilities in a compelling way, we also wanted to increase the variety of inputs and outputs.

The “Follow Along Hardware” version of the Reference Designs took an abstracted interface like the Arduino (Uno) Shield interface on something like the nRF9160-DK and added a breakout to accept MikroBus Click Headers and extend the capabilities of the development board. The flexible nature of Zephyr allowed us to create overlay files and interact with a variety of sensors (inputs) and output devices.

But what about when we want to do even more than that? How do we better emulate the setup of our customers?

Approximating production grade hardware

In 2022, we started building some of these designs into full featured Reference Designs that look like customer use cases. Application-specific demos are also concrete; recording a video or talking to a potential customer at a trade shows is easier when a use case is front and center. For example, “Would you like to see this Air Quality Monitor sending back complex data over cellular to Golioth and the wider internet?”

Around this same time, we started designing and building pluggable hardware of our own. We wanted the ability to swap out sensors, but in a more realistic form factor. There are still some tradeoffs in order to make it easy to swap out sensors, namely that we built the form factor to include modular headers like the MikroBus Click header and the Sparkfun QWIIC / Adafruit Stemma 4 pin i2c interface.

This allowed us to use the same sensors that are on the Follow-Along Hardware examples, but in an enclosed form factor.

This still isn’t how our customers operate though. They make truly custom hardware, often only borrowing from the schematic of a reference board they used in earlier stages. The Aludel Elixir migrated us away from soldering external dev boards (like the nRF9160 feather, which we love) to an integrated version where the chips are soldered directly to our custom PCB.

This gave us access to more pins and space, allowed the addition of multiple communication mechanisms onboard (cellular, Wi-Fi, Bluetooth), and a variety of power input capabilities. We also created a PCB front panel called the Ostentus, which took commands over i2c (using the QWIIC / Stemma connectors) and displayed information directly on the device. There are also capactive touch buttons around the screen for user input. This is useful both at trade shows and on the factory floor to give a quick summary of sensor readouts, with more in-depth data available on the Cloud.

The manufacture of those boards was the same process we expect our customers to do. The provisioning process includes the same difficulties as devices rolling off the line. In a best case scenario, they implement zero-touch provisioning using certificates to seamlessly join a Golioth project and start sending data.

Additional challenges arise for custom hardware

Customers have specific needs around form factor, power envelope, and supporting components. The Aludel Elixir was the same.

The next challenges are in the firmware space, bending firmware ecosystems like Zephyr to work with custom hardware and implement new features. A hardware device maker needs pull in the Golioth Firmware SDK, but also tap into the various subsystems of Zephyr and write custom elements like device drivers that conform to Zephyr standards. We did the same on the Elixir, and have continuously published about what we have learned in Zephyr as a result.

When we emulate the production process, we also run into hardware and firmware challenges that many of our customers run into. Things like provisioning devices off the “manufacturing line” (simulated in our case, since we either manufacture ourselves or do very small runs of units) or measuring current consumption of different aspects of the a device that regularly transmits data or optimizing firmware versioning to work with Golioth Over-The-Air firmware updates. Each time we build our own custom hardware, we step into the shoes of our customers building custom hardware. Each time we learn something new about the process of building efficient IoT devices on top of our platform.

Smaller and smaller

We introduced Golioth Connectivity and Bluetooth support back in August of last year. That also surfaced new challenges around the physical constraints of Bluetooth connected devices. While there is no requirement that a Bluetooth device be small, the new capabilities of Pouch and the Golioth Bluetooth Gateway reference implementation means we can build devices that are smaller than others we have created before.

There is also the challenge of creating a diminutive device that still can be eye-catching. That was the thought behind a 104 LED matrix array and two motor drivers attached to a Bluetooth module (the Tikk board, above). We use it to scroll information during updates and have used it as a digital signage application level design.

Once again, we are designing and building custom hardware to emulate the challenges of our users building Bluetooth devices. Whereas before we could create larger, modular designs, we have now reached the point when there are longer any modular interfaces on these boards. In the case of the Tikk, this took the form of a small form factor dev board (ProMicro) and permanently attached a very customized sensor breakout. Basically, this is the limit of our modularity, and it’s not very modular at that. As our customers are optimizing for the lowest power devices that can fit in the smallest spaces, this needs to get even more precise.

Once we have a truly integrated solution (like the Orleon, above), we once again need to focus on other similar challenges that our customers face. Even lower power operation, the ability to load certificates on in production, the ability to lock down interfaces after production ends, and the ability to still troubleshoot devices that have issues in the field. These may feel like universal needs for electronics devices, but they are most prevalent for devices that race towards high volume production.

Dogfooding at each stage of the design

Last month we shared one of our “hack day” projects extending the capabilities of an ePaper display as a meme delivery device…but really this was an exercise in “dogfooding” our own IoT platform. Each time we port an off the shelf piece of hardware like we used for the MePaper we feel the pain points that IoT developers face from the firmware on up. Building custom hardware takes on even more of the process and is an exercise in empathy for our customers and stress testing our systems. We will continue trying out different designs and look forward to building open source solutions that could be the starting point for new products in the IoT market.