The Heart of a Decentralized Machine Network: Part I

As the director of hardware at Helium I’m responsible for making consumer and industrial IoT hardware from concept to mass production. This includes sourcing and selecting components, electronics design, prototype development, troubleshooting, reworking prototypes, test, and calibration. In addition, it involves maintaining compliance with world-wide standards, and working with distribution and manufacturing partners to fulfill inventory in high volume.

When we started discussing our gateway concept many months ago we had made the decision to utilize blockchain technology in an innovative way to incent and reward a community to participate in building the world’s first decentralized machine network. At the heart of this network is the gateway.

The gateway will ultimately integrate with many other components, and I’m fortunate to work with a team of experts that have deep knowledge in blockchain, advanced mathematics, embedded systems, software, radio technology, and other technical fields.

It’s exciting to work on such a unique project, but it’s also challenging when you’re forging a new path and the risk of something going wrong is very high. Project challenges and risks were largely due to technical complexity combined with ambitious design goals and timelines. Most importantly, what we’re attempting has never been done.

Within this post I will describe some of the considerations in designing the gateway hardware, and will use the terms gateway and printed circuit board (PCB) interchangeably.

Defining initial design goals

To build the physical infrastructure for the decentralized machine network (to learn more about our DMN our CEO wrote about it here), we used the following design goals to guide the project:

Cost

You can accelerate progress and minimize risk by choosing expensive components, but for us to be successful we need to make our products available to as many people as possible, and that means managing costs. To accomplish this requires smart design and squeezing the most value out of every component.

Global usage

If the gateway was intended for a single country we could have accelerated the process and reduced cost. However, our mission spans much larger than a single country and each country has its own unique regulations for wireless spectrums. This largely impacted the radio design, and the selection of a processor needed to support the radio. Which brings us to…

Long range

Our goal is to deliver connectivity to low-powered devices (we call them machines) over many, many miles of range. If we can reward the community to provide low cost, ubiquitous connectivity that allows machines to send data to the internet over long ranges, the number of network users will explode.

Concurrent connections

We envision gateways receiving data from many types of machines and need to design the gateway to not only handle those situations we can’t imagine, but also handle many machines connecting simultaneously.

Native geolocation

This capability is critical to enable use cases that simply aren’t possible or practical using today’s available technology. Th ability to deliver accurate native geolocation capabilities had a huge impact on our design and board layout. After all, in just one nanosecond light travels over a foot, so nanosecond-level timestamping is critical for accurate geolocation.

To build or buy?

After ambitious design goals were determined, and aggressive time frames were defined it would have been ideal to purchase a complete off-the-shelf hardware solution. However, based on everything we were trying to achieve it wasn’t possible to find a complete off-the-shelf solution so we had no other option than to create our own hardware system from the ground up. The big benefits to making our own solution are that we can open-source the whole hardware design, fully customize the entire system, and keep costs lower for higher production volumes.

Selecting key gateway components

Selecting components, and creating a bill of materials

The first step in creating our gateway from the ground up was putting together an initial bill of materials (BOM) with all the necessary components including peripherals (GPS, cellular, wifi, bluetooth) as well as key components (radio chipset, processor, and SDR).

Selecting typical peripheral components such as GPS, ethernet, wifi, bluetooth, and cellular can be done relatively quickly, but for sophisticated components the process is more involved. Finding components that can meet our design goals for the right price by reputable vendors who can supply the required volume can be challenging.

Selecting the right CPU for Software Defined Radio

If the heart of a decentralized machine network is the gateway, the brain of the gateway is the processor, and it must be selected carefully alongside with the radio chipset. It’s very important to balance performance and cost.

Designing with SDR in mind

Selecting the right processor and radio chipset can be challenging for this type of gateway, as they are both tightly intertwined. Before selecting a processor we needed to select a suitable radio chipset, and we first needed to decide what radio capabilities we wanted. Specifically, the amount of data bandwidth needed for the receiver and transmitter, the resolution of the data, and the sampling rate. These answers proved challenging as we wanted to keep our design flexible, yet still low cost. In addition, there were so many options of radio sub-components from which to choose. The ideal case would be a fully integrated solution that was re-configurable, and offered at low cost.

Example of sub-components within a radio chip-set

We compared dozens and dozens of options on the market, each offering different combinations of various LNAs, VGAs, Mixers, PAs, ADCs, DACs, and more. The best radio chipsets contained most all of these blocks in one package and were re-configurable, allowing our design to be more loosely defined. However, while they met our technical needs, most of these fully-integrated solutions tended to be very expensive, and would have been too costly.

The alternative was to individually select each block we needed, and design the entire radio system from the ground up. Although these small blocks could help keep lower costs, they increase the complexity of board design and layout, and introduce more risk that something can go wrong during prototype development. For our design we wanted to reduce these risks, simplify board bring-up, and keep development time as short as possible. In addition, we wanted to keep our design flexible. Fortunately we were able to identify a suitable radio chipset that was not only re-configurable, but cost 25% of a similar chipset.

The SDR radio chipset we used sampled with a resolution of 12 bits, with a maximum rate of 40Mhz. Given that we needed to be able to transmit and receive simultaneously, we could quickly calculate the amount of data throughput required which then helped determine the CPU architecture we would need.

There are off-the-shelf SDR boards on the market that include processing units to parse data and perform needed computations, but these cost several thousand dollars and we discovered there are essentially no commercial SDR available at higher volumes. They also don’t contain all the additional peripherals needed for our gateway.

If we were only launching this gateway in the US market, it would have been substantially easier to find a cheaper radio. But to enable a truly global network, an SDR is not only an elegant solution, but necessary one. With an SDR the gateway is able to operate in any country by changing its frequency and modulation through software to be in compliance of any particular country. In other words, it becomes less about the data standard for a country, and more about the ability to exchange data anywhere. All that is needed is the necessary computing power to interface with the SDR.

For more details about our SDR check out my co-worker Jay’s blog post here.