Old Time Radio – Shortwave Pirate Radio Station Or Something Else ?

For about the past three weeks, we’ve had a bit of a mystery on the 43 meter pirate shortwave broadcast band. First logged on the HFUnderground on May 18, 2014 on 6772.6 kHz by EvilElvis as an UNID pirate playing “Tooth Powder commercial, 5 Minute Mystery, Red Skelton, Avalon Cigarettes commercial”, this station has been heard nearly non-stop since then, except for some short breaks, and a two day period between June 3 (it was last heard on June 2 at 2357 UTC and returned by 0035 UTC on June 5.

This station has been heard from coast to coast, and has a over 170 loggings on the HFUnderground Pirate Shortwave Radio Forum and has become quite the favorite of many shortwave pirate radio listeners. Many of us where disappointed when we turned on our radios on June 3 to just hear static, and equally thrilled to hear the station again when it returned two days later. I’m hearing it on 6772.6 kHz as I type this at 1323 UTC on June 6, 2014. It generally operates close to 6772 or 6773 kHz, but as also been heard on 6800 and 6880 kHz.

Possibly the same station was reported in the 13.56 MHz HiFer band previously. Glenn Hauser first logged it on 13560.7 AM on April 18 at 0520 UTC, and mentioned the following to me via email:

I haven`t heard it on any of the 6 MHz frequencies, but I keep wondering if it`s the same one I have reported thrice on 13560+. That would be 2 x 6780+ if that was ever a fundamental. Looking thru the posts (not sure I saw all of them) I don`t see anyone referring to that or to the webcast ID I heard from the 1920s Radio Network out of WHRO in Virginia. Should compare the programming to their schedule. They also have a separate mostly-music channel. 13560 was also pointed out to be a part 15 RF ID frequency which be some connexion.

The 1920s Radio Network has a website.

The general format seems to be playing music (often described as easy listening music, or even elevator music) during the daytime, and then old time radio shows overnight, hence the nickname Old Time Radio given by several listeners. No formal ID has ever been heard. News is typically heard at the top of the hour, and seems to be syndicated news audio provided by “Feature Story News“. I’ve noticed that today, June 6, I am not hearing any news.

The first thing that comes to mind is that this is a pirate radio station. There’s no SWBC stations assigned to these frequencies. While speculation about pirate radio station transmitter locations is often frowned upon by parts of the pirate radio community, propagation (based on who can hear the station at various times of the day) clearly shows that the transmitter site is somewhere in the northeastern USA or southeastern Canada. That is pretty obvious. And the signal levels are typical of what you’d expect from a pirate station running something on the order of 100 watts, give or take a factor or two or three. But the surprising thing is how active the station is, running nearly 24/7. Someone’s not that afraid of enforcement activity by the FCC. Or could it be something else, like a radio contractor doing some testing? It seems unlikely, but then again, we had the famous Yosemite Sam station years ago.

So, if you’ve wanted to hear a pirate radio station, but always seem to miss them, now is your chance. Just tune around 6772 when propagation favors reception in your location from a station somewhere around the northeast USA, and you may indeed hear Old Time Radio, or whoever they are.

June 7 Update:
At 2129 UTC on June 7, 2014, the station went QRT on 6771, then came back on 6976 (a new frequency for it) at 2136 UTC.

DX Toolbox 4.3.0 Released

Version 4.3.0 of DX Toolbox, the radio propagation app for Windows and Mac OS X has been released.

This version adds the Ionosonde Plot Window. This window lets you see graphs of ionosonde data from a number of sites around the world. Select the site from the first popup menu (there are dozens of sites around the world), then select the type of graph from the second. There are three types:

foF2: This is a plot of the highest frequency that will be reflected from the F2 layer of ionosphere when transmitted straight up. As the incident angle is decreased, higher frequencies will be reflected, that is, more distant stations can be heard, or alternatively, more distant locations can receive the signal. This effect explains the “skip zone” around a transmitter site.

foEs: This is a plot of the highest frequency that will be reflected from the E layer of the ionosphere.

hmF2: This is a plot of the height of the F2 layer of the ionosphere. Along with the foF2 value, it can be used to calculate the MUF for a given path.

Here is a screenshot of what the window looks like, click on it to see it full sized:

DX Toolbox also displays a variety of other information, here is the main window of current space weather:

There is also this chart of recent solar and geomagnetic conditions:

Several propagation forecasting tools are also available. This one computes the MUF (maximum usable frequency) and LUF (lowest usable frequency) between two locations, as well as the estimated received signal levels:

You can read more about DX Toolbox here, and see more screenshots here.

Copies of DX Toolbox for both Windows and Mac OS X can be downloaded from the download page.

An version (minus a few features) is also available for the iPhone and iPad.

Winter 2013-2014 Snowfall

With March ending, I’m hoping we’re done with snow. Here are my measured snowfall totals for the season:

Sunday December 8, 2013: 7 inches snow, some freezing rain
Tuesday December 10, 2013: 6.25 inches snow
Saturday December 14, 2013: 2.5 inches snow
Tuesday December 17, 2013: 0.5 inches snow
Thursday December 26, 2013: 0.75 inches snow

December 2013 total: 17.00 inches snow

Thursday January 2, 2014: 6.00 inches snow
Friday January 10, 2014: 0.25 inches snow
Saturday January 18, 2014: 1.00 inches snow
Tuesday January 21, 2014: 8.00 inches snow
Wednesday January 29, 2014: 0.50 inches snow
Friday January 31, 2014 Graupel

January 2014 total: 15.75 inches snow

Monday February 3, 2014: 7.00 inches snow
Wednesday February 5, 2014: Ice Storm : 1/4 – 1/2 inch freezing rain, 1.00 inch snow / sleet
Sunday February 9, 2014: 1.75 inches snow
Thursday February 13, 2014: 16 inches of snow in the morning, 4 inches at night, 20 inches total
Saturday February 15, 2014: 0.5 inches snow
Monday February 17, 2014: 2.0 inches snow
Tuesday February 25, 2014: 0.25 inches snow
Wednesday February 26, 2014: 0.5 inches snow

February 2014 total: 33.00 inches snow

Monday March 3, 2014: 3.0 inches snow
Monday March 17, 2014: 3.75 inches snow
Tuesday March 25, 2014: 1.50 inches snow
Wednesday March 26, 2014: Dusting of snow
Sunday March 30, 2014: 4.0 inches of snow
March 2014 total: 12.25 inches snow

2014-2013 season total: 78.00 inches snow

Looking for some iPad/iPhone apps? Here are a few that I have written: http://www.blackcatsystems.com/iphone/index.html

Pictures of some snowfall events:

January 31, 2014 Graupel:
January 31, 2014 Graupel

February 5, 2014 Ice Storm:
February 5, 2014 Ice Storm
February 5, 2014 Ice Storm

February 13, 2014 Snow storm, pictures taken on the 14th:
February 13, 2014 snowfall
February 13, 2014 snowfall

March 30, 2014 Surprise snow storm

Looking for some iPad/iPhone apps? Here are a few that I have written: http://www.blackcatsystems.com/iphone/index.html

If you think there’s been more pirate activity during the shutdown, you’re right!

Here’s a graph showing the number of unique pirate logging threads on the HFUnderground.com

Each thread represents a different shortwave pirate radio broadcast. The red bars on the right are the number of broadcasts during the shutdown per day. I’ve also drawn in green the average number of broadcasts per day during the month before the shutdown (6.9 per day) as well as during the shutdown (12.2). As you can see, activity is up 77%. This past weekend was extremely active, setting records.

Receiving HF Weather Fax Transmissions On Your iPad, iPhone, iPod Touch or Android Device

It’s markably easy to receive weather fax transmissions without a computer today, you just need an app for your smartphone or tablet, along with an appropriate shortwave radio. This can be extremely handy for mariners who do not have internet access at sea, but want to be able to receive weather charts to keep abreast of storms and other potentially dangerous conditions. It’s also a way for radio hobbyists to decode and view weather fax transmissions without using a computer.

For the iPhone, iPad, and iPod touch, there’s the HF Weather Fax app from Black Cat Systems, available on the iTunes store: https://itunes.apple.com/app/hf-weather-fax/id394199597?mt=8

An Android version is also available on the Google Play store: https://play.google.com/store/apps/details?id=com.blackcatsystems.weatherfax

Under good reception conditions, very high quality weather fax images can be received (click the image to see a full sized version):

A radio capable of receiving the transmissions is also required. Most SSB marine radios should be able to do this, in addition there are many relatively low cost consumer radios that will also work, such as the Sony ICF-SW7600GR .

Next, you need to get the audio from the radio into the tablet or smartphone. While there are some patch cables that will work, weather fax is fortunately a rather forgiving mode to receive, and often just placing the device’s microphone next to the radio’s speaker (or better yet next to some headphones plugged into the radio) often works quite well.

Weather faxes are sent several times a day from dozens of locations around the world. NOAA has their online Worldwide Marine Radiofacsimile Broadcast Schedules listing them by region and country, and is an essential resource. The frequencies listed are carrier frequencies, to tune them in USB mode on your radio, subtract 1.9 kHz. For example, NMF from Boston MA transmits on a carrier frequency of 6340.5 kHz. Your radio should be set to USB mode, and tuned to 6338.6 kHz for proper reception.

Both of these apps will automatically detect the start of fax tone sent at the beginning of an image transmission, to properly align the image. They will also detect the end of fax tone, and use that to save the image, for later viewing. Note that relatively good reception is required for proper detection of the start and stop tones, a weak signal or lots of static or interference (or even audio pickup from the microphone) can cause the tones to be missed.

Here’s a short video made by a user of HF Weather Fax on the iPad:

And here’s a video showing the Android app:

Reducing Local QRM With A Few Ferrite Cores

One downside to an SDR is that you more easily notice the mysterious carriers and other local noise/RFI signals. After reading this article on Common Mode Chokes, I decided to see what I could do to improve my situation.

As a first step, I captured this baseline of the 6500-7000 kHz range, where I am most interested in listening (click to enlarge):

I then added a choke on the antenna input to the SDR, right where it enters the radio. It is 9 turns of the coax on a large toroid core, probably type 37 or 43 material, possibly a Fair-rite 5943003801:

The other coax cable next to the antenna input is the reference signal from the 10 MHz GPS reference. Adding ferrite to it had no effect. I’ll get to the orange toroid next. Here is the result (click to enlarge):

As you can see, there was a significant reduction in the number of carriers and other noise signals.

Next I added the orange toroid also pictured (unfortunately I have no idea what type of ferrite it was, it was from the junkbox), as well as two of the clamp on ferrites you often see on AC power or video cables to the ethernet cable that runs from the SDR to the computer, here are the results: (click to enlarge):

This got rid of a few more. Pretty much, what is left is an actual signal. I was able to identify these:
6604 New York Radio
6519 A voice transmission, perhaps another VOLMET
6660 The second harmonic of CHU 3330
6725 An RTTY transmission
6885 Israel fading in
6970 faded in and out, so it seemed to be a legit DX station

Here’s a slightly later shot of 43 meters (6800-7000kHz):

All in all, a significant improvement, for a few minutes worth of work!

Measuring The Velocity Factor of Coax Using an SDR

Recently I had the need to measure the velocity factor of some coax. The velocity factor of a transmission line is ratio of the actual propagation of radio signals through the cable vs the speed of light in a vacuum.

Here’s the coax in question:

It’s RG-6U, for which I have seen published velocity factors ranging from 0.65 to 0.85, depending on the manufacturer and type of dielectric. This coax was laying in my junk box, and I have no idea who makes it, or what the claimed specifications are. The performance of a lot of lower cost coax often widely varies from published specs, as well.

One technique to measure the velocity factor of a transmission line is to use a piece of it as an open stub, which is a section of transmission line connected to another line via a Tee connector. The added transmission line is open at the other end, hence the term “open” stub. The open stub will act as a notch filter for frequencies with a wavelength close to four times the length, in other words the stub is 1/4 wavelength.

For this measurement, I used an SDR (Software Defined Radio) as the measurement device. In this case an SDR-14. To generate RF I used a noise bridge.

The output of the noise bridge is a good source of wide-band RF.

Here is the Tee. On the left is the RF signal, on the bottom is the connection to the SDR, on the right is the open stub.

With the noise bridge connected, but no stub, here is what the SDR spectrum looks like, click to enlarge:

As you can see it is relatively flat. Next, we’ll connect the 1/4 stub (again, click to enlarge):

You can see the dip in the signal level, caused by the stub.

In this case, the stub was 13 ft (4 meters) of cable. Iif the velocity factor was 1.00 the wavelength would be 16 meters, the frequency 18.75 MHz. The frequency of the center of the notch is 15.7 MHz, so the measured velocity factor is 15.7 / 18.75 = 0.84.

Next I used a 9 ft 3 inch (2.85 meter) cable. The wavelength for a velocity factor of 1.00 would be 11.38 meters, the frequency 26.35 MHz. The frequency of the center of the notch was 21.8 MHz, so the measured velocity factor is 0.83.

Using both cables, the total length is 6.85 meters, the wavelength for a velocity factor of 1.00 would be 27.4 meters, the frequency 10.95 MHz. The frequency of the center of the notch was 9.1 MHz, so the measured velocity factor is 0.83.

For this piece of coax, the velocity factor seems to be 0.83, which is a reasonable value.

6914 kHz Mystery Station

This weekend, I’ve noticed a station transmitting periodically on 6914 kHz. It will come on the air for a few minutes, then go off. All transmissions appear to be AM, with a variety of modes, such as CW (so MCW in this case), RTTY, and even some voice.

Last night I heard transmissions until the last one ended at 0136 UTC, when they stopped until 0745 UTC this morning. None were noted on the SDR recording during that time period.

When the transmissions restarted at 0745 UTC, they were extremely weak.

Here is an RTTY transmission (again, sent in AM mode) using 1000 Hz shift, 45 baud, with a center frequency of 1700 Hz, received at 2345 UTC 1 June 2013:

JAL4-6756 38677 192864 BT


The signal was not the best, so there are some errors in the decoded text. Here is an Audio recording of the transmission.

Here is a CW transmission at 1358 UTC on 2 June 2013:
And the decoded text, thanks to Token for providing it:

Here is a voice transmission at 1431 UTC on 2 June 2013:

Token has reported this station on both 6914 and 23146.5 kHz back in December 2012.

Building the STM32F4 DISCOVERY Toolchain For Mac OS X

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
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:

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!