The Squid – A Universal Matching Transformer for Beverage, Longwire, Dipole, Random wire, K9AY, Flag, EWE… and More Antennas

I built my own “universal” matching transformer for connecting dipoles, beverages, loop antennas, etc. to coax cable, rather than having to wind several transformers and test each to see which impedance ratio provided the best match. After some interest from others who wanted one, they’re now available for purchase.

Each contains a tapped transformer, providing many winding ratios, matching a range of impedances. Each tap on the transformer comes out via a color coded wire, making it easy to determine which pair to use. You can also just go through the various combinations, to find best pair to use. The output is a standard SO-239 socket, which you can directly plug coax with a PL-259 connector into. Or you can use an adapter if you have different coax, I tend to use RG-6. That’s a 75 ohm cable, but it’s fine to use here because I can still select a tap that matches the impedance.

For a dipole antenna, one wire goes to each leg of the dipole. For a loop, connect to the two wire ends. For a beverage, one wire to the antenna, the other to the ground rod. And so on. Note that the transformer is only designed for receiving applications, not transmitting.

The transformer has three isolated eyebolts. Two are used for the antenna connections to take the strain off the tap wires (don’t just directly connect to them) and the third to hang the transformer.

Unused taps should be covered with electrical tape, so the wire does not corrode.

More details as well as ordering information on The Squid page.

My Journey Through Hell, Trying to Program an ATTiny85 With an Arduino

I got a few ATTiny85 8 pin microcontroller ICs for a CW Beacon Keyer project I’m working on. You can write code in the Arduino environment for them, and you can program them using an Arduino as the ISP. This all sounded so easy… Famous last words.

I decided to use my Arduino Mega 2560, since that’s what I had available, the Arduino Uno was otherwise occupied. I did a quick websearch for instructions on programming using that Arduino, rather than the Uno, which is more often used. I ran across quite a few hits for people having problems getting it to work, which should have been my first clue that I was headed down the wrong path. The wiring is a bit different using the Mega, as far as which pins are used for ISP. And there were frequent mentions of needing a 47 uF cap on the reset line. Very dodgy.

I gave it a try, and of course it didn’t work. So I kept fiddling. You can make changes to the ISP sketch, to tell it to use the normal (Uno) pins for ISP. Tried, that, didn’t work. It was also a little unclear where to connect this magical 47 uF cap. I first though on the reset line of the Tiny85, which didn’t work. Then I realized no, it goes on the Arduino’s reset line, to stop it from going into reset mode prematurely. Still didn’t work. Spent much of an afternoon on it, without any luck. I read numerous posts about what worked for various people to ISP using a Mega, or what didn’t. I finally set aside for the day.

The next morning, I decided to try using the Arduino Uno. I connected up the ATTiny85, and it programmed the Blink sketch the first time I tried. Easy. Took all of 5 minutes. I wish I had tried the Uno first.

While it may indeed be possible to program an ATTiny using an Arduino Mega, I could not get it to work, and numerous other web pages related similar tales of woe from others.

Getting a cheap Chinese clone Arduino board to work on the Mac

I picked up a cheap Arduino Uno clone board off eBay, for some projects I am working on (to be featured here, once I have a bit more to show).

There’s lots of these on eBay, this particular one is listed as “Hotsell UNO R3 ATmega328P Development Board With Boot Loader For Arduino UNO BG”, it was $3.45 shipped, not a bad price. I see that since my purchase, the seller has raised the price to $4.76.

It arrived fairly quickly, about 3 weeks, typical for stuff from China. I plugged it in, fired up the Arduino IDE and… nothing. Didn’t show up. Checked the list of USB devices via System Information, and it did appear, with vendor ID 0x1a86 and product ID 0×7523.

Some web searches showed up lots of hits for this, particularly dealing with cheap Chinese Arduino boards. Apparently they use a CH34x chipset based USB interface chip, which your computer often does not have drivers for. Some more searching turn up this page: https://0xcf.com/2015/03/13/chinese-arduinos-with-ch340-ch341-serial-usb-chip-on-os-x-yosemite/

With a download link for a Mac OS X driver: https://0xcf.com/download/ch341ser-mac/?wpdmdl=122

They have Windows drivers as well.

I ran the driver installer and… nothing. Still does not show up in the Arduino IDE, nor in the list of devices. I poked around a bit, and noticed the installer put the kext into /Library/Extensions/ and not /System/Library/Extensions which I know can sometimes cause problems. So I moved it to /System/Library/Extensions via:

sudo cp -R /Library/Extensions/usbserial.kext /System/Library/Extensions/usbserial.kext

And sure enough it now appears in /dev:
/dev/cu.wchusbserial14364440

And appears in the Arduino IDE, and works fine. Success!

More adventures in filtering the power supply for an AFE-822 SDR

I frequency monitor and record the 285-325 kHz DGPS band, looking for DX beacons. Recently, I noticed a noise source centered around 315 kHz, almost 10 kHz wide, on my AFE 822 SDR with a 500 ft beverage antenna:

I tried hunting around the house with a portable radio, looking for it, but could never find it. I then checked on my netSDR, with a 670 ft sky loop antenna, and it was not visible there. Very curious. I then tried the beverage antenna, and could still not observe it. But it was there with the AFE822, with either antenna. This made me suspect noise was entering the AFE-822 through the power supply. I was use the USB input for power, and previously wrote about my attempts to reduce the noise from the power supply. This noise source was new since then, possible due to something else added to the shack.

I decided to put together a filtered DC power supply, using linear wall transformer, and adding filtering via capacitors and an inductor.

The circuit itself is fairly simple:

The output of the transformer I used is about 10 volts under load. I chose a 5 ohm power resistor to place in series, which dropped 2.5 volts, so the resulting DC power supplied to the AFE 822 is 7.5 volts. The value of this resistor depends on the output voltage from the DC supply. The AFE-822 draws 0.5 amps, Ohms Law can be used to calculate the desired resistance. The AFE822 has a voltage regulator inside it (it appears to be an LM7805 variant, possibly low drop out), so it can tolerate a wide range, the AFE 822 website specifies 7 to 10 volts.

The inductor is from the junk box, I don’t know what the value is. While I’m telling myself it helps to filter, I might try to find a known, larger value. The 1000 uF electrolytic capacitors provide low frequency filtering, the 0.047 uF ceramic caps provide RF filtering.

The filter circuit was constructed dead bug style on the lid of a small metal can:

Here it is mounted on the can:

And now the spectrum, with the new power supply. Certainly an improvement:

A Low Pass Filter For Longwave

Recently, I have been DXing DGPS (Differential GPS) stations on the longwave band. They occupy the region from 285 to 325 kHz. I’ve been getting some pretty good results with some custom software I wrote that demodulates all of the DGPS channels (1 kHz apart) in parallel from I/Q recording files from my SDR. This lets me analyze the entire band from a set of overnight recordings. That itself is the subject of another post I am working on.

I decided to build a low pass filter that just passes the longwave band, attenuating medium wave and shortwave, in an attempt to improve reception of weak DGPS signals.

The filter is flat to about 400 kHz, then starts attenuating. It is down about 30 dB at the start of the MW band (530 kHz) and reaches about 45 dB by 700 kHz, then eventually reaches about 50 dB. My strongest local MW stations are on 1280 and 1320 kHz, so I felt this was sufficient. I did not want to attenuate signals on the longwave band itself.

Below is a schematic of the filter. I used what components I had on hand, hence the paralleling of some of the inductors and capacitors. (Click on any of the images to enlarge them to full size)

I previously wrote about Building an RF Noise Generator For Testing Filters and included some plots showing the noise spectrum taken with an AFE822x SDR running the SdrDx software. Below is a plot of the noise generator fed directly into the SDR over the range of 100 to 1700 kHz.

Next is the spectrum with the filter installed. You can see the dramatic attenuation starting above about 400 kHz. (You can see an RFI noise source around 1300 kHz from elsewhere in my lab, which I have not yet tracked down)

Below you can see the entire MW and LW bands, this is without the filter and using my 500 ft beverage antenna:

Next, with the filter installed. Most of MW is knocked out, except for a few locals and stations on the lower end of the band. 580 is WHP in Harrisburg PA with 50 kW. A few more stages on the filter might be able to attenuate that some more, but I’m pretty happy with things already.

Below is an image of the filter itself, mounted in an aluminum enclosure:

And all bundled up, ready for use:

Building an RF Noise Generator For Testing Filters

It’s often handy to have an RF noise generator when testing various circuits, especially filters. I was working on a low pass filter for long wave, and wanted a way to measure the performance of the filter.

This is the noise generator I came up with. It’s a fairly simple circuit:

A zener diode as the noise source. Zener diodes, when conducting a very low current, produce a wide spectrum of noise. In this case I used a 6.8 volt zener diode, similar values should work as well.
A single NPN transistor used to amplify the noise form the zener diode.
A variable resistor to adjust the current through the zener diode for maximum noise.
Three resistors, four capacitors, and an inductor (to filter out noise you don’t want, from the power supply).

In my case, I powered the generator from a 12 volt DC power supply, you could use a 9 volt battery as well, if you wish.

Below is the schematic (you can click on any of the images to see them full sized):

The incoming DC power is filtered by the inductor and two capacitors.

Next it goes through the variable resistor as well as a fixed 10K resistor, so that the maximum current through the zener diode is limited to a safe value during adjustment. The noisy zener diode current is then applied to the base of the transistor, used as a common emitter amplifier. I used a 2N3904, other values should work as well, though you may need to adjust resistor component values. The 0.1 uF capacitor keeps the voltage on the zener diode relative constant.

The 680 and 1000 ohm resistors in parallel are values I had in my parts bin, suitable to use in parallel based on the current to the base of the transistor. The transistor output is the AC coupled through another 0.1 uF capacitor.

Below is a photograph of the circuit, build on the lid of a 1 pint paint can. I have a number of these from geiger tubes that I purchase for use in radiation detectors that you can plug into your computer for experiments as well as long term measurements and graphing. Hey, want to buy one of my geiger counters? Full details are here: http://www.blackcatsystems.com/GM/GeigerCounters.html

OK, back to the noise generator. The paint can lids are handy for prototyping RF circuits. You can built them dead bug style on the bottom side of the lid, test them out, then put them on the can for your RF shield, as shown below. The two connectors are a BNC jack for the RF output, as well as a standard DC power jack for the power supply.

For looking at the generated noise spectrum, I used the fabulous SdrDx SDR software by Ben, AA7AS, along with an AFE822x SDR.

Below is the noise level with the RF noise generator powered off (you can see an RFI noise source around 1300 kHz from elsewhere in my lab, which I have not yet tracked down):

And with it powered on:

The increase in noise level is about 50 dB, very suitable for testing filters and such.

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.

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!

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

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