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.

APRS Using WiFi Localization

I’ve been running a soundcard APRS gateway for more than a month now. It relays packets from 144.800MHz  to the internet using an old TR-2500 transceiver and a small Linux box running soundmodem and Xastir, both remote. Apart from a few days when Xastir was hung (but did not crash; perhaps a deadlock), this worked flawlessly. The gateway uploaded many location packets from vehicles in the area. It also received many packets from a digipeater on an 1700m-high mountain in southern Turkey (TM5HTY), some 450km away, and a some from Cyprus.

More recently, I’ve been experimenting with running an APRS client, APRSISCE32, on my laptop. There are two ways to tell APRSISCE32 where you are, so that it can report the information. One is by clicking on the map. This is fine is you don’t move much, but it’s not a practical way to keep track of changing locations. The other way is using a GPS connected to a serial port. This is also not very practical on a laptop, because laptops do not have a built-in GPS receivers (toting an external one is a hassle) and because they are mostly indoors where there is no GPS reception.

I discovered, however, that a company called Skyhook makes a free program that uses WiFi localization to emulate a serially-attached GPS. The program, called Skyhook XPS, tries to determine your location by noting which WiFi access point your laptop hears. It sends the identities (MAC addresses) of the access points to the company’s servers, which looks them up in their database. If some of these MAC addresses are associated with a physical location in the Skyhook’s databases, the program knows where you are. It provides this information to other programs, like APRSISCE32, using a virtual serial port that it creates. The location information is sent over this serial port as if it came from a GPS (that is, using standard NMEA sentences).

Apple uses a very similar schemes to provide location information to devices without a GPS, such as the first-generation iPhone and the iPod Touch.

When I tried Skyhook XPS at home and at work, it could not determine my location; the access points near me were not known to Skyhook. The company’s web site has a web form that allows you to associate MAC addresses with geographic locations, and I used it to upload the MAC addresses of access points at home and at work. The web site warns that it may take a few weeks for the information to become usable, and indeed the software was unable to localize me even after I uploaded the data.

In the mean time, I went on trips to Germany and the US. There the software localized me without any problem and with good accuracy (10m confidence circle), most of the time pinpointing correctly the building I was in. Here is a screenshot from Aachen, Germany.

When I got back home to Tel-Aviv, the software was finally able to localize me both at home and at work. The locations were precise, but the software’s confidence was lower (154m at work, 173m at home).

I think that the localization confidence is dermined by the number of access points whose location Skyhook knows. In the screenshoot from Germany you can see many red dots on the WiFi radar-like display, meaning that Skyhook knows the location of many access points; in the screen shot from Israel there is only one red dot, so the software can’t determine exactly where I am. Skyhook’s web site has a coverage map and there I can see that it has some coverage (known access points) in Israel, but not very many and not as many as in other countries. Apple seems to have a much better coverage of Israel, because my son’s iPod Touch always knows where he is.

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.

A Tripod Mount for the Satellite Yagi

A tripod mount made the Satellite Yagi a lot more usable. I found a few brass anchors that fit a tripod screw. I cut the wood beam of the Yagi so that it was just a bit longer than the antennas themselves. A small piece of the remaining lumber, drilled a hole that fits the anchor through it and forced the anchor through. There a bit of glue, but it’s mostly pressure that keeps the anchor in place. The anchor extended from the other side of the piece of wood, so I drilled the boom too to take the extra piece. Finally, I secured the piece of wood with the anchor to the bottom of the boom using both glue and screws.

The antenna is now easy to rotate by hand as the satellite moves overhead. I managed to receive many different satellites and to work AO-51 from my balcony, with the antenna essentially indoors. (I can only hear and work the satellites when they are east of me, because the balcony faces east.) The pictures below show a closeup of the tripod mount and the antenna mounted on the tripod.

Streaming Radio Channels on the Web through RadioReference.com

Update from April 17: The feed has been running now for a few days non-stop using a really old transceiver (a Kenwood TR-2500 from around 1983). It is pretty useless as a transceiver (dead rechargeable battery, dead memory-retention battery, and no CTCSS), but it’s working well as a scanner. Enjoy the feed.

I’ve been trying to stream audio from a radio over the internet. I started by installing Icecast, a streaming web server (it runs on both Linux and Windows; I installed it on a Linux box). Icecast assumes that another server will send it the audio stream, which Icecast can then send to many clients. There are several servers that can read audio from a soundcard and send it to Icecast, usually as an MP3 or Ogg stream. I tried a few: livecast, ices, and darkice. I could not get any of them to work.

Eventually I found a post in some forum that showed a darkice configuration file which worked for me. I connected to the Linux box from a browser in my Windows laptop and was able to hear the live audio stream. I began to wonder how to make this stream available to others (firewall issues and the like), when I remembered that the forum post that helped me was on RadioReference.com. I decided to check what this web site is.

I discovered that RadioReference.com provides a large number of live radio-channel audio feeds. Many channels cover police, fire departments, and other government agencies (mostly in the US), but there are also quite a few feeds of amateur radio channels, almost all of them VHF and UHF channels. I registered and requested to provide a feed.

A few hours later my request was approved and I was given the technical details of how to connect. The web site suggested that I provide the feed using a Windows application that they provide, but they also have instructions on how to feed the audio using darkice. I configured darkice on the Linux box and started feeding audio. Darkice samples the audio at 8000Hz and send it to RadioReference.com in variable-bit-rate MP3 format (quality setting 0.2) with a high-pass filter at 300Hz and a low-pass at 3500Hz.

The feed is coming now from the FT-857, which is scanning all the local VHF and UHF repeaters as well as some popular Simplex frequencies. The results are excellent. The audio quality through the web is as good as the audio coming out of the radio. I can listen to the feed on a computer or on an iPod (and probably on many other devices).

There are several advantages to this approach relative to using Echolink

• You don’t need the Echolink application, only a browser;
• The stream is available to anybody on the internet, whereas Echolink is only open to licensed radio amateurs;
• By connecting the feed to a scanner you can get a better sense of the activity in an area than with an Echolink node that sits on one frequency.

On the other hand, Echolink allows you to talk to people you hear on the radio, not only to listen to them.

My next step is to try to replace the FT-857 by an old hand-held VHF transceiver and using a dedicated antenna, so the FT-857 and my main antenna are not tied up in this application.