CloudSDR

The Thing

The Thing is a microcontroller or single board computer with a USB RTL-SDR software defined radio.  It may optionally contain an Adafruit GPS sensor for mobile operation and real-time clock.

For rapid prototyping but also to demonstrate platform diversity, I selected single board computers -- the BeagleBone Black and the Intel Galileo gen 2 development board and loaded Debian Linux on both.

RTL-SDR

These are $20 USB devices originally intended to pickup terrestrial television signals in Asia that can be tuned from about 25MHz to 1700MHz or more with up to 3.2MHz sample range.

A community of radio enthusiasts and tinkerers have created software to interface with these devices as cheap software-defined radios.  One popular tool is rtl_power, which takes samples and runs it through a fast-fourier transform (FFT) to produce a set of power levels.  Here are some visualizations produced by this method from http://kmkeen.com/rtl-power/, where it is described in greater detail.

But you can do a lot more than just sample power levels with the RTL-SDR device.  The raw samples can be transported over the network or you can decode modulations and extract signals.  You can capture a FM radio transmission and decode it into a stereo MP3, annotating it with the digital transmissions like station name and song name.  Or you can listen to RTTY signals, CW morse code, navigate trunked systems, even listen to the hydrogen line in space.

Scaling Issues

The USB devices are cheap and there are scaling problems adding a lot of them to a single computer.  As USB devices, they can be temperamental.  Several can be made to work semi-reliability but even with one, it creates piles of siloed data.  

Geolocation

By knowing where a RTL-SDR is located, one can add a dimension to the sampled radio data.  Analyzing the power levels of signals from different locations can reveal propagation characteristics and usually the origin of the signal.

AWS IoT

A device becomes a Thing by interfacing with the Amazon Web Services Internet of Things service (AWS IoT).  This provides a high-security TLS MQTT and HTTPS channels for communications and a rules framework to manage things.  Any device that can speak these protocols can be a Thing.

Thing Shadow State

Every Thing has a Shadow State.  This is a JSON document with "reported", "desired", and "delta" hashes applicable only to this Thing.  The Thing updates the "reported" hash with its state but an external application anywhere else can update the "desired" hash.  The Thing subscribes to updates with the MQTT protocol and sees this desired state change, can update its configuration and report that it has changed its state.

This allows for decoupled operation.  If you want to know the state of a Thing, you don't have to go out and talk to the thing directly.  There would likely be high latency and it might not even be accessible right now.  But you can always check the Shadow State for the last reported value and the timestamp it was set.

Control Channel For Swarms

One can therefore imagine software to centrally monitor and modify the "desired" state of a large number of distributed Things, and to do so in an elastic way.

This means that AWS IoT and related AWS services can be used as the central nervous system or command and control for a distributed set of autonomous things.  These things can run on different platforms and have different capabilities but all speak the same protocol and can be leveraged to perform acts greater than their individual skill sets.

I find this fairly exciting because of the other integrated services that Amazon offers such as Machine Learning, elastic Lambda functions, Redshift data warehousing and analytics, massive tiered storage capabilities, etc..  I imagine future "Expert Systems" that are distributed cloud applications leveraging these services that manage and herd Things in our environment.  This is a framework for a cybernetic control system.

Shadow State Has Limits

There is an 8KiB limit to Shadow State documents, and AWS IoT may modify the document to add a "delta" hash.  

Using the rtl_power_fftw program, I collected 2.8MHz radio frequency samples from the RTLSDR device and calculated spectral power levels for 280 FFT bins.  I stored the start frequency and the sample rate, then the power levels as an array of values.  The idea was that each reported value was the synthetic state of 10Hz of radio spectrum.  I started triggering errors when I tried to send more than this.

Transferring bulk sensor data for say 100 values in the shadow state document can work but recognize the limits.  JSON is intended to be human-readable and is fairly bulky so you cannot transfer very much information in 8KiB.

Control Channel 

For the RTLSDR device, there are a small number of knobs that can produce a larger amount of data.  We can use the shadow state as a control channel to relay temporary credentials and the Thing can store the bulk data stream into Amazon S3 or Kinesis or any other service imaginable.

AWS IoT Extremely Large Array

A lot of people have these RTL-SDR devices and are inclined to put one to good use.  I propose a model where somebody with an RTL-SDR can plug it into a BeagleBone Black or Intel Edison, or any number of other devices (even a personal computer), and provision it as an AWS IoT thing.  Once provisioned, the Thing is under the control of the Thing Mind, a set of rules governing the state of the participating Things.  

Individually, each RTL-SDR device is fairly limited.  It doesn't even have enough bandwidth to decode a terrestrial digital television signal in the US, has falloff on the edges of the samples, is prone to interference, has tuner drift, and operates over sometimes flaky or busy USB buses.  

But collectively, one may produce synthetic data by averaging or otherwise merging the output of many of these devices.  Several devices can be made to span the digital tv signals and we can digitally combine and postprocess enough to decode them.

Using the Amazon cloud, one may then listen to recorded signals that were transmitted in the past, or get access to signals that are outside the listening range or beyond the capabilities of one's particular hardware.  The information from radio signals is not just auditory in nature, there are digital data streams, video, transponder information providing the location of aircraft, marine vessels, and bearded ham radio enthusiasts.  

So how should this work?

• Thing Setup and Provisioning
• Thing Location Visualization (Google Maps/Earth Mashup)

Thing Setup and Provisioning

• Insert RTL-USB device into system and attach desired antenna.
• Attach Adafruit GPS sensor, if available.  Otherwise, lookup latitude and longitude for fixed Thing and write it down.
• Load Debian Linux onto system
• Connect it to a network in whatever way you can (wired, wireless, usb)
• Install the CloudSDR Debian package and dependencies
• Provision the Thing - talk to AWS API Gateway to register thing and get credentials.  
• Test the service.
• Start the service and leave it alone.