Building the STM32F4 DISCOVERY Toolchain For Mac OS X

Posted on by
2

The STM32F4 DISCOVERY is a very neat development board for the STM32 F4 series microcontroller. Not only is it neat, but also cheap. As in $14.55. Here’s the link to buy one from Mouser.

I have some radio related projects that I plan on implementing with this unit. But first I had to get the Open Source development tools installed. And while there are numerous webpages that describe how to do this, none of them actually worked. Such is the world of Open Sores.

With a bit of help, I was able to get things up and running. To save others grief, I’m documenting what I did to get things working. First, a brief description of what goodies you get with this development board.

Here’s a datasheet for the development board.

Some of the Features:
■ STM32F407VGT6 microcontroller featuring 32-bit ARM Cortex-M4F core, 1 MB Flash, 192 KB RAM in an LQFP100 package
■ On-board ST-LINK/V2 with selection mode switch to use the kit as a standalone ST- LINK/V2 (with SWD connector for programming and debugging)
■ Board power supply: through USB bus or from an external 5 V supply voltage
■ External application power supply: 3 V and 5 V
■ LIS302DL, ST MEMS motion sensor, 3-axis digital output accelerometer
■ MP45DT02, ST MEMS audio sensor, omni-directional digital microphone
■ CS43L22, audio DAC with integrated class D speaker driver
■ Eight LEDs:
– LD1 (red/green) for USB communication
– LD2 (red) for 3.3 V power on
– Four user LEDs, LD3 (orange), LD4 (green), LD5 (red) and LD6 (blue)
– 2 USB OTG LEDs LD7 (green) VBus and LD8 (red) over-current
■ Two push buttons (user and reset)
■ USB OTG FS with micro-AB connector
■ Extension header for all LQFP100 I/Os for quick connection to prototyping board and easy probing

Now for the gory details of actually getting all this to work:

First, my system:

I installed this on a Mac Book Pro running Mac OS X 10.6.8. I wanted it on a laptop so I could take it to my basement workshop to do the actual development work. You can do this under linux and Windows as well. I don’t have any information on doing that, you’re on your own. Good luck.

I installed Xcode 4.2, which is the latest version that will run on 10.6 Snow Leopard. I understand that Xcode 4 is required to get the development stuff up and running, I do not know that for a fact, however.

First you need to install a bunch of stuff:
brew install mpfr gmp libmpc texinfo libusb-compat libftdi wget

This uses Homebrew, which you must install if you don’t already have it.

This toolchain script was used as the base: https://github.com/ehntoo/summon-arm-toolchain

As I said earlier, it does not quite work out of the box.

A big thanks to Gwynne who came up with a patch.

So all you need to do is:

cd && git clone git://github.com/ehntoo/summon-arm-toolchain.git && cd summon-arm-toolchain && wget -O - http://darkrainfall.org/build-openocd.patch | patch -p1 && ./summon-arm-toolchain

Then… wait. A while. It takes 20-30 minutes to build everything. Go have lunch.

All of the dev tools are put into ~/sat so make sure that is in your $PATH variable:
export PATH="$HOME/sat:$PATH"

Plug in the dev board and connect to it with the On Chip Debugger:
openocd -f board/stm32f4discovery.cfg

if all goes well, a bunch of text is spit out into the terminal window, ending with:
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Then open up another terminal window and connect to the On Chip Debugger:
telnet localhost 4444

Next I grabbed the STM32 Discovery firmware files, to get some sample code:
git clone https://github.com/nabilt/STM32F4-Discovery-Firmware.git

I decided to try the IO_Toggle project first, which turns some digital outputs, connected to LEDs on the board, on and off. Toggling LEDs is the microcontroller version of a Hello World program.

Building the project did not go completely smoothly. I needed to change a line in the Makefile dealing with floating point:
MCFLAGS = -mcpu=$(MCU) -mthumb -mlittle-endian -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb-interwork
to
MCFLAGS = -mcpu=$(MCU) -mthumb -mlittle-endian -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -mthumb-interwork

I don’t yet have a good explanation as to the need to make the change, but I saw it mentioned on many websites while searching for a solution to the problem.

The result is a demo.elf file which gets downloaded to the dev board.

Open up yet another terminal window (while in the directory containing demo.elf) and run gdb via:
arm-none-eabi-gdb

In the OCD telnet window, stop the program currently running on the microcontroller:
reset halt

Then in the window running gdb:
target extended localhost:3333
load demo.elf

Then in the OCD telnet window run the program:
reset run

I was rewarded with blinking LEDs. I then edited the main.c source code to change their toggle rate, and re-built the project, as a test, which all worked.

Next step, some radio related programming!

Homeopathic Radio Engineering

Posted on by
2

Mainstream radio engineering principles hold that the received signal strength of a transmission is proportional to the radiated power. Doubling the transmitter power produces twice the received power, quadrupling the transmitter power produces four times the received power, twice the received voltage, which is 6 dB or one S unit. This has been accepted for over a century.

However, recent experimental results, first reported on the FRN and later in The Journal of Irreproducible Results cast doubt in this basic radio engineering theory.

These results claim that as the transmitter power is reduced to very low levels, the received signal strength actually goes up, not down.

A transmitter location on the east coast of the USA was used. The tests were conducted on HF radio frequencies on and around 6925 kHz, using a state of the art solid state transmitter with a standard off the shelf MOSFET as the RF final amp:

Each monitoring post was equipped with the highest quality HF receiving gear and highly sensitive monopole receiving antennas.

During the trials, it was found that placing a non-conductive fabric, such as a sock, over the receiver produced the strongest signals. While the exact mechanism for this effect is not yet known, it is presumed to be due to the high dielectric constant of the fabric.

The results of the experiment clearly speak for themselves, as transmitter power went down, the signal strength went up:

One way to explain the results is to return to the luminiferous ether theory of radio propagation. Radio waves are propagated by vibrations in the ether. Fewer radio waves means that there is more ether per radio wave, so the vibrations are larger, producing a stronger signal at the receiving site.

There were even reports of radio propagation that cannot be explained by any known laws of physics, such as signals in the daytime traversing from Montana to New Zealand on 6955 khz with a completely sunlit path, even though D layer absorption would make this completely impossible. Yet this was reported many times by longtime radio physicist Dr. Winston: “The signals were always received with as SIO of 555. Even the audio quality was perfect, why it sounded like I was listening to it live in the studio!”.

Several times signals were actually received and logged on the FRN before the transmission began. This suggests that superluminal neutrinos may be involved.

Further research into this new phenomena is required. If homeopathic radio is ever perfected, it would allow listeners to report hearing transmissions that used little, or theoretically even no power. Indeed, reducing the output power to zero watts might produce the best results of all for this type of station.

Boom Box Radio Early Morning Propagation Analysis

Posted on by
Reply

Boom Box Radio had an early morning transmission on March 10, 2013, from 1044 until 1212 UTC. They were trying to reach a listener in Guatemala. The time of this transmission, starting just before to after sunrise, lets us examine the effects of sunrise on reception on the 43 meter band.

This first waterfall shows when Boom Box Radio signed on at 1044 UTC. You can see a very faint trace appear on the waterfall about a quarter of the way up from the bottom, at 6925 kHz. Remember that with a waterfall, time flows or falls down, like with a real waterfall, so the latest information is at the top:

This next waterfall shows what happened at 1107 UTC, when the signal went from just a faint trace of a carrier on the waterfall, and no audio, to a very good S7 to S9:

Note again that the oldest information as at the bottom of the waterfall. At that time, there is just barely a carrier. Then you start to see some modulation, and then finally, in a matter of seconds, the signal shoots up to armchair quality.

Below is a graph showing the signal strength of Boom Box Radio, in dBm, from 1044 UTC sign on, until 1212 UTC sign off. You can click on it to see a larger version:

An S9 signal corresponds to -73 dBm. Every S unit is 6 dBm, so S8 is -79 dBm, S7 is -85 dBm, etc.

I have annotated several important times: The 1044 UTC sign on, 1107 UTC when the signal went up, 1125 UTC which was local sunrise, and 1212 UTC when it went off the air.

You can see that there is a very slow increase in signal level after the sign on, but the signal remains extremely weak. Then suddenly at 1107 UTC, the signal shot up to S9. Then for the rest of the transmission it mostly stayed in a range between S7 and S9.

The sudden increase in signal was caused by the Sun increasing the ionization level of the F layer of the ionosphere. This increase needs to have occurred at the point in the ionosphere where the radio waves are being reflected, most likely roughly midway between the transmitter and receiver locations. Note that in my case, this occurred before my local sunrise. This could be due two at least two factors I can think of. First, the transmitter site could be to my east. Second, the ionosphere is several hundred miles up, so it experiences sunrise before a point directly below it (on the Earth’s surface) does.

I believe this graph shows the importance of selecting the correct time for transmissions, depending on your target area. Just before sunrise is when the ionosphere is the weakest, and is only able to reflect radio waves on 43 meters at low angles. Too early in the morning, and the band is not open for local (NVIS – Near Vertical Incidence Skywave) reception. The band is, however, open for reception to more distant locations, that is, more than many hundreds of miles away (well over 500, perhaps close to 1,000 miles). If you’re trying to get out to DX locations, this is a good time to do it. Sunrise varies throughout the year, so as we move into summer, and it occurs earlier, the band will likewise open up earlier for NVIS. Likewise in the middle of winter in December, it is somewhat later.

For reference, the operator of Boom Box Radio stated that this was a Heathkit DX-60 transmitter putting out 40 watts into a 40 meter band dipole that was about 15 feet high.

I thank Boom Box Radio for conducting this early morning test.

Update: The operator contacted me again to mention that his local sunrise was at exactly 1107 UTC.

Shortwave Pirate Radio 2012 – A Year in Review

Posted on by
3

To gauge shortwave pirate radio activity in 2012, I analyzed the loggings to the HF Underground (http://www.hfunderground.com) message board. A computer script parsed the message thread titles, as well as the timestamps of the messages. This information was used to produce some statistics about the level of pirate radio activity. Of course, as Mark Twain has written: “There are three kinds of lies: lies, damned lies, and statistics.” Still, let’s see what we can learn.

There were 8683 messages posted to 2081 unique threads. Ideally, each thread represents an individual pirate station transmission. Also ideally, each message posted to a thread represents one logging. In reality, there is some error involved.

For example: the thread with the most messages, and therefore probably the most logs, and less probably the most listeners hearing it, was Wolverine Radio on October 19, 2012, with 39 messages. The numbers are slightly inflated, since a few reporters posted more than once. But it’s still a useful gauge how well heard a transmission was. If you’re interested, second place was a logging of an UNID on 3223 kHz on March 28, 2012, third place was Wolverine Radio again, on September 30, 2012, and fourth place was Pirate Radio Boston, on October 27, 2012. The UNID station had a lot of duplicate posts by individuals, which accounts for the high ranking.

The following graph shows the number of logging threads with a given number of messages:

Looking at the graph, we see that there were 464 broadcasts with a single logging. 344 broadcasts had two loggings, 318 had three loggings, and so on. This tells us that the vast majority of transmissions were only reported by a small number of people. Over half were logged by three or fewer people, and three quarters by five or fewer people.

This of course does not mean that only that number of people heard the transmission. It is quite probable that the vast majority of pirate radio listeners do not log their reception reports on the HFU or any message board. Some may directly contact the station, while others listen but have little or no contact with other pirate enthusiasts or stations. Anecdotal evidence suggests there are a lot of “lurkers” in pirate radio, who may in fact be the vast majority of listeners. It is unfortunately impossible to come up with a good estimate of how large the pirate radio listening community really is.

If we assume each thread represents a unique transmission, then if we count the number of threads per pirate station, we can estimate how many transmissions they had. There are a few flaws with this method. First, it’s possible that there are some duplicate threads for a given transmission (two threads started by two listeners for the same transmission). This could inflate the estimate number of transmissions. Second, the loggings posted on the HFU represent what users heard and reported. There’s often stations that people hear but do not log, perhaps because they don’t get around to it, or because they’re not HFU users. Hang out on IRC #pirateradio for a while, and you will see many transmissions being mentioned, but never logged. This could make the estimated number of transmissions obtained by this method too low. Third, there’s also the question of what “counts” as a transmission. If a station was on for a few seconds with a test, but was logged by name, then it gets count. Finally there likely are some transmissions that no one heard, possibly due to poor propagation conditions.

Tabulating the information by station name, here are the stations with at least two or more transmissions logged on the HFU, sorted by number of transmissions (message threads):

Stations With Most Transmissions:
#1 Rave On Radio (85)
#2 Radio True North (82)
#3 Captain Morgan (81)
#4 Undercover Radio (79)
#5 Radio Ga Ga (66)
#6 Blue Ocean Radio (62)
#7 Wolverine Radio (51)
#8 Radio Ronin (49)
#9 Red Mercury Labs (42)
#10 WBNY (36)
#11 Turtlehead Radio (33)
#12 WMPR (32)
#13 XFM (23)
#14 Pirate Radio Boston (23)
#15 Renegade Radio (21)
#16 Channel Z (19)
#17 Metro Radio International (18)
#18 The Crystal Ship (18)
#19 WPOD (18)
#20 Big Boobs Radio (15)
#21 Grizzly Bear Radio (15)
#22 Voice of Captain Ron (15)
#23 Northwoods Radio (14)
#24 Toynbee Radio (14)
#25 Radio Bleh Bleh (13)
#26 MAC Shortwave (12)
#27 EAM Guy (11)
#28 Insane Radio (10)
#29 Northern Relay Service (10)
#30 Radio Free Mars Radio (10)
#31 Chamber Pot Radio (9)
#32 Liquid Radio (9)
#33 Radio 2012 International (9)
#34 Radio Free Euphoria (9)
#35 Radio Jamba International (9)
#36 Stone Circles Radio (8)
#37 WFMT (8)
#38 Eccentric Shortwave (7)
#39 All Along The Watchtower Radio (6)
#40 Appalachia Radio (6)
#41 Hot Legs Radio (6)
#42 KPZL (6)
#43 Mushroom Radio (6)
#44 PeePee Vagina (6)
#45 Radio Casablanca (6)
#46 Radio Strange Outpost 7 (6)
#47 WBOG (6)
#48 XLR8 (6)
#49 Pissant Radio (5)
#50 Radio Whatever (5)
#51 The Machine (5)
#52 WEMP (5)
#53 Ann Hoffer Live (4)
#54 CYOT (4)
#55 Radio Vixen International (4)
#56 KAOS (3)
#57 EAM Girl (3)
#58 Hard Tack Radio (3)
#59 KIPM (3)
#60 KMUD (3)
#61 WPON (3)
#62 Cool AM (2)
#63 Dit Dah Radio (2)
#64 Pandora’s Box (2)
#65 Radio Clandestine (2)
#66 Radio KEN (2)
#67 WHYP (2)

Not making this list are stations with only one transmission reported. Also, since the loggings were analyzed with a script, it is possible that
some logs were missed due to misspelling of the station name, etc.

And in reality, in #0 position way at the top, would be:
#0 UNID (534)

As you can see, there are a lot of UNID stations reported. Many of these are short test transmissions, or one or two songs played. Some are longer, full length transmissions, with either no attempt at an ID by the operator, or conditions were such that no listener was able to pull out an ID.

It’s worth pointing out, again, that these lists are based on the logs posted on the HFU. There are many reasons why a particular station’s broadcasts occurred but were not reported. The user base of the HFU is heavily centered around the Northeast and Midwest of the US. There could be transmissions from other parts of the country, particularly the West Coast, which are not being reported, because there are too few users from that region. There are also certain stations which some listeners have decided not to publicly log, for a variety of reasons.

Next, we can count the total number of loggings for each station, and see how they rank. Note that this is sensitive to duplicate posts by the same listener for a given transmission, so values for some stations can be inflated:

Stations With Most Loggings:
#1 Undercover Radio (429)
#2 Wolverine Radio (413)
#3 Captain Morgan (382)
#4 Radio True North (357)
#5 Rave On Radio (346)
#6 Radio Ronin (341)
#7 Blue Ocean Radio (288)
#8 Radio Ga Ga (229)
#9 WMPR (195)
#10 Red Mercury Labs (189)
#11 XFM (168)
#12 Turtlehead Radio (129)
#13 Renegade Radio (116)
#14 Channel Z (114)
#15 WBNY (108)
#16 Metro Radio International (96)
#17 Pirate Radio Boston (88)
#18 WPOD (74)
#19 The Crystal Ship (70)
#20 Big Boobs Radio (69)
#21 Grizzly Bear Radio (69)
#22 Radio 2012 International (62)
#23 Northwoods Radio (55)
#24 MAC Shortwave (54)
#25 Voice of Captain Ron (54)
#26 Toynbee Radio (53)
#27 EAM Guy (50)
#28 Radio Bleh Bleh (46)
#29 Liquid Radio (45)
#30 Radio Jamba International (45)
#31 Radio Free Mars Radio (45)
#32 WFMT (38)
#33 Hot Legs Radio (38)
#34 Radio Vixen International (38)
#35 Northern Relay Service (37)
#36 KAOS (34)
#37 Ann Hoffer Live (34)
#38 Radio Strange Outpost 7 (34)
#37 Mushroom Radio (33)
#40 Eccentric Shortwave (31)
#41 All Along The Watchtower Radio (31)
#42 Radio Casablanca (31)
#43 Insane Radio (29)
#44 XLR8 (28)
#45 KPZL (27)
#46 Appalachia Radio (27)
#47 Radio Whatever (27)
#48 KIPM (26)
#49 Radio Free Euphoria (26)
#50 WBOG (22)
#51 The Machine (22)
#52 Chamber Pot Radio (21)
#53 Pissant Radio (21)
#54 Hard Tack Radio (20)
#55 PeePee Vagina (20)
#56 Stone Circles Radio (19)
#57 Dit Dah Radio (15)
#56 Pandora’s Box (11)
#57 WEMP (10)
#58 WPON (10)
#59 KMUD (8)
#60 CYOT (7)
#61 WHYP (7)
#62 Radio KEN (7)
#63 EAM Girl (6)
#64 Cool AM (4)
#65 Radio Clandestine (4)

In general, the stations that transmitted the most, were reported the most. The largest exception to this rule is Wolverine Radio, which is #7 for total broadcasts, but #2 for total reception reports. Wolverine is often noted with a very strong signal, this may count for some of the larger ratio of reception reports to transmissions.

In fact, we can produce a table of the ratio of reports to transmissions for stations (with more than 10 transmissions, to reduce errors due to insufficient data). Stations with a high ratio have a lot of listeners per transmission, stations with a low ratio have few listeners per transmission:

8.10 Wolverine Radio
7.30 XFM
6.96 Radio Ronin
6.09 WMPR
6.00 Channel Z
5.52 Renegade Radio
5.43 Undercover Radio
5.33 Metro Radio International
4.72 Captain Morgan
4.65 Blue Ocean Radio
4.60 Big Boobs Radio
4.60 Grizzly Bear Radio
4.55 EAM Guy
4.50 Red Mercury Labs
4.50 MAC Shortwave
4.35 Radio True North
4.11 WPOD
4.07 Rave On Radio
3.93 Northwoods Radio
3.91 Turtlehead Radio
3.89 The Crystal Ship
3.83 Pirate Radio Boston
3.79 Toynbee Radio
3.60 Voice of Captain Ron
3.54 Radio Bleh Bleh
3.47 Radio Ga Ga
3.00 WBNY

The average ratio is 4.75.

If we look at the estimated number of broadcasts by day of week, the results are inline with what we expect, namely that the weekends are most active, with a lull during the middle of the week:

Sunday 485
Monday 205
Tuesday 174
Wednesday 173
Thursday 173
Friday 320
Saturday 551

However, even the days in the middle of the week (Tuesday, Wednesday, and Thursday) have some level of pirate activity, about 3 or 4 transmissions per day. This is a very high level of activity as compared to what I remember from the 1980s and even the 1990s. Back then, weekday transmissions were much less common.

Breaking down the activity by month, we see there is some variation, with the busiest month, December (as we’d expect, with all the holidays) a little less than twice as active as the slow months in the Spring:

January 172
February 152
March 148
April 217
May 151
June 160
July 182
August 153
September 148
October 211
November 139
December 248

Looking at the transmitting modes used, AM and USB are virtually tied, with USB having a slight edge. The other modes are literally noise, with a small handful of reports. There’s a significant number of logs where no mode was reported, but it is virtually certain that either AM or USB was used:

AM 822
USB 849
LSB 21
CW 29
FM 21
SSTV 65
UNKNOWN 274

And what about the choice of transmission frequency? 6925 is the big winner, accounting for over half, and close to two thirds, of the logged broadcasts. If you add in the logs for 6924 kHz, which no doubt are pirates trying to end up on 6925 but who have a crystal or VFO that is slightly off, you end up with an even larger total. Clearly, if you can only monitor one pirate frequency, 6925 is the one:

6240 kHz: 4
6850 kHz: 5
6899 kHz: 9
6900 kHz: 12
6920 kHz: 5
6924 kHz: 82
6925 kHz: 1343
6926 kHz: 7
6927 kHz: 6
6929 kHz: 5
6930 kHz: 132
6932 kHz: 4
6933 kHz: 8
6935 kHz: 75
6940 kHz: 47
6945 kHz: 24
6949 kHz: 6
6950 kHz: 104
6951 kHz: 11
6955 kHz: 39
11428 kHz: 5
15070 kHz: 16

There are still a significant number of transmissions on other frequencies, with 6930 and 6950 being the most popular. 6955, which at one time was the most used pirate frequency in North America, is now down to 6th place, lower than the number of broadcasts by ops on 6925 kHz with a off frequency crystal.

Your comments, questions, and suggestions are greatly appreciated!

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

Posted on by
8

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

Posted on by
Reply

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

Posted on by
18

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

Posted on by
5

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

Posted on by
Reply

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

Posted on by
Reply

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.