The Heart of a Decentralized Machine Network: Part II

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.

In Part I of this article here, I discuss our initial design goals, selecting the right peripheral components, and keeping the SDR in mind along the way.

In Part II, I discuss non-traditional aspects of our design along with principles we applied to complete the first working prototype in a relatively short timeframe.

FPGA vs. Embedded Processor

The traditional technique used to handle computing requirements for an SDR (software-defined radio) is an FPGA (field-programmable gate array). FPGAs work well with tight timing requirements, and offer extensive flexibility to reconfigure hardware gates without a board re-spin. However, FPGAs are typically expensive and after vigorous debates, we chose a non-traditional path of using an embedded processor for an SDR solution. We chose this path for a number of reasons, but most importantly we could keep costs low while still providing the necessary computing power to handle the data throughput requirements.

This decision was not trivial and we were not aware of any other vendor who had chosen to pair an embedded processor with an SDR, which is why we spent a significant amount of time considering the downstream impact of our choice.

Originally we chose a lower grade embedded processor, but after experimenting with the development kit we quickly discovered it lacked sufficient computing power. To ensure we have enough processing power on the board, we chose to upgrade to a dual-core ARM15 that also included two digital signal processors (DSP), and graphics acceleration processors. The DSPs and graphics accelerators help offload computation effort from the two main processors.

Avoid building an expensive brick

The approach we chose as a company to build our board is generally not recommended. Our design included over a dozen power switching regulators, high speed multi-core processors and DDR memory, over five radios, and several other mixed-signal peripherals. Typically when you make products this complex you’d never throw everything onto a custom prototype PCB in the beginning. More complexity equals a higher likelihood something will go wrong, especially with the first prototype where something almost always goes wrong, and worst case scenario you end up with a really expensive brick. Even troubleshooting can become a nightmare in this scenario.

I’ve witnessed teams that have designed and built complex prototype boards such as these, and problems or mistakes can be located deep inside the board under copper trace layers you can’t access let alone fix. At that point you’ve built an expensive brick, lost a lot of development time, and often unable to learn anything from the failed prototype. When that happens you almost have to repeat the process, and just hope the next prototype has at least minimal function so you can finally start learning from it.

To avoid this headache, the usual approach is to purchase development kits for all components of the system (e.g., cpu, radio, gps, cellular, wifi, ethernet, etc.), and flywire them together to form the first prototype concept. This exercise greatly reduces risk. It’s also useful for becoming more familiar with each component of the system, how components behave together, and determining if a specific component should be used in the final system or substituted with something more suitable.

Typically after you’ve confirmed everything is working only then do you proceed to build out your board.

An accelerated Helium hybrid flywire approach

After we had conceptualized a top level design of the system, we chose to take an accelerated flywire approach by focusing on the highest risk components, the CPU and the SDR. This allowed us to flywire the SDR’s 12-bit digital receive lines with the CPU PRU interface and confirm that we could at least achieve the required sampling speeds. We encountered several challenges as the off-the-shelf development kit for the CPU had very limited I/O availability so we could not fully test the SDR’s 12-bit digital transmitter simultaneously with the 12-bit receiver, but based on CPU resource usage while receiving we felt comfortable committing to the selected processor.

The ideal next step would have been to flywire everything else: bluetooth, wifi, cell, gps, etc, but since most I/O on the development board was already dedicated to something else or not exposed at all, we had to take a leap of faith, and jumped right into designing the full prototype PCB.

Preliminary PCB Floor-plan

Aside from schematics and circuit design, an equally important step is to develop a preliminary floor-plan of the PCB. This is done to not only estimate the required size of the system, but also optimize the placement of power, digital, analog, and radio components. This initial forethought into placement is critical in maintaining signal integrity, reducing noise, and spreading thermal heat. Once complete, actual layout can begin.

Early SDR and RF frontend PCB layout

Since we knew we had many high speed signals, we opted for a 12-layer board that included four dedicated ground planes. Proper grounding is equally as important as the initial component placement. The high number of ground planes help maintain signal integrity, lower signal noise, reduce unintended wireless emissions, and spread thermal heat more evenly. Since we omitted the ideal step of flywiring everything first, attention to detail during layout was critical to reduce the chances that common mistakes would lead to an expensive and non-working PCB prototype.

CPU and high-speed DDR3 interface

Here’s an example of how things could go wrong: The CPU and DDR interface have a lot of memory lines that need to be properly powered, length matched, and impedance controlled. It only takes one memory line miscalculated or placed too close to another signal, and memory errors would have likely occurred.

Dozens of similar mistakes could have easily been made. These mistakes are often very difficult to troubleshoot, and not easily resolved once the design goes to the factory to be manufactured.

After the physical PCB was manufactured, we were ready for bring-up. This can be a particularly nerve-racking moment as any number of unnoticed design flaws could be present. Fortunately, after carefully powering our board with a current-limited supply, all of the dozen power rails on our system looked clean and steady. After power we tried to bring up the clocks, but encountered problems. Fortunately, working along-side the firmware team we identified minor issues with a part footprint, and resolved it with minor rework to logic buffer components.

Ultimately, our hybrid flywire approach paid off and it was a monumental day when the board booted up for the first time. One we achieved this milestone we knew that further bring-up could truly begin, and our talented team of firmware and embedded engineers could test all of the many remaining peripherals. We were fortunate to reach this stage and not have an expensive brick, allowing us the opportunity to incorporate everything we learned into the next board revision.