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:

AGA5D2 DE A39P. FROM XXX DEFPAT ECHO X2 RTB XXXAFTER ACTION K
ART KKDUQLGLZXPQORU TUYI YUUOI PIOIU OUIYY WETYU IYOUI QRWET YTUII IUOPQ WYTUR TIOOQ PPOUY YYIER WEITY URYYU WQPOP TWLA IPQUQ QITWI PUPUQ IYUYR EWPQU TUIOW O
JAL4-6756 38677 192864 BT

A39P DE A5D2. ROGER OUT

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:
AHDR DE A50S COME IN K
A50S DE AHDR RGR GO AHEAD K
AHDR DE A50S CONTINUING ON SECPAT ROUTE. ALL CONDITIONS NORMAL K
A50S DE AHDR RGR COPY ALL K

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

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.