APRS (Automatic Packet Reporting System) is an amateur-radio based system for realtime communication using digital packets sent over radio links. I present here, an implementation of an APRS iGate using the Raspberry-Pi. An APRS iGate is an Internet gateway that gates packets from the radio/RF side to the APRS-IS on the Internet (and vice-versa). The APRS-IS is an Internet based network that connects APRS networks from all around the world and facilitates APRS applications (like realtime postion reporting of objects overlaid over google maps, see aprs.fi)
piGate – complete setup (minus the 2m antenna)
The key components of piGate are depicted in the diagram below. The VHF FM radio receives the APRS packets and outputs them in form of short bursts of audio tones (APRS uses audio frequency shift keying modulation at 1200baud, listen to a AFSK1200 packet here). The audio is sent to a sound card connected to the Raspberry-Pi. The software running on the Raspberry-Pi reads the audio signal coming into the sound-card, demodulates the signal, decodes the packet and then sends it to an APRS-IS server over the WiFi link.
1. Yaesu FT-270E VHF FM Handheld 2-metreband Transceiver.
2. A 2m vertical dipole antenna (not visible in the picture above)
3. The piGate in an extruded aluminium enclosure
(a) A Raspberry-Pi
(b) A MicroNEXT MN-WD152B WiF USB Adapter with external antenna
(b) Sony Singstar usb adapter (being used as the sound card)
(c) A dual-color LED connected to the GPIO header (to indicate status).
I wanted to fit everything neatly inside a box. The eclosure I choose was this extruded aluminium case bought from Maplin (size 120mm x 78mm x 43mm). The enlosure had slots into which I could slide a standard euro-card size pcb. I decieded to mount the pi on a euro-card sized board and then slide it into place. The problem was how to mount a PCB that doe no have any mounting holes (the newer revision-2 of the pi does have mounting holes). I looked into the possibility of drilling holes into the Pi PCB but I couldn’t find an appropriate location plus I didn’t want to risk damaging the board. So instead, I used these Nylon hex threaded PCB spacers. I used a stanely knife to cut slots into them and then screwed then onto a SRBP (read paper plastic composite) board. I used four of these nylon spacers hold the Pi in place on the SRBP board (the SRBP board slides into the enclosure).
The sound-card and the WiFi adapter are mounted on the bottom side of the board. There were no mounting holes on the WiFi adapter PCB as well so I drilled a hole at an appropriate location on the PCB (kids dont try this at home!). Soon I realized that there wasn’t enough space for full size USB connectors so I made custom USB cables for the sound-card and the WiFi adapter.
1. Power is supplied to the box using a regular DC jack. I soldered wires directly from the DC jack to the power supply input filter capacitor on the Pi PCB.
2. The WiFi adapter uses a lot of current and the USB port on the PI are not able to supply that unless you bypass the poly-fuses in the power supply path of the USB port. I used instruction given here to do this mod.
3. Half of the SD card was poking out from the SD-card slot. This was bugging me, so I cut the SD card to shorten its length (again kids, dont try this at home !). Actually if you hold a SD card against a bright light you can see that only some part of it is the actual memory package, the rest is just plastic.
4. The composite video socket on the Pi PCB was also coming in the way so I got rid of that as well.
I had to pay particular attention to the audio interface between the VHF radio and the sound card. The first thing was to select a sound card that delivers good audio quality. I started with a cheap Ebay USB sound-card and quickly found out the recorded audio quality was rubbish and hence the software was not able to decode any packets. I settled with the Sony Singstar USB adapter (which is just a plain old USB soundcard, only mic inputs tough), it was quite cheap and the audio quality was good enough for my application. The second thing was to consider the actual interface because the VHF radio audio out is a line-level audio output and the input on the sound-card input is at mic-level. I built a line-level to mic-level adapter based on designs given on this page ( 20 dB PAD for line to electret microphone input ).
On the software side of things I am using Multimon . to decode the audio coming from the sound card and a python script to handle everything else. Multimon reads from the soundcard input, runs a AFSK1200 demodulator on the received data and then prints the decoded packet on the terminal. I wrote a python scripts that launches multimon as a subprocess and redirects the standard output into a pipe so that the script can read what multimon is spitting out. My python script wasnt able to read anything coming out of Multimon initially. I had to add some stream flushing code and recompile Multimon to get over the problem.
To make the required changes to multimon, I compiled it on the Pi itself. The source code on the link given above is old and doesn’t compile on ARM based machines. I wasn’t able to find the sources for multimon in the debian repository for the Pi, so I downloaded the source package from the main debian repository and it compiled on the Pi without any problems.
The python script does the following:
1. Launches mutimon as a subprocess and redirects the standard output to the a pipe that it can read.
2. Establishes a TCP socket connection with an APRS-IS server
3. Checks incoming packets to see if they meet the criteria for gating and then sends the packet to the APRS-IS by appending its own call to the packet path.
4. Sends its own position reports to APRS-IS every 5 minutes.
[asdil12] has kindly posted his set of scripts for this job which you can grab here: https://github.com/asdil12/pymultimonaprs
1. Reducing audio latency: There is a few seconds of delay between the packet being received and sent to APRS-IS. I think this is because multimon is using the older OSS interface for reading audio from the sound card. Also I have read that the kernel can be tuned to reduce the delay even more.
2. Reporting own postion: The position in the report is hard-coded at the moment but I am working on a script to determine the position of the box based on the MAC addresses of the WiFi APs in range using the skyhook API.
3. Adding a web interface for management.
4. Using a USB DVB-T dongle as a software defined radio (like RTL-SDR) connected to the Pi instead of the VHF radio & audio interface that I have used. The new setup can probably be used for numerous other practical applications. Although the Pi processor might not be good enough for real-time SDR processing, it can possibly instead use the computational resources of another machine connected to the internet for that purpose.
Some more pics of the piGate: