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.