All-Mode VHF/UHF Reception with a Low-Cost TV Dongle

Balint Seeber’s new software supports not only the USRP, but also a range of low-cost USB dongles designed for receiving DVB-T television signals. When I read about this, I felt that I can’t not try one, so I ordered an ezcap dongle for $20 from a Chinese seller on eBay. It arrived a couple of days ago, and my experience so far is very positive.

The dongle I ordered was listed as an ezcap dongle, which is one of the models supported by Balint’s software. The dongle that arrived is exactly the one that was shown in the picture on eBay; inside, it was labeled as EzTV666. It came with a 15cm whip antenna, so I plugged in the antenna, plugged in the dongle, configured the driver using Zadig, and started up HDSDR. Balint’s library for the USRP and the TV dongles was already installed, so all I had to do is tell the software that I wanted to use a TV dongle and it worked without a problem. I didn’t have to install any new software.

I was immediately able to receive some local narrow-band FM traffic. I ran the dongle with a bandwidth of 1.6 MHz, so you can see a nice piece of spectrum on the screen at once. It goes up to 3.2 MHz, but Balint warns that high bandwidths cause some signal degradation. In the screenshot below you can see shorts bursts from a hand-held trancseiver at the input frequency of a local repeater and the repeater’s output 600 kHz higher. The repeater output bursts are longer because the repeater controller adds a “tail” to each transmission. It’s pretty neat to see both the input and the output of a repeater at the same time. The dongle’s frequency is a bit off, so the displayed frequency is incorrect (about 10 kHz too high), but this is easy to correct in HDSDR (Options -> ExtIO Frequency Options).

I installed the software that came with the dongle on another computer. Reception of local broadcast FM stations was good, but I was not able to receive DVB-T television signals, even with the bundled whip antenna outside the window.

Clearly, I needed better antennas if I was to receive more interesting stuff. To use better antennas, I needed some way of connecting them to the dongle. From the picture on eBay it was not easy to determine the type of RF connector used on the dongle; it did not seem to be the IEC 169-2 connector that is used in some of the other SDR-capable DVB-T dongles, but I didn’t know what it was. When the dongle arrived, I realized that the connector is an MCX connector. I didn’t have any cables with MCX connectors or any MCX adapters, so my initial thought was to cut the cable from the rather useless whip and terminate it with a BNC, but before I did that a friend gave me an MCX-to-N patch cable that he bought at a surplus store. That was good enough to connect any of my existing antennas, so I continued the experiments.

I first tried a 145 MHz dipole (1m end to end). It improved the reception of local UHF and VHF narrow-band FM dramatically, and it also worked very well for DVB-T (which is at 514 MHz here); I was able to watch TV on the computer. It also worked reasonably well for air-band signals. The next stage was to try to receive satellite signals. I experimented previously with a borrowed FUNcube dongle and I new that the FUNcube was very capable of receiving satellite signals. The FUNcube dongle uses the same tuner chip as the ezcap (an Elonics E4000, but its analog-to-digital converter is higher resolution than the ezcap’s; the FUNcube also has a low-noise preamplifier ahead of the tuner, and I am not sure if the ezcap uses one (if somebody knows, let me know).

A satellite called VO-52 was supposed to fly over last night, so I turned my cheap Yagi towards it and listened. Initially, I attached a preamplifier between the antenna and the dongle, but I later discovered that it did not make a huge difference. VO-52 has both a Morse beacon and a linear transponder. The beacon came through very clearly. In the screenshot on the right you can see the beacon’s signal move down in the audio passband due to Doppler shift. It it well above the noise and easy to hear. Next, I checked whether I can receive SSB signals in the transponder’s passband; I could. Here is a short recording of one Greek station (the Doppler shift causes the speaker’s voice to become lower over time).

While I was listening to VO-52, the local FM repeater sprang into activity. It is only about 100kHz away from the satellite’s signal; when the repeater was transmitting, it was causing pretty severe distortion of everything else the dongle was receiving. The satellite still came though, but not as well. You can see the effect in the screenshot on the right. I discovered that this was caused by too much gain in the preamplifier+dongle chain. There are two ways to solve this: to not use a preamplifier, or to drastically lower the gain of the dongle (you can set the gain with a slider).

The main benefit of the preamplifier in my setup is that it includes a good bandpass filter. Without the preamplifier, strong-out-of band signals sometimes overwhelm the dongle. With it, reception is much more consistent. But the dongle does work reasonably well even without anything between it and the antenna.

Another interesting thing that you can see in the last screenshot is the strong CTCSS tone coming out of the repeater, at 91.5 Hz. It is clearly visible in both the audio spectrum display and in the audio waterfall.

Using a Motorola PageTrac and a VHF Antenna Tuner in an APRS iGate

My APRS iGate has been using the old Kenwood TR-2500 that you see in the picture for a few months. The radio was connected to an old commertial VHF antenna. This antenna is not resonant on 144.800MHz, but it is sturdy and high, and it receives very well. So I used it in receive-only mode; the iGate relays APRS messages from RF to the internet, but not the other way around. But when I got two old Motorola VHF radios, I decided to replace the TR-2500 by one of them, a Motorola PageTrac. This was supposed to bring two advantages. First, the Motorola radio would start up on 144.800 after a power loss, whereas the TR-2500 had to be programmed manually for 144.800 after a power loss because its memory battery has long died. Second, the PageTrac puts out 45W whereas the TR-2500 puts out only 2.5W, so if I start transmitting messages, the PageTrac would have a much better range.

The plan proved more difficult to execute than I had thought.

A Matching Network

The existing antenna is sturdy, high, and mounted on an old mast that I had no desire to climb. So I decided to keep using it. To transmit using this antenna, I needed a matching network: a single-purpose antenna tuner. I borrowed an MFJ-269 antenna analyzer from Nir Israeli and measured the impedance of the antenna and coax at the radio-side connector (at 144.800 MHz). I then designed an L match circuit using an online calculator.

I didn’t completely trust the analyzer and I was not sure that the air inductor I prepared had the correct inductance. So I used a variable capacitor in the L match, so that I could tune it. This worked out well. By adjusting the variable capacitor I was able to bring the SWR to a low value that is good enough for transmitting (I think it was 1.2:1 but I didn’t record it). The L match is narrow band and the SWR is reasonable only across about 0.5 MHz, but this is of no significance for APRS, which uses a single frequency.

The online calculator gave me not one appropriate L match but two. The other solution had a tiny series inductance and a capacitor across the transmission line. I tried it (with no inductance at all) and could not get the antenna to match. I am not sure why this matching network did not work.

Antenna tuners of this sort are almost never used at VHF, because it is pretty easy to build resonant antennas. But in my situation, with a good antenna that works well even though it is not resonant, this special-purpose antenna tuner is a good solution.

Power Supply Troubles

The two Motorola radios I got are a DeskTrac, which is a desktop version of the more common mobile MaxTrac, and a PageTrac. The DeskTrac is documented very well on the web. I didn’t find any useful documentation on the PageTrac, but it is a very simple radio, so I didn’t really need much documentation. Both radios worked when I got them, but I quickly discovered that the power supply of the PageTrac was failing. Two large electrolytic capacitors were burned, and they actually charred the PCB beneath them. They were buzzing and burning when the radio was turned on. I tried to replace them, but I didn’t find replacement 15,000μF capacitors. I decided to replace the entire power supply. It was rated at 13.8V and 10A, so I needed a power supply with similar specs.

The first candidate was a power supply from a dead computer. Its 12V output was rated at 16A, so I thought it would work. I spent a bit of effort trying to raise the output from 12V to 13.8V, but this caused buzzing in the PC power supply, so I left it alone. I assumed that running the radio at 12V rather than 13.8V would reduce output a bit, but this was acceptable to me.

The radio worked with the computer power supply, but whenever I tried to transmit, the power supply shut down. I am not sure why it shuts down, but my guess is that the roughly 10A that the radio draws from the supply on transmit causes the switching regulator in the supply to generate wider pulses. This maintains regulation on the 12V line, but it raises all the other outputs that have almost no load on them (5V, 3.3V, etc.; all are generated from the same switching waveform). The over-voltage protection circuit of one of these outputs might be what is shutting down the supply.

Next, I tried an old 12V/11A Lambda switching supply that I thought at a surplus store for about $5. I adjusted it to 13.8V. It works without a problem, and it is small enough to fit inside the PageTrac enclosure. It just sits in the enclosure without being bolted to it, but since the radio just sits on a shelf, this does not cause problems.

The Computer Interface

To use the radio as an APRS iGate, I needed to connect it to the soundcard of the computer running the iGate software. The interface that I used with the TR-2500 was not really an interface at all: just a cable connecting the TR-2500′s earphone output to the computer’s microphone input. But with the PageTrac, I needed some kind of interface, if only to activate the transmitter. I built a simple interface with (1) DC blocking and level adjustment on both the audio input and audio output directions, and (2) a PTT activation circuit. The PTT circuit is activated by the RTS signal of a serial port, and is isolated from the radio by an optocoupler. But the audio lines are not isolated, so the radio and computer are not really isolated. So far this did not cause any problems.

Initially, the interface did not work. When I would connect it, the radio would go into transmit mode, even if only audio cables were connected, not a serial cable. It took me a long time to debug, but eventually I discovered that I made a mistake in the wiring of the cable connecting the interface to the radio’s front speaker-mic connector. Once I fixed the mistake, the interface started working.

Limitations of the PageTrac

The PageTrac has some limitations. One is the fact that the only audio/PTT connector available is the RJ45 speaker-mic connector on the front. It has an RJ11 connector in the back, but it is undocumented. In contrast, the backThe DeskTrac has a DB-25 jack on the back designed for connecting it for to computers and other equipment. The second is that it has no “monitor” button to turn off the squelch. APRS works a bit better without a squelch, and the DeskTrac has a button that allows you to turn it off. I also think that unsquelched audio is available from the DeskTrac’s DB-25 connector. But even through the squelched speaker-mic connection, the PageTrac works fine. Another limitation of both radios is that the speaker is never completely muted (even at the lowest volume level). To prevent the radio from sounding the APRS packets, I simply disconnected one of the speaker’s wire.

Software Modem Issues

Soundmodem, the soundcard-modem that I have been using with the TR-2500, did not decode packets received by the PageTrac. I thought of adding a high-pass filter to the audio interface, to compensate for a possibly too-aggressive de-emphasis, but eventually wrote a new software modem that decodes packets from both radios without a problem. But this is a topic for another post.

After resolving all of these issues, the new iGate configuration is up and running. The iGate beacons on both the internet and on 144.800 MHz, and it relays text messages and other packets from the internet to mobile stations. In the screenshot below you can see me exchanging text messages with a mobile station (which uses a Kenwood D700). You can see both stations on the map, the text-message window of APRSIS32, and the actual packets that are received and transmitted by the iGate, some via RF and others via the internet.

A Lego Enclosure for an APRS Tracker with a Built-In Antenna

My APRS tracker seems to work quite well, but it was difficult to use with various pieces of equipment sloshing about on the dashboard. Initially, I’ve been using the short vertical antenna that came with the UV-3R radio. Both the radio/antenna and the GPS antenna were placed on the dashboard. This antenna did not work well inside the car, especially when it was lying horizontally with the radio on the dashboard. Then I switched to the small PCB magnetic loop antenna I built a while ago. This worked much better, especially when the antenna was standing up. But now I had three pieces of equipment (the radio, the loop antenna, and the GPS antenna) sloshing on the dashboard. This was only good enough for a bit of testing.

I was considering how to mount the antenna and the radio more securely on the dashboard. I didn’t feel like spending a lot of effort on building an enclosure. Then the idea of building the enclosure, or at least a prototype, from Lego. The box you see in the picture above is the result. It actually works very well. It’s a bit heavy, so it doesn’t move at all on the dashboard. It contains the antenna, the radio, and the GPS antenna. There are holes in the box for the audio cable to the microcontroller, for the GPS antenna cable, and for the display and buttons of the radio. Being able to turn the radio on and off is important, since it runs on its internal battery. The hole on the side is also large enough for the radio’s charging cable. The antenna and radio slide into specially-built compartments that hold them securely. It’s also easy to slide them out. Both antennas work well inside the plastic box on the dashboard (Lego bricks are usually made of ABS plastic). The box has enough space for a small microcontroller board and for a GPS module, but my current microcontroller board is a large development board, so for now it and the GPS module still lives in a cardboard box that I stick in the glove compartment.

As you can see in the snapshot from aprs.fi below, this Lego tracker actually works, even though it’s inside the car and even tough the UV-3R puts out only 2 Watts. Still, I plan to deploy a 1/4-wave vertical antenna on the car’s roof for even better coverage, and I’ll probably replace the Lego with some other box, mostly to avoid having the Lego bricks ruined by exposure to sunlight. But for now, I’m using the Lego tracker. It’s also very good to know that the 10cm magnetic loop antenna works well in APRS trackers; such antennas can be used in small trackers that are completely self contained.

Two more comments are in order. First, driving with a heavy tracker on the dashboard is possibly unsafe, since in an accident it might hit the driver or a passenger. I’m mostly using it around the neighborhood, but once I switch to the vertical antenna on the roof, I’ll move the whole thing off the dashboard. The other thing I wanted to mention is that I performed the two almost-necessary modifications of the UV-3R radio. One adds a capacitor to the VHF low-pass filter, to attenuate the second harmonic, and another adds a decoupling capacitor to the external transmit-receive control signal; without it, the radio often locks in transmit mode when used with a headset or an external modem.

Building an APRS Tracker

I’ve been running an APRS RF-to-internet gateway for a few months now. It uses javAPRSSrvr as the gateway program and soundmodem as a soundcard modem, both running on a remote Linux machine. Both programs are very reliable, running for months without a fault. I spent a bit of time trying to get the two programs to communicate over a virtual serial port, but this did not work, so I eventually switched to AX25 kernel-mode support, which worked out of the box on Ubuntu Linux.

I want to track myself using APRS, so I needed a tracker.There are several published hardware and software designs on the Internet, and I originally considered building a tracker based on one of these designs. But I eventually decided to build a tracker that is not based directly on any existing design. Mostly, I wanted to end up with a high-quality and flexible code that could be easily ported to different hardware platforms and to different uses. I’m not yet there, but I’ve got a working prototype that’s running my own code.

One thing I knew I wanted to do was to avoid a modem chip. Some APRS trackers and digipeaters use a modem chip, normally the mx614. A modem microcontroller would be able to produce and decode a 1200b/s AX25 signal in software. There are several trackers that do that already, like Gary Dion’s WhereAVR and Byonics‘ TinyTrak3 and TinyTrak4.

The prototype is running on an microcontroller development board that I use at work for teaching a course on embedded computing. It has an LPC2148 microcontroller, which has an ARM processor, and lots of on-board peripherals. The tracker currently uses almost none of the on-board peripherals except for the LCD screen. The board is connected to a GPS module and to a VHF radio. The GPS is a NEO-5Q module from ublox; it’s mounted on a board that also has a microcontroller and a bunch of other components (a prototype from an old wifi-based tracker project I participated in), but I’m only powering and using the GPS module on this board. The GPS is connected to an external active patch antenna. The radio I’m using is a Baofeng UV-3R, which I bought mainly for this purpose. It cost less than $50 including shipping, considerably cheaper than some dedicated VHF tracker transmitters. The radio is connected to the microcontroller through a little interface board that I built. Both this interface board and the GPS module are currently stuck into a breadboard, with wires connecting the microcontroller board to the breadboard.

The interface board performs 3 functions. It connects the DAC output of the microcontroller to the microphone input of the radio. This signal is routed through a trimmer resistor, to adjust modulation in the radio (it needs a much smaller amplitude than the DAC produces), and though a DC blocking capacitor. The board also routes the audio output of the radio to an ADC pin of the microcontroller, but I haven’t tested this yet. Finally, an open-collector NPN transistor switches the radio to transmit. I had some trouble with this transmit-receive switch: RF would get into the circuit and would keep the radio transmitting long after the microcontroller tried to turn the transistor off. I solved this with two 0.01μF decoupling capacitors on both the base and the collector of the switching transistor.

I used my own software drivers for the microcontroller (for it’s UARTs, DAC, etc.), but I used code from other APRS open-source projects for building up packets and for producing the audio output of the modem. I will release the software once it is more or less stable. I used three codes: Tracker2′s code by Scott Miller of Argent Data, the AX25 code in BeRTOS (a real-time operating system), and soundmodem. I have a lot of positive experience with soundmodem running on the Linux box, so hopefully it will work well on an embedded system. Fortunately, it uses fixed-point arithmetic, rather than floating point which is not supported in hardware on small microcontrollers, so it should work. But I have not tested the demodulator yet. The parts of soundmodem that I’m already using required quite a bit of hacking, unfortunately. I initially tried to keep the modem code as is, but I gave up after a while; the over structure does not work too well in an embedded setting.

I’ve been working on the tracker for a few days, and yesterday it got to the point where it was working on the bench: parsing GPS data, producing packets, and sending them to the radio. The packets were well-formed and my gateway decoded them (actually just some of them;  I’m not sure if the 2W signal from the radio was too weak, or the transmitted audio is not good for some reason). It was time to take the tracker for a ride. I took it to the car and hooked it to the cigarette-ligher’s socket. The LPC2148 board can be powered by up to 15V, and it can produces enough 3.3V power for the GPS, so I assumed everything would work. It did for a while (you can see some position spots in the aprs.fi map on the right), but after a few minutes the tracker started rebooting itself every second or so. I touched the regulators on the board and they were pretty warm, so I’m assuming that one of them overheated, shut down, and caused the system to reset. I guess I can’t power this unit directly from the car’s battery; I’ll need to drop the voltage with an off-board regulator first.

Next, I’m going to work on the AX25 demodulator, hopefully producing a tracker that can also decode packets.

Two Monoband Magnetic Loop Antennas

I recently built two more magnetic loop antennas, both for single bands. I built the first one mostly in order to find a good use for a piece of Heliax (coax with a solid copper shield) that I found discarded. Copper tubing is an excellent material for small loop antennas, so building a loop seemed like a good idea. The Heliax was only 1.60m long, so it only made sense to build a loop for one of the higher HF bands. The main difficulty in building a small loop is to find a suitable capacitor to resonate the loop. I decided to try to build the loop using two capacitors in parallel: a piece of coax that will form a high-voltage fixed capacitor and a small butterfly air-variable capacitor that I had. The butterfly capacitor had too little capacitance to resonate the loop alone. The coax would serve as a fixed capacitor, but I would be able to easily rough-tune it to the band by trimming it.

I decided to build the loop for the 21MHz band, because when I built it a couple of months ago, the higher bands were not open for significant periods of time (this changed later and I re-tuned the loop for the 28-29Mhz band). I soldered the ends of the Heliax to the butterfly capacitor and to a piece of RG-58 coax. This was not easy; I did not have a high-power soldering iron, and the excellent heat conduction of the Heliax’s shield made it difficult to heat it up enough to solder. I eventually managed to solder the capacitor, coax, and Heliax using short pieces of house wiring. It’s not pretty but it worked.

I trimmed the coax capacitor to the correct length using a borrowed antenna analyzer. I tuned earlier loops without one; it’s definitely easier with an analyzer. The coupling loop is the one I use with the coax loop. It’s larger than 1/5 the diameter of the Heliax loop, but it still resulted in impedance close to 50Ω. I set the air variable capacitor to maximum capacitance and trimmed the coax until the antenna resonated just below 21.000MHz. I could now resonate the antenna anywhere on the 21MHz band by tweaking the air variable. I made several contacts on 21MHz with the loop, but after a few days I re-trimmed the coax capacitor all the way to the 28MHz band, which was more active.

The loop with the RG-213 coax capacitor

I noticed something strange in JT65, a mode that transmits for 50s at a time. I would tune the antenna low SWR and transmit. At 10W or below, everything was fine. But at 20W and up, the SWR would rise from near perfect to horrible after a few seconds of transmission. The rise in SWR was rapid but not sudden; it would take several seconds. This was very consistent and it happened on both 21MHz and 28MHz. I realized that the power was doing something bad to the antenna, so I went out to check. There was a slight odor, and the end of the coax stub was burned (and warm). The high voltage across the capacitor was causing current to leak between the inner and outer conductors of the RG-58 coax, and that current was heating up the coax, burning it, and changing its capacitance (which is what caused the antenna to de-tune and the SWR to rise). I replaced the RG-58 with a much more robust RG-213. I tuned it to the band but kept the inner conductor longer by about 1cm than the outer shield, to separate the two conductors even more. The antenna can now withstand high power. I made many contacts with it.

I hoped that the antenna would be better than my coax loop, which is made with LMR-400 coax and N-type connectors, thanks to the solid-copper outer conductor and thanks to the soldered connections between the loop and the tuning capacitor. But on the air, there didn’t seem to be a significant difference between the two. The coax loop is a little larger (80cm diameter vs. 52cm), so maybe that compensates for its disadvantages. The coax loop is more flexible, since with a large air variable and a vernier dial I can tune it all the way from 7MHz to 29MHz, so I don’t use new Heliax loop much any more.

It was still fun to see that I can have reliable SSB and FM contacts (not to mention PSK31 and JT65) using such a small antenna.

An Update: I’ve finally soldered the Heliax directly to the tuning capacitor. I did well with this antenna during a recent contest, in which I made quite a few SSB contacts including to Australia, China, Japan, and quite a few other countries. I’m pretty happy with the antenna now.

The second small loop I built is a PCB loop for 144MHz. I envisioned it as a way to build APRS trackers that are really small: that is, have a small antenna, perhaps in the same plastic enclosure containing the transmitter and the GPS receiver and antenna. Furthermore, if an effective VHF loop can be built on a PCB, the antenna could be etched by a commercial PCB manufacturer, making is relatively easy to duplicate. PCB antennas are very common on UHF. They are also common in RFID tags, some of which work at 13.56MHz (where they are very inefficient but still good enough for RFID). For APRS, the antenna can be fixed-tuned to 144.800MHz, so the tuning capacitor can be fixed rather than variable.

I designed the loop to be a square with beveled edges. The square is 10cm-by-10cm, and the copper loop is 1.5cm wide, to make losses low. I am not actually sure that making the PCB conductor so wide would actually keep losses low, but it seems like a reasonable bet (if somebody can run simulations to determine this, I would be happy to read the results). I was hoping to tune the loop to resonance using a sliding capacitor that I would form from the two open ends of the loop itself and another piece of PCB material sitting on top of it, separated by either a small air gap or some polyethylene. I ended up, however, using a coax-stub capacitor, which you can see in the picture. I also used a gamma match to feed the loop, rather than a coupling loop.

The small piece of PCB was designed to form a tuning capacitor with the ends of the loop, when mouned on top of it

I had a lot of trouble tuning this loop. I started by installing the PCB air capacitor, which I fixed to the loop using nylon screws. My intention was to make slots in the PCB material that would allow me to slide the small piece of PCB up and down to change the capacitance, but initially I used simple holes that fixed the capacitor at maximum capacitance. I connected the loop to an antenna analyzer and tried to find the resonance point. I could not find any resonance point. I moved the gamma match up and down and tried again and again. I replaced the gamma match by a coupling loop. No resonance. I abandoned the project for a few days.

Prototyping the loop took quite a bit of work, to cut the PCB and to file away some of the copper using hand tools, so not being able to get it to work was frustrating. After a few days, I decided to use methods that worked for me on lower bands and to try again. I took apart the hand-made air variable capacitor and soldered a short RG-58 coax stub to the loop. And instead of the antenna analyzer, I used a receiver (in SSB mode) to search for a peak in the noise. I was able to find a weak peak below 144Mhz. I repeatedly shortened the stub and searched for the peak, which slowly rose toward 144MHz. Once it was near, I was able to transmit and to trim the coax to low SWR. The antenna is now tuned to 144.800MHz and gives acceptable SWR over a range of about 0.5Mhz.

The back of the loop, showing the SMA connector

I did some non-scientific comparisons of the loop and a short flexible handy-talkie whip, the 15cm-long Diamond SRH-815. There didn’t seem to be a lot of difference between the two antennas, which was a bit disappointing. So either I didn’t do the comparison properly (entirely possible), or this loop is not much more efficient than a short whip. For most uses a short whip is more practical, so right now I can’t really think of a good reason to use a small PCB loop on VHF. But I’m still happy I was able to get the antenna to work.

HF Email using Winlink 2000

So far I’ve used three digital modes on the HF bands: PSK (mostly PSK31), WSPR, and JT65A. PSK is fun, in that you see signal phenomena in real time, and you see them both visually and in the ability or inability to decode the signal. If the signal fades, you see it fade; if two stations transmit on the same frequency, you can see that too. It allows you to chat with other stations and write whatever you want. But because PSK31 does not have any error correction or automatic acknowledgements, you sometimes receive only part of a transmission. To me, this feels low-tech. I expect digital transmissions to be almost perfect when communication is possible. PSK31 is not.

WSPR and JT65A incorporate strong error correcting codes, so transmissions are usually error free (not always, but almost). But neither of these is good at actually sending information. In WSPR the only information transmitted is station identification and location; you can’t say anything other than who and where you are. JT65A allows you to send a bit of free text, but it’s cumbersome; mostly, it’s also just for establishing the ability to communicate, not for actually communicating information.

Yesterday I finally succeeded in using another digital mode called WINMOR, which really feels like high-tech on HF. WINMOR is part of Winlink 2000, a system that is mostly designed to send and receive regular internet email through HF, VHF, and UHF radios.  It is used by radio amateurs, emergency organizations, and NGOs to communicate by email from places that do not have internet connections (like yachts, jungles, etc.). Winlink initially used an HF digital mode called PACTOR, which is very adaptive and efficient. PACTOR requires a dedicated hardware modem; the protocol is proprietary and the modems are expensive. A couple years ago Rick Muething designed WINMOR, an HF sound-card protocol for Winlink 2000 (on VHF and UHF Winlink uses AX25). I downloaded the software a while back but didn’t manage to connect to an HF radio gateway, and forgot about it.

Yesterday I decided to give it another try. The software uses a propagation prediction program and a list of active gateways to suggest gateways that are likely reachable. I tried to connect to the one that was supposed to be best, in southern Russia (on 14MHz). I heard the gateway respond and got a message that I was connected, but when the software tried to deliver an email message I sent, the gateway failed to respond and the connection was broken. I tried a few times and gave up. I also tried gateways in the Netherlands and Germany, but they did not even respond to me. In the afternoon conditions on 14MHz seemed to have improved, so I tried again. It worked! I received the mail I sent myself via HF! I replied and connected again to the radio gateway, and the response was delivered to me over the radio. Very cool.

I was later able to also connect to the radio gateway in the Netherlands, and to upload position reports to Winlink 2000, not just email. The Winlink web site shows the position of all the stations that uploaded position reports recently, and you can also view all the recent positions of particular stations. It’s quite interesting; many stations upload position reports from the middle of the ocean, as you can see here.

Winlink and WINMOR are really interesting. They deliver a useful service. Most of the time, sending email via WiFi, cellular, or wired networks makes much more sense than sending email over HF or VHF radios. But in emergencies and when you’re in the middle of the ocean, Winlink is a really useful service.  The protocol is very sophisticated, but you can sort of see some of what it is doing. You hear and see acknowledgements, retransmissions, and other protocol actions. But the biggest difference between WINMOR and many other HF digital modes is that it is an all-or-nothing protocol; it either delivers the data perfectly with no errors, or it fails completely. You don’t get garbled text. This is how modern communication works.

It’s not easy to set up radio gateways; the Winlink 2000 folks want gateways to run continuously (24 hours a day, every day), so setting up a gateway is not something to just experiment with, like I did with WSPR and APRS.

But WINMOR also has a peer-to-peer mode that allows you to communicate outside the Winlink system; perhaps I’ll try that.

First Steps with GNU Radio

GNU Radio is a package of DSP building blocks for constructing software radios. It is also the support software for a range of radio front ends from Ettus Research. You can also use GNU Radio with other radio front ends; I was able to easily use it with a Softrock receiver.

These radio front ends are a modular system containing motherboards and daughter boards. The motherboards have high speed ADCs, high speed DACs, and an FPGA for high-speed DSP. In most cases the FPGA does relatively little (but at high sample rates): decimation and digital down conversion on receive, and digital up conversion and interpolation on transmit. The rest of the signal processing is done in software on a PC (some motherboards have an embedded PC running Linux). The daughter boards typically contain transceivers or receivers that move the baseband signals produces or consumed by the motherboard to higher frequencies. I have the oldest motherboard, a USRP1, and a few daughter boards: BasicTX and BasicRX, which are just transformers that allow you to access the baseband signals directly, and an RFX400, which is an old transceiver for 400-500MHz. Newer transceiver boards cover much wider frequency ranges. Obviously, GNU Radio contains signal blocks that transfer samples to/from the hardware front ends (actually there are two versions of these blocks; I used the newer ones, called UHD).

GNU Radio (the software) consists of three main parts. One is a library of signal processing blocks (filters, demodulators, etc) written in C++. The second part is Python wrappers for these blocks. The Python wrappers allow you to connect the DSP blocks into a signal flow graph in Python, which is easier than connecting them in C++. The third part is GNU Radio Companion (GRC), a graphical environment for constructing these signal flow graphs. It allows you to construct interesting and working radios visually, without writing a single line of code. Very cool.

First, you need to install GNU Radio. The software has many dependencies, so installing it is definitely not easy. I installed it several times, on both Linux and Wiindows. Each time, some of the software worked but some did not. I don’t bore you with all the details. What worked best eventually was installing on Windows using Josh Blum’s detailed instructions. Even after I completed the install, GRC would not start; a dialog box suggested that I need to set two environment variables, PYTHONPATH and LD_LIBRARY_PATH. This turned out to be misleading, because on Windows you need to set PATH, not LD_LIBRARY_PATH. Once I figured this out and how to set the variables (by digging the sources to see what they were supposed to point to), GRC worked.

There are some blocks (some important) that do not work or do not fully work under Windows: The WX GUI blocks (which many GNU Radio example codes use), and the audio source and sink. As far as I can tell, the audio source does not work at all. The audio sink does work, but you can’t specify an audio device (which is possible in Linux). Also, in the other set of GUI blocks, the Qt blocks (which Josh added to GNU Radio), the slider does not work, which is fairly annoying.

On Ubuntu Linux, you can install GNU Radio and GRC from existing packages, but then the installation contains neither the UHD driver and blocks nor the Qt blocks. I tried to live with this, but the WX blocks did not work well, so I switched to an alternative installation method. In this method, you run a script that installs everything. The script worked well for me, installing a version with both UHD and Qt support.

With the software installed, I started experimenting with GRC (I actually started by trying to run the Python examples that came with GNU Radio, but they did not work because of some problem with the WX GUI blocks, so I switched to GRC experiments). To get started, I mostly used the tutorials by Sharlene Katz and the GRC examples by Alexandru Csete. Sharlene’s examples use the old USRP driver, not UHD, and they use the WX GUI blocks, so I could not use them as it, but her tutorials were very helpful. Alexandru’s examples are available for both the old USRP driver and for UHD, so they were mostly usable as is.

Here is a simple SSB/CW receiver that uses a Softrock as a front end. There is no tuning control (I controlled the center frequency of the Softrock from another application), but the receiver works and I was able to hear some CW signals on 14MHz. I think that writing a controller that would be able to tune the Softrock should not be that hard (since another Python program, Quisk, already knows how to do that).

My second GRC radio is a bit more complex: a narrow-band FM transceiver. I use it with the RFX400 transceiver, connected to the 430-440MHz home built Yagi. I can hear many FM voice signals, some from quite a distance. I was also able to communicate with Avishay Ginzburg, who lives about 4km away. It’s not that far, but the RFX400 only puts out about 100mW. Avishay complained that my audio was pretty bad, but he was able to understand me. There is also some problem with switching from transmit back to receive which I still have to investigate. In theory, when the USRP has no outgoing samples to send, it switches off the transmitter in the daughter board, allowing the daughter board to receive from the same antenna connector. I stop the samples from going out during receive using a signal processing block called a valve. In practice, the transmitter sometimes stays on, preventing the receiver from functioning properly. I don’t know if it’s a bug in my GRC radio or a bug in the valve or on the UHD driver. Anyway, here is one version of this transceiver (I keep modifying it).

My next plan is to see if I can hear satellites using this radio. I’m basically waiting for a satellite pass with a strong signal that I can easily hear using the FT-875D; once I hear one, I’ll switch the antenna to this software radio and see if I can see the signal on the spectrum display and hear the audio.

Soundcard now Decodes APRS

The comments by Julian and Marc on my previous post on APRS have been extremely useful. Julian pointed me to a writeup by John Ackermann that explains that APRS decoder do not work well when the 2200Hz tone is much weaker than the 1200Hz tone. I recorded a few packets and looked at the signal in Audacity, an open-source sound editor. Sure enough, the amplitude of the 2200Hz tone was much smaller than that of the 1200Hz tone:

John Ackermann’s article discusses one reason for this phenomenon: a modem that overdrives the transmitter. APRS packets are sent on VHF using audio tone that modulates an FM transmitter. FM voice transmitters pre-emphasize high audio frequencies and then clip the audio to limit deviation. If the modem overdrives the transmitter, low and high frequencies have the same amplitude. This seems fine, but the receiver de-emphasizes high frequencies, leading to the 2200Hz tone being too weak.

Initially I suspected that this problem caused my problems. I asked Avishay Ginzburg to send a few packets at his normal setup and then to reduce the drive from the modem. With a reduced drive, the overall amplitude of the received audio on my side was lower (both by ear and in Audacity), but the 2200Hz tone was still much weaker than the 1200Hz tone. So overdrive was not the problem.

Avishay’s signal is very strong in my home, so the signal-to-noise ratio that I initially suspected was not the issue either. Time to look for other suspects.

Marc’s comment on my earlier post suggested that the same problem could be caused on the receive side, by the interface to the modem or by the modem itself. I use a soundcard, not a hardware modem, but the sound-card interface certainly could be the problem. For the APRS experiments (or at least for most of them), I used a galvanically-isolated soundcard interface, not the simple interface that I described here a while ago. I switched to the simple interface; problem solved. I could now decode packets from a couple of stations, both stationary and mobile.

I also switched from the FM mode of the FT-857D transceiver to the packet mode. That may have made a difference too. The reason that I did not use the packet mode earlier is that the Windows software modems switch from receive to transmit using the RTS or DTS signals of a serial port, which is a mode that I don’t like to use. The packet mode on the FT-857D does not support sound-activated transmission (VOX), so I used the FM mode. Soundmodem, the Linux soundcard modem, supports receive/transmit switching using serial CAT commands, so I could use the packet mode.

Why was I able to decode ISS packets but not local packets? Perhaps I used the simple interface and not the isolated one, but perhaps I used the packet mode. The main conclusion here is that I should have kept notes on the setups that did work and on the setups that did not work, but I didn’t keep any notes. Big mistake.

Why does the galvanically-isolated interface act as a low-pass filter? I still don’t know. I should probably test the frequency response of the audio isolation transformers. The interface also includes resistors to drop the signal to a level that’s good for the microphone input of a sound card; perhaps the resistors formed an RC filter with some capacitance, or an LC filter with the transformers. The interface works fine for narrowband modes like PSK31 and JT65A, so I assumed it would also work for APRS, but this assumption is wrong; an interface with a non-flat frequency response may work fine for narrow-band modes but may fail for wider-bandwidth modes.

Soundcard APRS

Warning (added on June 14): the conclusions at the end of this post are wrong; see a followup post for a more likely reason for the failure to decode packets.

Over the past few weeks I’ve been trying out APRS, a digital communication mode that is popular mostly on the 144Mhz band. APRS mostly consists of short location announcements that are sent over radio. These are displayed on nearby radios that receive them, and if one of the receivers is connected the internet, which is often the case, they are uploaded to internet servers. Websites like aprs.fi and openaprs.net can display the information on a map. You can also use APRS to send email and announcements over radio, but the main use appears to be dissemination of location information.

Some high-end VHF radios have built-in APRS capabilities: they can transmit APRS packets (using a built-in or attached GPS to determine the location) and they can display received APRS packets. With less capable radios, you connect the radio to a computer via a specialized modem called a TNC, or you connect the radio to the computer’s sound card and use a software modem. Either way, an APRS client program running on the computer sends messages and displays received messages. I don’t have a TNC, so I experimented with software modems.

I started with a software modem program called AGWPE, which runs under Windows. Several APRS client programs can use it; the one I like best is APRSISCE32, but I’ve also used UI-View32. I set up the software and was quickly able to send location packets to nearby stations. In the screenshot on the right you can see my location, as received by a station about 30km away (interestingly, this station did not upload my position to the internet; it retransmitted it, and the retransmitted packet was picked up and uploaded by a station in Cyprus that is 350km away from here). Decoding packets was another matter. I heard packets on the radio, but the software did not decode a single packets. I decided to try another software modem, AX.25-SCS, also running on Windows (Thanks to Julian for the link). Same thing; I can send packets but I can’t receive.

I decided to see if I can send or receive APRS packets from the international space station (ISS). The ISS has a radio that is used for APRS most of the time, but not all the time. I waited for a convenient pass, tuned the radio, and heard packets being send from the ISS. The software, AGWPE, was able to decode some of them! Not all, but at least some. I don’t know if my packets were received by the ISS (they were not gated to the internet and I did not decode them being retransmitted, so perhaps the ISS did not decode my packets). Here is one: “UR3QLZ>CQ,RS0ISS-4*:Hello To All!  op. Grigorij qth Zaporozhye Ukraine KN77MT”.

I still could not figure out why the software was not decoding local packets, which I could hear pretty well. I disconnected the computer from the radio, and told APRSISCE/32 to transmit a packet. I could hear it in the laptop’s speaker. I recorded it with an iPod Touch. Then played it back, expecting the software to pick it up though the laptops microphone and to decode it. Nothing.

I got pretty desperate, but decided to try one more thing. I downloaded soundmodem, a software modem that comes with sources and which can be compiled under both Linux and Windows. On Windows, it depends on a lot more software, so I decided to use it on Linux instead. Same thing; I can transmit packets (send from Xastir, a Linux APRS client), but the modem won’t decode packets I hear on the radio. However, soundmodem has a diagnostic mode in which it will print out corrupt packets. Running it in this mode, I could see that the software decoded the packets, but very poorly (there were mistakes every few characters).

At that point I decided that the only possible explanation is that the signal-to-noise ratio (SNR) of the packets I’m receiving is just not good enough for the demodulator. That could explain why the software decoded packets from the ISS ,which is pretty far (several hundred kilometers) but within a line of site, but could not decode packets from terrestrial stations that I can’t see directly from my balcony (where the antenna is).

To test this hypothesis, I ran the software on the computer-radio setup that I normally use to stream VHF voice traffic to the internet. That radio is connected to antenna on a high roof, with good reception of repeaters up to 100km away. I installed soundmodem on it and waited for packets. It decoded them without any problem.

The main conclusion: APRS needs a really good signal-to-noise ratio to decode packets. I am not sure if hardware modems can do a better job than the software modems; I don’t see why they would.

Some technical comments on soundmodem:

• Until the APRS client connects to it, it consumes 100% of the CPU; once it is connected, CPU usage drops dramatically. Seems like a bug that’s probably not hard to fix.
• The software chooses a sampling rate, starting from 5000 samples per second and going up until it finds a rate that the sound card supports. This often leads to 9600s/s. I modified the code to start at 11025, as suggested in some forums. Not sure if it made any difference, but it still works
• To get soundmodem to compile on Ubuntu 10.04, I had to install libxml2-dev, libgtk2.0-dev, and libaudiofile-dev. It is probably possible to install binaries from a package, but I didn’t try.

The Trombone Magnetic Loop for 50MHz

A while back I found another discarded piece of the orange polyethylene-aluminum-polyethylene tubing from which I already built several loop antennas. This piece was small, about 1.5m, and thicker than the tubing I’ve been using so far: the diameter of the aluminum tube is 16mm rather than 14mm. I decided to turn it into a 50MHz (6m) magnetic loop.

The main challenge when building magnetic loops is the tuning capacitor. After considering several designs, I decided to build a trombone capacitor using the loop itself as one plate, using 16mm polyethylene-aluminum-polyethylene tubing for the loop and the outer plate of the trombone, and a small piece of the 14mm as the inner plate. This is essentially a refined version of my unusual loop; in the unusual loop I squashed one end of the loop and stuffed it into the other end to form a capacitor. This time I would stuff a thin tubing into both ends of the loop, creating two capacitor that are connected in series by the thin inner tubing.

The thin tubing was too thick to slide into the thick tubing, so I had to file some of the outer polyethylene layer from the thin tubing. In the picture at the top, you can see scratches from this process and you can also see that the aluminum got exposed in some places. This is nothing to worry about, because the inner coating of the thick tube is about a millimeter thick, giving plenty of insulation. After filing away some of the polyethylene, the thin loop slid into the thick one.

Sizing the loop, sizing the capacitor section (the small piece of thin tubing that slides into the open ends of the thick-tubing loop), and tuning the loop were all difficult, because I don’t have an antenna analyzer. I could sometimes detect the frequency to which the loop was tuned by the peak in the noise, but not always, especially if the resonant frequency was way off. Also, the KI6GD loop calculator that I usually use to size loops and tuning capacitors refuses to go above 30Mhz. I initially started with a loop that was too large, so it resonated way above 50MHz even with no capacitor at all. I then decided to scale down the loop from a 25MHz design; this suggested a 38cm loop, which turned out to be a good size. I made some rough calculations as to how much capacitance each centimeter of the trombone would produce; I did not attempt to measure the capacitance, which perhaps I should have. The capacitor section too started much too long, but after I cut it to about 9cm I was able to tune the loop near 50.1Mhz, which was my goal. Tuning took a long time. Once the loop was tuned, I secured the trombone in place using a lot of electrical tape. It’s been several weeks since, during which I moved the loop many times, and it remained tuned. Even being in the sun does not seem to detune it significantly. The coax is coupled to the loop 1/5-diameter loop made from stiff copper wire. The coax connector and the coupling loop are secured to an ABS base using lots of epoxy glue; the base is secured to the loop using two cable ties.

A relatively large magnetic loop that requires very little capacitance to tune has a relatively wide bandwidth. That, together with the fact that the 50MHz allocation here is only 200kHz wide (of which the lower 100kHz is used mostly for beacons), means that a fixed-tune loop is good enough for me.

I don’t know how good the capacitor is (how high its Q) and I didn’t measure this, but in theory the Q should be high, because polyethylene is a good dielectric; Peter Rhodes used polyethylene bags (e.g. freezer bags) in his PIC-A-TUNE antenna tuner to build high-Q high voltage capacitors. In practice the coating of my tubes might have some additives that lower the Q, so I can’t say anything definite.

I have not found too many other designs for 50MHz loops. Ed Bosshard describes a couple on his web site (both larger than mine). Juan Antonio Siles Sanchez published two videos documenting (in Spanish) the construction of a square copper loop with a trombone capacitor; the loop itself forms the outer tube of the trombone, as in my antenna, and a threaded rod forms the inner part.

Higher in the VHF and certainly at UHF, magnetic loops do not make much sense, because the size of half-wavelength antennas and even full-wavelength loops is manageable, even if you do not have a lot of space. But the 3m that a 50MHz dipole would require may still be large enough to make a magnetic loop attractive.

So far I’ve made only local contacts with the loop, but there is no reason that it would not work for long-distance communication when conditions are good enough on the band. Relative to the wavelength, this loop is larger than my coax loop is at 14MHz and 21MHz, bands at which I’ve made many long distant contacts with the coax loop.

An update from early June 2011: Yes, the loop works fine for contacts with distant stations. So far I’ve made two SSB contacts with European stations and heard many more in several modes. The loop also seems to stay tuned, which is something I worried about a bit.