Decoding ADS-B Aircraft Transponders: An SDR for $17 – The R820T USB RTL-SDR DVB-T Dongle – Part 3

   PSK31     
   iPad app to decode PSK31     

Please be sure to read Part 1 and Part 2, if you’re new to this series of articles.

All aircraft contain a piece of avionics technology called a transponder. This contains a receiver, and a transmitter. When the signal from ground radar is received, the transponder transmits a short burst on 1090 MHz, encoded with information.

There are several possible replies from an aircraft transponder:

  • Mode A replies with a target ID code
  • Mode B replies with the barometric altitude of the plane
  • Mode S, also called the Extended Squitter, is the one we’re interested in.

Mode S, also called ADS-B allows a variety of types of data to be sent from the transponder, including:

  • ICAO aircraft code (the tail number of the plane can be obtained from this)
  • Flight Number
  • Altitude
  • Location (Longitude and Latitude)
  • Heading

There’s an online document called ADS-B for Dummies that goes through the various messages, and their format.

Since the RTL dongles can receive 1090 MHz at a wide bandwidth, it turns out to be possible to use them as low cost transponder decoders. Very low cost. You can pick them up for around $15 on eBay. Dedicated ADS-B receiver packages are more. Much more. As in hundreds of dollars.

There are quite a few packages out for the RTL dongles that decode ADS-B transmissions. For Windows, there’s ADSB#:

For linux and Mac OS X, there’s Dump1090

I compiled Dump1090 for Mac OS X, here is what the output looks like:

The columns across the screen:

  • Hex – the ICAO code for the plane
  • Flight – flight number
  • Altitude – altitude in feet
  • Speed – speed in mph
  • Lat – latitude of position
  • Lon – longitude of position
  • Track – heading in degrees
  • Messages – the number of messages from this plane that have been received
  • Seen – how long ago (in seconds) since the last message from the plane, that is, how long since it has been last seen (or heard from)

I’ve since ported the Dump1090 code over to Cocoa on Mac OS X, resulting in Cocoa1090:

Cocoa1090 uses the ICAO hex code to derive the tail number (and aircraft model) from a database in a text file, which are also displayed.

A beta version of Cocoa1090 can be downloaded here: http://www.blackcatsystems.com/software/cocoa1090.html

Spying on your neighbor’s grill thermometer – Monitoring the 433.92 MHz ISM Band with an RTL Dongle

   PSK31     
   iPad app to decode PSK31     

Remote weather stations, some car key fobs (although many in the US use 315 MHz), wireless grill thermometers, and many other devices use the 433.92 MHz ISM (Industrial, Scientific and Medical) band. Chances are good that if it is a wireless sensor, it uses this band.

Here is a waterfall showing transmissions observed here, using one of the inexpensive USB RTL DVB-TV Dongles:

The entire waterfall occupies 139 seconds.

You can observe several periodic transmissions. I have a remote weather station and a remote thermometer, so that accounts for two of them.

If you have an RTL tuner dongle, take a look and see what 433 MHz transmissions are occurring near you.

An SDR for $17 – The R820T USB RTL-SDR DVB-T Dongle – Part 2

Earlier, I wrote about the RTL2832U based USB TV tuner dongles that can be turned in an inexpensive Software Defined Radio (SDR). Please take a moment to read that for an overview of these insanely great (for the price) modules, if they’re new to you. I’ve since mounted the dongle in a small metal enclosure:

There were two reasons for this, first to reduce noise pickup, the second was to easily add an F style antenna connector.

Next, I wanted to try getting the rtl-sdr series of command line programs to run. I had tried a set of pre built binaries, but they didn’t work, so I decided to build it myself.

First I got the code from http://cgit.osmocom.org/cgit/rtl-sdr/

I followed the instructions from http://sdr.osmocom.org/trac/wiki/rtl-sdr
cd rtl-sdr/
autoreconf -i
./configure
make
sudo make install
sudo ldconfig

The first problem was after ./configure, namely:
configure: error: Package requirements (libusb-1.0 >= 1.0) were not met:

Turns out I had an ancient version of libusb.
sudo port install libusb
solved that.

With the programs built, the next step was running rtl_test:
$ rtl_test -t
Found 1 device(s):
0: ezcap USB 2.0 DVB-T/DAB/FM dongle

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
No E4000 tuner found, aborting.

So far so good.

Next I tried running rtl_fm, which lets you demodulate a FM signal. AM is supposedly also supported. I say supposedly because I could not get rtl_fm to work properly. It would run, and write demodulated sound data to a file, but playing it back always produced gibberish. Also, the files were way too large for the specified sample rate and length of time the program was running. The documentation for rtl_fm is sketchy, even by open sores standards. For example, the list of options includes:
[-s sample_rate (default: 24k)]

which naturally makes you suspect -s sets the sample rate. It does no such thing, it actually sets the IF bandwidth. Again, supposedly.

After several hours of trying to get rtl_fm to work properly, I threw in the towel, and moved on to rtl_tcp, which acts as a little TCP server, sending I/Q data to a connected client. I had much better luck here. Running the program produced the following:
$ ./rtl_tcp
Found 1 device(s).
Found Rafael Micro R820T tuner
Using ezcap USB 2.0 DVB-T/DAB/FM dongle
Tuned to 100000000 Hz.
listening...
Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).

I then connected to it via telnet in another console window:
$ telnet 127.0.0 1234

And the rtl_tcp server program responded with:
client accepted!
and proceeded to send I/Q data to my telnet session, which spewed it to the window. Mission accomplished.

Next I wrote a small program to open a connection to the rtl_tcp server, and grab all the received data, count the number of bytes per second, and display it once per second, as a quick and dirty test to see if everything was working OK. I got around 4M bytes per second, which is correctly for a 2 MHz sample rate (the data is 8 bit I/Q, so there are two bytes per sample).

Having accomplished this, the next step was to make some use of the data. I thought trying to decode and display ADS-B aircraft transponder messages on 1090 MHz would be fun. That is my next post.

An SDR for $17 – The R820T USB RTL-SDR DVB-T Dongle

You may have heard of the latest SDR craze to hit the radio hobby – the RTL based USB dongle TV tuners. These were originally made to receive and decode the European standard digital television broadcasts. An enterprising hobbyist discovered that they can be tuned throughout the VHF and UHF range, and that you can get at the raw sampled data from the onboard A/D converter (only 8 bit, however). This allows them to be used as a very inexpensive Software Defined Radio (SDR) for VHF and UHF. How inexpensive? Mine was $17 shipped, although you can find them for even less, if you’re willing to get them direct from China and wait a few weeks for delivery.

Here is what I got:

There’s the dongle itself, as well as the small (about 4″) antenna.

It’s interested to note that the enclosure actually says SDR on it, the word has apparently gotten out about the SDR applications for this dongle, and someone is private branding them.

Here’s what the inside looks like:

The USB connector is on the left, the MCX style RF connector is on the upper right.

There are control programs available for Windows, Mac OS X, and Linux. For software, first I decided to try rtl-sdr I copied the libraries to the specified locations, restarted, and was greeted with:

>:rtlsdr_osx cps$ rtl_test -t
Found 1 device(s):
0: ezcap USB 2.0 DVB-T/DAB/FM dongle

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Failed to open rtlsdr device #0.

It’s possible this is an older version of the rtl-sdr package, that expects the E4000 tuner chip. (Although a less cryptic error message would sure be helpful)

Then I tried Cocoa Radio. It crashes on launch. So far open sores is zero for two.

So next I tried the Mac OS X port of gqrx. Much better! It came right up, and within a minute I was receiving FM broadcast stations. I have noticed that if I make a change to the sample rate, I need to quit and re-start the app before putting it into run mode, or it crashes.

The sensitivity is not bad, I was able to pick up stations about 50 or 60 miles away using the included tiny 4″ antenna, laying on my desk.

Below is a screenshot of gqrx running on the FM band, you can see three FM broadcast stations, at 97.9, 98.5 and 99.1 MHz, the latter is tuned in for demodulation.:

I was also able to pick up 2m packet radio transmissions on 144.39 MHz, and one of the NOAA weather radio stations, on 162.525 MHz.

There are many varieties of these TV tuner dongles out there, mostly the difference is the RF tuner chip used. Previously the E4000 tuner was the preferred one for SDR applications, as it had the widest tuning range, although with a gap in the middle. It apparently is no longer made and is difficult to find tuners that use it. Currently the R820T tuner chip seems to be the preferred one for SDR use, the tuning range is slightly less, but there is no gap. Some eBay vendors identify the chip used, many do not, but there are lists online of the various USB dongles by brand name and model number, with the tuner chip specified, such as here.

My next project was mounting the dongle in a small metal enclosure, with a different RF connector, so I can easily connect one of my existing outdoor antennas to it. Read all about it here.

A Very Busy Christmas Weekend/Eve For Pirates

Here’s what folks have been hearing since Friday night. 41 different North American pirate radio transmissions so far, a total of 163 loggings, and it’s not even Christmas yet!

A big thank you to the operators for their shows, and the listeners for their reports.

All of these loggings can be viewed at the HF Underground

Pirate Radio Boston 6925 AM 1945 UTC December 24, 2012
WBNY 6240 AM 1604 UTC December 24, 2012
Eccentric Shortwave 6930 USB 1529 UTC December 24, 2012
Channel Z 6925 AM 1400 UTC December 24, 2012
UNID 6925 USB 1455 UTC December 24, 2012
Metro Radio International 6975 AM 1323 UTC December 24, 2012
Radio Ronin 6920 AM 1308 UTC December 24, 2012
Northwoods Radio 6925 USB 1200 UTC December 24, 2012
Channel Z 6925 AM 0427 UTC December 24, 2012
UNID 6955 AM 0212 UTC December 24, 2012
Rave On Radio 6925 USB 0200 UTC December 24, 2012
Radio GaGa 6925 USB 0140 UTC December 24, 2012
Radio Appalachia 6935 AM 0125 UTC December 24, 2012
Dit Dah Radio 6925 USB 0025 UTC December 24, 2012
Dit Dah Radio 6935 USB 2156 UTC December 23, 2012
WBNY 6913.34 AM 2150 UTC December 23, 2012
WKND 6924.6 AM 2148 UTC December 23, 2012
Metro Radio International 6925 AM 2008 UTC December 23, 2012
WEDG The Edge 1610 AM 1700 UTC December 23, 2012
Pirate Radio Boston 6925 AM 1612 UCT December 23, 2012
Pirate Radio Boston 6950 AM 1610 UTC December 23, 2012
Pirate Radio Boston 6925 AM 1805 UTC December 23, 2012
Channel Z 6925 AM 1346 UTC 23 December 23, 2012
1720 KHz “The Big Q” 0509 UTC December 23, 2012
Channel Z 6925 AM 0405 UTC December 23, 2012
WPOD 6925 USB 0130 UTC December 23, 2012
Wolverine Radio 6925 USB 0048 UTC December 23, 2012
Toynbee Radio 6925 AM 2258 UTC December 22, 2012
Monkey Mayan Memorial Radio 6925 AM 2222 UTCDecember 22, 2012
UNID 6950 USB 2218 UTC December 22, 2012
UNID 6924.7 Khz AM 2215 UTC December 22, 2012
Toynbee Radio 6925 AM 2131 UTC December 22, 2012
Pirate Radio Boston 6949.39 AM 2015 UTC December 22, 2012
UNID 6935 AM 1902 UTC December 22, 2012
Pirate Radio Boston 6949.39 AM 1355 UTC 2December 22, 2012
Rave On Radio 6925 USB 1241 UTC December 22, 2012
The Big Q 1720 & 1710 AM 0525 UTC December 22, 2012, 2208 UTC
Captain Morgan Shortwave 6950.7 AM 0240 UTC December 22, 2012
UNID 6925 AM 0225 UTC December 21, 2012
UNID 6924 AM 0203 also 6929 AM 0207 December 22, 2012
Insane Radio 6925 AM 0121 UTC December 22, 2012
Insane Radio SSTV 6925 AM 0021 UTC December 22, 2012

WWV and WWVH Via Both Long and Short Path on 15 MHz and I can Hear Russia From My House

In Measuring The Distance To A Shortwave Radio Station we looked at how the propagation delay in a shortwave signal can be used to estimate the distance to the station.

I ran some more tests the other day:

Below is a recording of 15 MHz, taken at 2300 UTC on December 13, 2012:

The GPS 1 PPS reference is on the top trace, and the audio from the radio is on the lower trace.

You can see the one second tick pulse from WWV in the audio, as well as two pulses from WWVH, the first (weaker) one is the normal (short) path signal, and the second one is via long path. We can confirm this is the case by converting the time delays into distance. We’ll use the same formula as in the previous article, we subtract off the 286 sample delay from the radio, multiply by 22.676 to convert the delay in samples to microseconds, then multiply by 0.186282 (the speed of light in miles per millisecond) to convert the delay into miles.

For WWV, the measured delay from the 1 PPS pulse is 660 samples. (660-286) * 22.676 * 0.186282 = 1580 miles
For WWVH short path, the measured delay was 1516 samples: (1516-286) * 22.676 * 0.186282 = 5196 miles
For WWVH long path, the measured delay was 5080 samples: (5080-286) * 22.676 * 0.186282 = 20250 miles

The distance to WWV is 1480 miles, and to WWVH is 4743. The long path distance to WWVH is 20158 miles.

Remember, the calculated distances can be longer than the great circle distance, due to the signal making one or more (many more in the case of long path) hops between the Earth and the ionosphere. Plus, there is the experimental error.

And here is one more example, this time it is the Russian time station RMW, on 14996 kHz, recorded at 1157 UTC on December 10, 2012:

The delay was 1835 samples: (1835-286) * 22.676 * 0.186282 = 6543 miles.
The great circle distance is 4821 miles.

Measuring The Distance To A Shortwave Radio Station

In a previous post, I showed how it was possible to crudely measure the speed of light (or at least another type of electromagnetic radiation, radio waves, in this case) by measuring the time delay between two shortwave radio time stations, WWV and WWVH.

I’ve decided to re-do that experiment, but in a slightly different way. Rather than measure the speed of propagation, I will use that speed to determine the distance to the radio station.

Various time stations transmit precise time on several shortwave frequencies. Here in the USA, we have WWV in Ft. Collins, Colorado, which transmits on 2.5, 5, 10, 15, and 20 MHz. We also have WWVH in Kekaha, Hawaii, which transmits on 2.5, 5, 10, and 15 MHz. These stations transmit an audio “tick” at exactly each UTC second. There is also the Canadian station CHU, located near Ottawa, Ontario, which transmits on 3330, 7850, and 14670 kHz.

One way to measure the speed of radio waves (and light) would be to measure how long it takes for the tick to travel a fixed distance. Divide the distance by the time, and we have the speed of light. However, that requires knowing the exact UTC time locally. This can be done with a GPS unit that outputs a 1 PPS (pulse per second) signal.

How to feed these signals into the computer, so they can be measured? The radio audio is easy enough, feed it into the sound card. It turns out the 1 PPS signal can also be fed into the sound card, on the other channel. I used a capacitor to couple it.

The first measurement that is required is one to determine what time delay is added by the radio electronics. In my case, I was using a JRC NRD 545 receiver, which has DSP (Digital Signal Processing) to implement the audio filters. This certainly adds a time delay. I therefore needed to run some baseline measurements, to determine how long this delay was.

I fed the same 1 PPS signal into the antenna jack of the radio. The signal is a short (10 microsecond pulse) that is rich in harmonics, so it produces a noticeable “tick” sound every second. I then recorded the audio from the radio, along with the 1 PPS signal fed into the other channel, and obtained this data (click on the graph to enlarge it):

I measured the time delay between the two ticks, and found it to be 286 samples. At 44.1 kHz, each sound sample is 22.676 microseconds. Multiplication gives us the time delay, namely 6485 microseconds. This delay added by the radio is constant, provided I do not adjust the IF filtering parameters (which were set to USB mode, 4.0 kHz wide, for all tests).

Next, the antenna was reconnected, an the radio tuned to 15 MHz. At this time of the day (about 2100 UTC) it is possible to hear both WWV and WWVH. Here’s the sound recording:

The WWV pulse occurs at about 5.18 seconds on the recording, and WWVH, much weaker and harder to see, at about 5.2 seconds.

The delay for the WWV pulse is 657 samples. Subtracting the radio delay of 286 gives us a delay due to propagation of 371 samples. Multiplying by our conversion factor of 22.676 microseconds per sample gives us 8413 microseconds.

Light (and radio waves) travel at 186,282 miles per second or about 0.186 miles per microsecond. For the metric inclined, that’s 299.792 km/sec or 0.300 km per microsecond. So multiplying our time in microseconds by the distance light travels each microsecond gives us the distance:

8413 * 0.186 = 1567 miles (2522 km)

The actual distance, along the Earth’s surface, from my location to WWV is 1480 miles, or 2382 km. Why the discrepancy? The radio waves do not travel along the Earth’s surface, but instead are reflected from the ionosphere, which is several hundred miles up. This means the actual path they take is longer. We’ll try to take that into account, a little further down.

The delay for the WWVH pulse is 1550 samples. Subtracting the radio delay of 286 gives us a delay due to propagation of 1264 samples. Multiplying by our conversion factor of 22.676 microseconds per sample gives us 28662 microseconds. We’ll do our next multiplication again, to convert to distance:

28662 * 0.186 = 5339 miles (8592 km)

The actual distance from my location to WWVH is 4743 miles, or 7633 km.

Next, here’s a recording from the Canadian time station, CHU:

The delay for the CHU pulse is 401 samples. Subtracting the radio delay of 286 gives us a delay due to propagation of 115 samples. Multiplying by our conversion factor of 22.676 microseconds per sample gives us 2607 microseconds. We’ll do our next multiplication again, to convert to distance:

2607 * 0.186 = 486 miles (782 km)

The actual distance from my location to CHU is 407 miles, or 656 km.

Now let’s try to take into account the actual path of the radio waves, which get reflected off the ionosphere. We need to know the height of the ionosphere, which unfortunately is not constant, nor is it the same over each part of the Earth. Here is a map showing the approximate height, while the above recordings were taken:

In the case of the path to CHU, the height is about 267 km, or 166 miles.

We also need to determine the straight line path between my location and CHU, through the Earth, vs the distance along the Earth’s surface. This can be calculated, and it is 391 miles, or 629 km.

We’ll determine what the actual path length is for a radio signal traveling this distance. It looks like a triangle, with a height of 166 miles, and a base of 391 miles. We need to determine the other two sides to find the total path length. All we need to do is take half of 391 miles, which is 195.5 miles, square it, add to that 166 squared, and take the square root, then double our answer. The result is 513 miles, which is very close to our measured value of 486 miles. We’re off by a little more than 5%.

Next let’s try WWV: The actual distance is 1468 miles or 2362 km. Doing our math, using an approximate FoF2 ionosphere height of 246 km (153 miles): Half of 1468 miles is 734 miles, we square that and add to 153 squared, and take the square root, and double our answer, getting 1500 miles. Our measured distance was 1567 miles, so we’re off by less than 5%.

Next, the case of WWVH. This is more complicated, as the signal probably is making more than one “hop”, that is, it is going up to the ionosphere, reflected down to Earth, and then reflected back up again, and down again. This may possibly occur multiple times.

We’ll try doing the math anyway. The actual distance is 4588 miles or 7383 km. Doing our math, using an approximate FoF2 ionosphere height of 253 km (157 miles): Half of 4588 miles is 2294 miles, we square that and add to 157 squared, and take the square root, and double our answer, getting 4598 miles. Our measured distance was 5339 miles, an error of 16%. But again, we don’t know how many hops there were. Still, not a bad effort.

Does anyone else have a GPS receiver with a 1 PPS output? If so, I’d like to hear from you, I have some additional experiments in mind.

Mysterious Ditter Network

First observed two days ago, there seems to be a new (to us HF listeners, anyway) network of HF ditter CW transmissions. The purpose of this network, as well as who is operating it, is unknown. It is possible they are for propagation monitoring. Based on observations of listeners and propagation characteristics, it would appear that at least some of the transmissions are coming from North America, possibly the Central US.

The transmissions do not occur at the same time on all frequencies. It appears that each transmitter steps through the frequencies. The following image shows the received signal on three of the frequencies (click on the image to view it as a larger size):

As you can see, thea transmission on each frequency begins right after the transmission on the previous frequency ends. This data was obtained by running a netSDR receiver in 500 kHz wide I/Q capture mode. The resulting recording file was then demodulated at each frequency of interest.

You can also see the second (weaker) dit on the 11150 tranmsission, that occurs shortly before the stronger main dit. (It is less obvious before the second dit, but you can see it, if you squint)

Each pulse (dit) is 130 milliseconds long, and they repeat every 6 seconds.

Next, the demodulated signal for a ditter transmission on each of the above frequencies is shown magnified, to see the exact times of each transmission.


How to find these transmissions:

I find that using an SDR is the easiest way, as you can observe a large portion of the spectrum at once. I use a 500 kHz wide view, and step through HF, looking for the periodic dits. But you can certainly use any radio. Note that the frequencies are all multiples of 25 kHz. They also sometimes occur in groups of three relatively associated frequencies. There are likely additional frequencies that have not yet been discovered.

If you’re hearing any of these transmissions, or have discovered possible additional frequencies, please let us know with a comment!

Transmissions on the following frequencies have been observed (all in kHz):
5450
5575
6225
6550
6750
7700
8000
8275
8775
8825
8900
8975
9050
9225
10050
10450
10575
10900
11025
11150
11225
11300
12450
13100
13250
13325
13875
14400
15100
15400
15625
16000
16350
16550
16725
17475
17650
17950
17975
18050
18100
18200
18450
18625
19300
19650
20100
20175
20250
22050
24050

Propagation Gives Away Your Location

Being as pirate radio is, well, illegal, operators like to stay anonymous. At least ops who want to avoid the FCC. Naturally, most ops consider keeping their location secret very important. Some even go so far as subtly, or not so subtly, providing false clues about their location, in an effort to fool the radio authorities. Unfortunately, basic rules of radio propagation make this futile.

A warning in advance. I’m going to be discussing some basic shortwave radio propagation theory. Nothing here is brand new, or unknown to anyone in the radio field. Certainly not the radio authorities. Some fur… err… feathers are possibly going to be ruffled by what is presented below, possibly with loud protests of “destroying pirate radio” and “releasing the identities of operators”. Nothing could be further from the truth. This is Propagation 101 stuff. If it scares you, then you probably shouldn’t be operating a pirate radio station. The purpose is the educate listeners and operators, so they know exactly what information can be gleaned from observing signal reports. It’s better to know exactly what can be done with this information, than to stick your head in the sand and pretend it doesn’t exist.

As has been discussed on this blog many times before, daytime propagation on the 43 meter band (where 6925 kHz is located) is considered NVIS (Near Vertical Incident Sky Wave). The radio waves go up, and are reflected back to the Earth for a fairly short distance around the transmitter site, usually a few hundred miles at the most. Attenuation by the D layer limits distant reception. At night, it’s almost the opposite reception pattern, as the D layer fades away, allowing distant reception. And the weaker F layer limits or eliminates NVIS reception, resulting in a skip zone around the transmitter, where the signal cannot be heard. The resulting reception area is shaped roughly like a doughnut.

So, for a daytime transmission, if one looks at a set of reception reports (as well as “no reception” reports, which can be equally useful), it becomes very easy to guesstimate about where a transmitter is. Not exactly of course, or even to a particular state, but certainly within a hundred miles or two. There will be a cluster of strong reception reports around the transmitter site, out to a few hundred miles. The maximum reception distance will vary a lot with transmitter level, antennas, and propagation conditions, but is likely under 1,000 miles. Look at where all the reports are coming from, especially the strong ones, find the center, and you have a good guess as to where the transmitter is.

At nighttime, listeners too close to the transmitter site (in the skip zone) will hear nothing, or at best a very weak signal. And during the transition from NVIS to DX propagation (see Going Long and An Interesting Example of a Station Going Long) the received signal will start to peak, and then suddenly cut out. Observing when this happens at a variety of listener sites provides other clues as to the transmitter location. If the F layer height and ionization values are known (and they are available in real time online) the distant to the station can be roughly determined when the station goes long. Do this for several receiver locations, and you can guess about where the transmitter is.

One ruse some operators have used in the past is to give misleading reception reports with a low signal level, using their real name and location, as just a regular listener. This is extremely dangerous, as if anyone is paying attention, their very weak signal report can stand out like a sore thumb if there are reports from others in the same area, with much stronger signal levels. Likewise, if you’re an operator, providing a completely bogus QTH doesn’t fool the FCC one bit. Announcing a QTH out on the Great Plains, while you’re really on the East Coast, doesn’t fool anyone when you’re being heard on the East Coast with an S9 signal at local noon. It just reminds everyone that you failed PROPAGATION 101. While shortwave propagation can be odd at times, there are limits. The laws of physics still must be obeyed.

The FCC and other radio enforcement agencies of course don’t have to rely on crude techniques such as these to locate transmitters. They have modern DFing equipment that can quickly and accurately locate a pirate station. The only reason they haven’t busted a given pirate is because, (as much as this may hurt to hear) that pirate is not important enough to get a visit. For now.

The commercially available WJ-9012 HF Direction Finding System, for example, boasts an error of less than 2 degrees. At a distance of 200 miles, that’s about 7 miles. Presumably the FCC has much better equipment.

While not announcing your location is probably a good idea (if for no other reason than to come across as taunting the FCC), in reality it doesn’t do too much to protect you from the radio authorities. Not interfering with allocated radio services, especially government and military, as well as operating from random remote locations, will go a long way to avoid getting The Knock.

Keep Safe!

mySdrPlayback – Mac OS X App to Play Back SDR I/Q Recording Files

I use an RFSpace netSDR to record the 43 meter (6800-7000 kHz) pirate radio band, overnight and often in the daytime as well. I then go back and check the recordings, to see what stations have been on the air. This lets me catch lots of broadcasts even when I am away from the shack.

Going through the recordings with traditional SDR software can be extremely tedious. You literally have to play the recordings at a real time rate, hoping to stumble across a transmission. Even being able to skip ahead and back is not much better.

So I ended up writing my own app to make the process of analyzing SDR recordings for interesting transmissions much easier and faster. I’ve just recently made this app available for others to download and use. It’s called mySdrPlayback (although it could probably use a more catchy name).

This is what the program window looks like (click on it for an enlarged image):

When the app loads, it reads in a list of all the recording files from the directory you have told it they are stored in. Clicking on a file loads it. A waterfall of the entire file is created, that is what you see in the large area on the right side of the window. The x axis is frequency, the y axis is time. Any transmissions are immediately obvious, such as a pirate on 6925 in AM mode, as well as WWCR, also in AM mode, on 6875 kHz. SSB and the various digital modes also have distinctive visual appearances. In no time, you can tell what type of transmission it is just by looking at it.

Files created by SpectraVue, the SDR app that RF Space supplies with their radios, SdrDx, the third party app also for RF Space radios, as well as files created by Perseus can be read. Other file types could probably also be added, if their exact format is known.

Selecting a portion of the recording file to play back could not be easier. Just drag select with the mouse by drawing a rectangle around it. Select the mode, and click Play. The frequency and time limits are displayed in the Secs Start/End and Demod fields when you drag select, you can also edit them in the boxes by hand if needed, to fine tune things.

The buttons to the left and right of Play let you skip playback behind or ahead by 10, 30, or 60 second increments, or even by 5 minutes. This makes it easy to jump around, looking for an ID. An S meter updates during playback, showing the signal strength in dBm.

The Demod To File button will demodulated the entire selected transmission to a WAVE file. You can then feed that into a decoding program, such as MultiMode if you want to decode an SSTV or other digital mode. You can also convert it to an mp3 file using your own utility, if you want to post it for others to download.

mySdrPlayback is only available for Mac OS X. There is no windows or linux version, and there never will be one. It’s written in objective-c and uses the extremely powerful and feature rich cocoa API. That makes development extremely easy, but is only available for the Mac. It can be downloaded from the program page: http://www.blackcatsystems.com/software/sdr_iq_recording_playback_program.html