From eLinux.org
Jump to: navigation, search

Testbed for RF Geolocation by Nathan Catt, Andrew Belk, Jaci Dalton, and Joel Stiffler


The goal of this project, Testbed Development for Geolocation of RF Emitters, was to improve upon the testbed used in conjunction with the Air Force Research Laboratory (AFRL) geolocation algorithm. The military has many applications where locating radio signals are important. Locating downed pilots or pinpointing communication signals of the enemy are just a couple of examples. Rose-Hulman Institute of Technology is currently working on compressive sensing algorithms to help locate the source of radio frequency (RF) signals. These algorithms will be implemented on a ground based mobile platform as part of this project development. The mobile platform will be controlled by a user. A system must first be designed that includes reconfigurable sensors with at least one transmitter and two receivers. The mobile testbeds will need to demonstrate the ability to receive signals and locate the transmitter. A final demonstration will be completed at the AFRL. This testbed could be made autonomous or implemented on an aerial platform in future development. The main goal of this project was to create a system that had individual sensors that can navigate through a predefined grid and use the received signal strength taken at different points and angles to locate the emitting signal. Our team used a mobile platform that has a programmable motor controller, a Software Defined Radio (SDR), a microprocessor, and various sensors. Our team was able to implement an Xbox 360 remote as a user control for movement and access to sensor data. The initial plan was to have an autonomously controlled system, but the accuracy of the off-the-shelf GPS was not sufficient. Our team suggests using a more accurate GPS sensor in order to implement a waypoint navigation algorithm.

Transmitting Rover

Project Overview

For this project, our team has been working for the United States Air Force Research Lab (AFRL). The United States Air Force (USAF) has the desire to be able to locate emitters at different frequencies for a number of different reasons, including locating enemy communication signals. The goal of our team’s project was to create a testbed that would collect the required data to run a compressive sensing algorithm that is currently being developed by the Rose-Hulman Institute of Technology Department of Mathematics. Our project was intended to be a fundamental stepping block for much more complicated data collection, but more importantly, to collect data to test the effectiveness of the geolocation algorithms. The main deliverables for this project include the testing hardware developed by our team and a detailed testing plan. Our team was able to achieve creating reconfigurable sensors that are mobile and able to collect data when requested by the user.

Logical Architecture
Domain Model



We chose to use the BeagleBone Black for our microprocessor. This enabled us to have plenty of room for additional sensor expansion. It takes 210-460mA at 5V and has I2C, Serial, UART, GPIO, and Analog Input along its pin headers. Additionally, it has an HDMI, USB, Ethernet, microSD card, and microUSB inputs. A BeagleBone Proto Cape was used to get rid of wire clutter.

We chose the Alfa Wi-Fi USB Adapter as a reliable/powerful Wifi adapter. The Wifi adapter must be plugged into the USB port upon start up in order for the connection to work.


The Adafruit Ultimate GPS Module was used as our GPS sensor. This was the best COTS GPS device on the market at the time. Details of the pins of the GPS sensor can be found here. We also used the External GPS Antenna to increase the gain of the GPS. Take note that this antenna is magnetic, although we do not utilize this on the rovers. Feeding this antenna through the top of the rovers' cover is extremely tedious, but was done to remove the magnetic antenna away from other hardware such as the SDR.


The compass is located on the outside of the rover and is wired through the cover down to the expansion cape. The compass specs can be found here. The compass uses I2C to communicate to the BeagleBone. Before testing can be done, a calibration of the compass must be performed. This includes turning the compass 720 degrees in 2 - 30 seconds.

Software Defined Radio

The Software Defined Radio (SDR) is the most complicated piece of hardware on board. It has much more power than the BeagleBone, although not as much input/output. Still, this piece of hardware has huge potential into further research and development. The SDR used in our project was the Ettus Research E100. The SDR communicates directly with the BeagleBone over an Ethernet connection. The USRP E100 is a top-of-the-line embedded SDR. A complex communication system can be programmed using python or GNU Radio (or its graphical version, GNU Radio Companion). After talking to an Ettus Reserach representative and determining the metal cover has no effect on performance, we chose to remove the casing to conserve space within the rover. It is imperative that care be given to these devices as they are fragile and extremely costly. Attached to the SDR is the Daughterboard and the Antenna. One SDR was programmed as a transmitter using an omni-directional antenna, while the other two rovers were programmed as receivers with directed antennas.

Since the start of the project, new SDRs have come on the market. NI's version of the Ettus Research USRP is widely used in the classroom and is easily programmed with LabView. Cost is a limiter on this product. A second, much less costly product of interest is the Hack RF. This could be helpful in simple RF protocol research.


The daughterboard is connected on the top of the SDR. We chose the RFX900 due to its operating frequency range in the IMS band. Make sure the board is properly attached to the SDR for accurate results. Other daughterboard could be purchased to change the frequency band.


Antennas chose for this project were the log periodic directional LP0965 as the receiving antenna and the omni-directional VERT900 as the transmitting antenna. These should be wired directly to the SDR using SMA connectors. Any antenna could be used for the transmitter or the receiver based on the needs of the testing. For example, all of the rovers could have the VERT900 as their antenna. The algorithm would have to modify its parameters to account for this change.

Payload Housing

The payload housing was constructed out of clear plastic using a custom drawing. We found this to be the cheapest, most reliable, and fastest option when considering payload housing. Modifications can be done to the plastic to make room for additional hardware, antennas, etc. The payload housing was "tested" by accidentally dropping a rover off of a table... Luckily it survived without a scratch! Be aware the the teeth of the siding can break off if not careful when removing components. Securely snap all parts together. If the parts fit a little too snug, use a flat-head screwdriver to lift the edge up. Sandpaper can be used to slim parts down.

Mobile Platform

The mobile platform consists of the Dagu Wild Thumper and the T'Rex Motor Controller. These two components together enable our rovers to move.

Wild Thumper

The Dagu Wild Thumper seems to be one of the best DIY RC platforms on the market. With options of 35:1 or 75:1 gear ratio, we chose the 75:1 in order to get more torque out of the wheels. The Thumper also comes with all terrain wheels, adjustable suspension, and a maximum payload of 11lbs. Motor encoders can be purchased it enable better control of the drive.

T'Rex Motor Controller

The T'Rex Motor Controller is one of the recommended motor controllers for the Wild Thumper. It has an Arduino bootloader that can modified via the microUSB port. The motor controller can be controlled via I2C, GPIO, RC, or Bluetooth. Separate RC or Bluetooth modules must be purchased in order for these controls to work. We chose to interface via I2C. Note that pullup resistors must be placed on the SDA and SCL lines in order for communication to work both ways. The code used was the Example Code included on the products website.

We've had a lot of troubles with the motor controller for this project. A different motor controller such as the Pololu version of the TRex is recommended.

Power System

User Control

User control is mainly through the Xbox 360 controllers and Xbox 360 wireless receiver. When the wireless receiver is plugged into the computer, press it's connect button while pressing the same button on one of the controllers. This should connect the two, however, the light will continue to blink on the receiver.

See the Control Flow Diagram below

Currently, the rovers can only move forward, backward, and turn in a circle. They cannot turn and move forward/backwards at the same time. This was to keep the controls simple in the initial testing. This could easily be modified with future testing. The left joystick enables the forward/backward motion. The right and left triggers enable the turning in the circle. The "A" button is used to collect data. And the "B" button is used to calibrate the compass. All buttons are available for expansion to add features to the rovers.

A future version could use autonomous motion while the user isn't controlling it and user controlled motion when the user uses the Xbox 360 controller.


Our code can be cloned from GitHub.

Software Flow Diagram
Alt text
Control Flow Diagram


The Client code is ran on the BeagleBone. This code integrates all of the sensors and communicates information back to the host computer. The current BeagleBones are the Rev B version running Angstrom with the September 4th, 2013 image. The Client runs two primary programs. The first (Client.c) interfaces with the Central Processing Node, while the second (SDRdata.py) interfaces with the SDR. These two programs interface through a UNIX socket.


Getting the BeagleBone (aka Client) to connect to the Wifi was a challenge. First, make sure the Router is maintained with a ESSID of "beagle" and the password is set to "beagle10". This can be done by pointing a browser at the IP address of the router when connected to its Wifi. Direct instructions on how to set up the Wifi with BeagleBone Black Rev B (the version we are currently using) can be found here. I've found better instructions for Rev C provided on Adafruit's website. These instructions seem to provide a much more stable connection. I skipped the disabling of the HDMI port and it still maintains a consistent connection.

The Central Processing Node (Server or computer) must be set to an IP address of


The Server, also known as the Central Processing Node, is the primary computer used in the test. This computer must be connected to the network via Wifi or Ethernet and have the Xbox 360 wireless receiver attached to one of its USB ports. Be careful on what else you have plugged into your USB ports, as this may affect the location of the Xbox 360 wireless receiver within the Linux system. To ensure you are connected with the Xbox 360 wireless receiver run the command:

main-computer$ lsusb

The output should tell you that the Microsoft Wireless Xbox360 Receiver is connected. Without this connected, the Server program will not execute.

Software Defined Radio


Subsystem Testing

Full System Testing

For correct operation, the following boot sequence must be followed:

  1. Power on the Wi-Fi router
  2. Connect the central processing node to the router
  3. Power the Beaglebone; wait for it to connect to the network
  4. Power the motor controller and the SDR

Location of Measurements

Alt text
Location of Measurements

Simulation of Position Points


Future Developments


Integrating MATLAB to view data in real-time is a potential addition to this project. This would enable users to understand and view solutions to the algorithm in real-time while controlling the rovers. In order to do this, a UNIX socket could be set up between the Server code and the MATLAB code so that once the Server code receives data, it is then relayed to MATLAB. Once MATLAB receives the code, it could add it to the table of previous data points and recalculate the position of the sensor using the algorithm.

Wild Thumper Controls

The controls to the Wild Thumper seem to be incorrect. Videos online seen here, show the Wild Thumper moving seamlessly through rough terrain. Our Wild Thumpers have a difficult time navigating even on pavement. This could possibly be due to its' heavy payload. Having two battery packs on board does not help.