D-STAR Heat Map

Update: Feb 21st, 2010

Summary of Project

Using a serial port interface to an ICOM ID-1 radio communicating with K2CC’s DSTAR Digital Data Repeater, signal strength can be measured in real time during simulated data transfer. This data is geotagged with the data from a USB GPS receiver connected to the same computer. Phil Hart (KC2SGA) and I then drove around Potsdam and recording signal strength all over. This data will be used to build a color coded heat-map of the town to see where signal propagation is best. This is all done in the 1.2GHz range of ham radio spectrum. This will later be used to aid in deployment of emergency data nodes should it become necessary to replace failed mobile digital infrastructure based on the cellular network.

Type of Project

Personal/Academic (Extra-curricular)

Current Status

In Progress

Goal

Generate a heat-map overlay on a map of St. Lawrence County representing the signal strength indicated by the ID-1 test setup (documented below) in communication with the K2CC Repeater/Gateway. This heat-map is intended to be stored in image and binary data formats so that potential deployment areas for mobile digital data relay rigs are quickly located in the event of an emergency

Details

ID-1 Antenna

In all development and tests the same antenna was used on the ID-1. This is a Diamond NR2000NA Mag-mount Triband omnidirectional whip. This antenna is designed for 2m/70cm/23cm making it useful for all digital voice and data operations, as well as standard FM repeater operations. This antenna is ideal for vehicles utilizing the emergency communications as with the correct diplexer used to isolate radios on each band and connect them all to the antenna.

Photo of Antenna mounted on to Phil's (KC2SGA) car.

ID-1 Communication Protocol

The ID-1 radio simply uses an FTDI FT232R chip to interface over USB to the computer as virtual COM port. However the vendor strings on the chip have been reprogrammed, which has caused some driver problems (see Bench Setup). Otherwise, the setup works as advertised, and it was easy enough to attach our own software to the port to control the radio and receive signal meter readings. Fortunately with some investigative web searching I was able to turn up an ICOM document that details the serial link settings, as well as the actual command set and protocol used to communicate with the radio. This was immensely helpful in being able to decipher the data and establish a link with the radio. Initial experimentation indicated that the radio would not send data until it was polled over the serial line, presumably to not send data unless the ICOM application was running, and ready. This was not indicated in the documentation, and had us thoroughly confused for a while. However once communication is established the radio willingly and automatic sends S-meter reports whenever the reading changes. This made it pretty easy to work with, we just poll the radio periodically to keep the link alive, and parse and log incoming signal readings as they come.

ID-1 Bench Setup

First, in order to get the software written and debugged to recover signal readings from the radio, we set it up on my workbench, using a DC power supply and the aforementioned antenna. Once there it was hooked up to Phil’s (KC2SGA) laptop, and we interacted with it in a Windows XP Virtual Machine. This was done because the ID-1′s computer interface is a USB Serial Port powered by the very common FTDI FT232R chip, however it has a specific ICOM Vendor String which doesn’t allow us to use the signed drivers, as such Windows Vista and Windows 7 64-bit Editions are none too happy with it. I’m currently working on a way to reverse the change and make the chip identify as itself so I may use the FTDI signed and verified driver.

Since the ID-1 is just a serial port to the computer, we also used two USB/TTL breakout boards I had around and used them to redirect output from the official (non-free) ID-1 control software published by ICOM. This was done to see how the software initialized communication with the radio, as well as test responses to other things.

Once the software was up and running we moved to the Mobile Test Setup, and continued tweaking there. For the next revision of the software we will likely return to this configuration.

ID-1 Bench Setup

ID-1 Bench Setup

ID-1 Mobile Test Setup

Once the software was able to retrieve signal meter readings from the radio, we moved the radio to Phil’s car, running off a 13.8VDC bus tapped off his car battery. The mag-mount antenna was placed on his trunk, fed through the trunk and connected to the radio in the backseat. I was also in the back with Phil’s laptop connected to the radio and the GPS receiver. I surfed the Internet through the gateway link the entire time we were driving to keep the link active. I eventually intend to write a utility to transfer random data so the transfer is more consistent, but since this was a test run I wasn’t too concerned. As Phil drove around, our software logged radio signal strength readings with GPS coordinates and timestamps in a basic comma-separated text file. This data was later imported in to MATLAB for processing. Notable problems with this setup, the connection seems to fluctuate wildly while moving, but is pretty stable when immobile, so it seems to get accurate data will take a lot of pulling over and parking. This appears to be a limitation in the radios transmission and receive capability, perhaps related to the high bandwidth data modulation. Also, the software occasionally stopped responding, it is unknown if this is a problem with the radio timing out (see communication protocol notes) or something else.

RC-2D Repeater/Gateway

The other side of this setup is the base station, an ICOM repeater stack containing an ICOM RC-2D 1.2GHz Digital Data Repeater. This is connected to a 1.2GHz omni-directional antenna mounted to the radio tower atop the Cora & Bayard Clarkson Science Center on Clarkson University’s Hill Campus. This puts the antenna at an elevation of approximately 500ft above sea level. The gateway node is connected to Clarkson University’s network through a CentOS Gateway Machine running ICOM software. This allows us to access the campus resources and Internet pipe through the 1.2GHz link. The data network is interfaced between the radios and computers with a 10Mbit/s Ethernet link, meaning the D-STAR system acts as a sort of generic Ethernet hub. As such, traffic can be easily exchanged between radio nodes and the outside world. The gateway node here will likely be the central serving point for any networked communication system.

The Radio Tower atop Cora & Bayard Clarkson Science Center

Data Collection Software

The software to collect data from the radio is written in Perl, using standard libraries for both serial port access and GPS data parsing. The GPS we’re using outputs standard NMEA sentences, which are easily parsed by many Perl modules. The radio itself, once it has been queried once starts sending automatic databursts indicating changes in several conditions, including received signal strength on a scale of 0 to 100. It would appear the radio does not send any data until polled once, we suspect this is to prevent it from sending data if the ICOM software is not running. However it would appear periodically polling something is enough to get the radio to talk. We’ve written our own state machine based parser for the data coming from the radio, also the software periodically polls the radio for status to ensure that the radio does not time out and stop sending S-meter readings. This data is then combined with the current position and time retrieved from the GPS over serial with the NMEA parsing module, and written to a file. On launch the application opens a file based on the current timestamp, ensuring the ability to restart the program in the field without worrying about overwriting old data. This proved crucial when a bug in the field caused the program to stop responding, I believe this bug is related to the aforementioned time out.

Mapping Software

Phil Hart (KC2SGA) wrote much of the code to parse the raw logged data and process it in to a heat-map. Currently he has some rough code that can generate maps and overlays, and you can see his prototypes below in the images. We are considering a new method for handling this part of the process, another member of K2CC/SPEED, Shaun Jones (KC2WQP) is researching a new mapping system that may simplify this process, and improve the quality of the results. Stay tuned.

Raw Signal Data

Raw Signal 2D Plot

Partial Heat Map

Initial Heat Map Test


Phil's Second Attempt

Shaun's First Attempt

Relevant Blog Posts

I’m back, for now… – 10/11/2009

New Project Page! – 2/9/2010

D-STAR Heat Map Update – 2/21/2010

Switch to our mobile site