Software-defined radio

Given the requirements, we researched available options and decided on a software-defined radio (SDR) despite the many development challenges we knew we would encounter.

With an SDR a single hardware radio digitizes radio frequency (RF) spectrum into samples. Application-specific software can then operate on those samples. Any physical process can be described with math, even the analog portions of a hardware radio. We can use this fact to implement those processes on a general-purpose processor. SDR frameworks typically model individual hardware radio components as “blocks” of code and allow you to connect multiple blocks to form a flowgraph. For example, you can have a channelizer, which is just a block that takes in an initial stream of radio frequency data and outputs several channels of smaller bandwidth RF data. Another block could be a demodulator or something that recognizes the packet format we’re using.

Concurrent connections

It’s handling concurrent connection scenarios that an SDR excels. Without an SDR, trying to manage concurrent connections requires multiple hardware radios, however, this restricts the number of channels available to receive signals. Any increase in the number of channels means more hardware radios required, which would necessitate a larger more complex design, increase the cost, require more power, and still would not result in supporting more concurrent sessions than a well implemented SDR.

Concurrent signals from different machines can be received and seperated into sub-channels by the SDR.

With an SDR, instead of requiring multiple hardware radios to listen to a certain amount of spectrum, you only need one and the software “chops” the spectrum into several sub-channels. Each channel has a virtual software demodulator allowing multiple channels to receive signals simultaneously. Through algorithms, the SDR solves signal congestion problems and enables a higher number of concurrent connections.

Over just a few megahertz (MHz) of spectrum, an SDR allows a Helium gateway to listen to dozens or hundreds of channels in parallel.

Native geolocation capabilities

Geolocation capabilities can be achieved through different approaches, but each comes with tradeoffs including:

using radio direction finding (RDF) to determine where the signal came from, but this requires at least three antennas on a gateway to get a direction fix and would require gateways to be mounded precisely vertical and with a precise alignment relative to the north pole.

adding GPS to each end device seems straightforward. However, GPS modules are expensive, are power-hogs, and on top of that location can be spoofed.

Another geolocation approach using time difference of arrival (TDOA) requires two things: the time when a signal is received and location of the receiver. TDOA requires an extremely accurate timestamp because every nanosecond of variance results in approximately three feet of location uncertainty. With inexpensive radios, you’d be fortunate to get timestamps within a microsecond, leading to at least 3000 feet of location uncertainty.

One way to think of TDOA is the reverse of GPS: rather than multiple satellites transmitting to a single machine, one machine transmits to multiple “satellites” (or gateways this scenario).

With accurate timestamps paired with gateway location, the system can provide native geolocation capabilities with a high degree of accuracy, and is a critical reason why we chose SDR.

Low cost, and energy efficient

Based on our design goals of affordability and energy efficiency, we chose a dual-core TI system on a chip (SoC) to power the gateway. This SoC also has four programmable realtime units (PRU). We leverage these PRUs to marshall high-speed sample data in and out of the RF front-end chip, a role typically performed by an FPGA on most SDR platforms. Eschewing an FPGA results in a dramatic impact on both price and power consumption.

As far as we know, we’re the only company to develop an SDR using PRUs. However, it’s not without tradeoffs. Although we avoid having to maintain HDL code for an FPGA, it does mean that we’ve had to write PRU-specific assembly code and painstakingly count every single instruction to ensure deterministic timing while avoiding dropped samples.

However, the significant cost savings and efficiency gains will benefit our customers and we believe will increase the likelihood of adoption.