APRS (Automatic Position Reporting System) is an amateur-radio system allowing on-line transmission of position of mobile stations through short packet reports addressed to all other stations. Reports are sent by both stationary and mobile stations. In addition to their position, stations can also broadcast e.g. weather reports or telemetric data. A characteristic element of the system is co-operation of mobile stations with GPS devices, which assures precision of reporting.

The creator of APRS is an American ham-radio operator Bob Bruninga, WB4APR. Although work on the system was launched as early as in the late 1970s, APRS was not accepted as a new standard of amateur packet radio until the TAPR/ARRL conference in 1992. The APRS system is a tactical method of communication based on a network of relays and gateways. Most APRS communication takes place at the simplex frequency of 144.800 MHz. A complete APRS station includes a transceiver, a TNC controller, a GPS receiver and a computer which uses APRS software to manage the station. How different elements of a station are used depends on its character and conditions it operates under. It often happens that a mobile station is limited to APRS software stored in TNC, not using a computer. Certain mobile stations merely transmit their position, using a simplified form of TNC - e.g. TinyTrak, which already contains APRS software but allows only transmission of data from the GPS receiver to the radio, without the possibility of bi-directional APRS communication. Home stations have no need for attaching a GPS receiver, as their position never changes. Finally, Kenwood devices are so integrated APRS stations that all one has to do is plug in an external GPS receiver - inside we've got both the transceiver and the TNC with APRS software; one can use them with the manipulator and the display, allowing for bi-directional communication with other APRS stations. The functionality of transmitting text messages over APRS is a very helpful means of communication between stations. Two kinds of messages can be used: ones with a defined recipient, or bulletins and messages addressed to all stations. An example of the latter can be weather reports broadcast by weather stations. Such reports contain: direction and speed of wind including bursts, temperature and optional parameters such as rainfall, humidity or atmospheric pressure. Moreover, APRS makes it possible to send messages addressed to e-mail accounts; here one should write EMAIL instead of the recipient's call sign and start the message body with the e-mail address, separated from the body proper by a space.

The hardware needed to participate in APRS is:

• A transceiver (radio) capable of receiving and transmitting in the UHF band on the frequency 144.800 MHz,

• A GPS (Global Positioning System) receiver capable of sending data in the NMEA0183 format over a serial RS232 connection; most devices available on the market meet this condition,

• A modem, TNC, computer or other device making it possible to connect the GPS unit to the radio, which will manage the system, transmit our data and enable presentation of data received from other stations. Such a device will be described further in the article.

Mobile APRS Devices

One can find descriptions of many small APRS devices on the Internet. Among them, tree warrant special attention: TinyTrak, PeekPack and AntiTraker. All three of these devices have been built using the PIC16F84 processor.

TinyTrak (http://www.byonics.com/tinytrak/) makes it possible to retrieve position information from a GPS unit and transmit frames containing position over the radio, at a specified time interval. The electronic circuit is very simple: the modulator is built out of 4 resistors which appropriately format the input signal and the demodulator limits itself to checking whether the channel is busy, so that TinyTrak transmits when the frequency is free.

Initially, PeekPack was developed by the same person who designed TinyTrak; a proposal for a more sophisticated version can be found at http://www.ir3ip.net/ik3svw/. Unlike TinyTrak, this device only allows one to receive frames and display them on a text-mode LCD screen. The electronics is just as simple as before, except a separate modem is necessary - for instance, the integrated circuit MX614 or TCM3105N.

AntiTracker (http://www.radio-active.net.au/web/tracking/antitracker.html) is a receive-only device as well, but the results it receives can be displayed on the GPS map if the the user owns an appropriate device. The electronic circuit is more complicated - four integrated circuits are required. In my opinion one could do away with the MAX232 circuit by replacing it with two transistors, as well as replace the two microcontrollers with one with more memory, e.g. PIC16F87.

Among the many available descriptions I haven't found a device which would allow receiving messages and replying to them. Another issue here is how to quickly interpret position of detected stations without the map, i.e. by using only numeric coordinates. Since building a separate device to provide a single feature is not a good solution, I have designed a device which combines everything I've just mentioned and at the same time has rather simple electronics, containing only three integrated circuits.

When it comes to APRS it is worth it to build one's own device and program it. It doesn't have to have a large, colour display or a multi-key keyboard. While building such a device it's best to use single-chip microcomputers - the so-called microcontrollers. I recommend the Microchip' PIC16F84 chip to beginners, the more advanced users might try their luck with Atmel microcontrollers: ATMEGA32 or ATMEGA128.

Choosing a Microcontroller

We start by choosing an appropriate microcontroller. It should have enough memory to contain our program code and have enough terminals for us to be able to connect a display, a keyboard, a modem and a serial port.

Many electronics people favour the ’51 series of chips, e.g. AT89C2051; unfortunately those chips are too slow and unsuitable for receiving Packet Radio signals. Their clock signal is internally divided by 12, which with the maximum clock speed of 12MHz gives us 1MHz of instruction frequency - which in turn must be divided into several to tens of cycles per operation, resulting in rather low operation speed. Furthermore, those chips do not contain internal EEPROM memory, further complicating the final circuit.

Another popular family of chips is PIC by Microchip. In this line of chips the clock signal is divided by only 4 and each operation takes up only one cycle (except jump operations, which take two). Moreover, those chips do contain internal EEPROM memory; however, division of their operation memory into banks effectively discourages beginners from programming them. Another serious hindrance is that there are no free C compilers for those chips, thus forcing most readers to program in assembly. On the other hand, Microchip has published an excellent run-time environment for its products at its website.

Finally, I have chosen the ATMEGA32 circuit. This is the chip with the largest amount of memory which is available in a large DIP-40 casing with 2.54 mm gaps between pins, meaning there should be no problems with soldering and placing the chip on an universal board. This circuit belongs to Atmel's AVR family, whose design is based on the Harvard architecture - whose main property is separation of program and data address space by using isolated addressing buses.

A Programming Environment

The AVR family are quite modern, fast and feature-rich microcontrollers. In order to facilitate setting up those chips, the manufacturer has made it possible to program them after they've been installed in the final system. Many interesting properties of those microcontrollers are related with their architecture or their instruction list, the latter having been designed with C compilers in mind.

Atmel provides everyone, free of charge, with an integrated development environment for AVRs called AVR Studio (http://www.atmel.com/). It contains an editor with syntax highlighting, an assembler and a simulator making it possible to trace execution of programs watching the state of all circuits built into the microcontroller. It is also possible here to create, compile and run programs written in C. This last feature offers great possibilities, then again it also causes a lot of problems with configuring the environment properly and adapting the C compiler to it. A good addition to AVR Studio is a free C compiler called AVR-GCC (http://www.avrfraks.net/). Since not every version of AVR Studio can be adapted to co-operate with a C compiler in the same way, I suggest the following approach:

• write program code in any text editor,

• prepare makefiles as shown in Listing 1 and a compiler script as shown in Listing 2,

• perform compilation on the command line,

• simulate execution of the program in AVR Studio by pointing it at the *.obj obtained as a result of the previous step.

Listing 1. A makefile used to compile AVR programs

# Simple Makefile by Volker Oth (c) 1999
# edited by AVRfreaks.net nov.2001
 
########### change this lines according to your project ##################
 
#put the name of the target mcu here (at90s8515, at90s8535, attiny22, atmega603 etc.)
MCU = atmega323
 
#put the name of the target file here (without extension)
   TRG = FOAPack
 
#put your C sourcefiles here 
   SRC = tnc.c $(TRG).c
 
#put additional assembler source file here
   ASRC =
 
#additional libraries and object files to link
   LIB = c:avrgcclibavr-libc-20011126srcavr5libm.a
 
#additional includes to compile
   INC    = 
 
#assembler flags
   ASFLAGS = -Wa, -gstabs
 
#compiler flags
   CPFLAGS = -g -Os -Wall -Wstrict-prototypes -Wa,-ahlms=$(<:.c=.lst)
 
#linker flags
   LDFLAGS = -Wl,-Map=$(TRG).map,--cref
 
########### you should not need to change the following line #############
include $(AVR)/avrfreaks/avr_make
 
###### dependecies, add any dependencies you need here ###################
tnc.o : tnc.c
$(TRG).o : $(TRG).c

The compilation script called gcc_cmp.bat (see Listing 2) should be placed in one's working directory (i.e. where all the source files are stored), having if needed modified the avrgcc path. Execution of this script with the parameter clean results in deletion of all compiled files; this is useful sometimes when the compiler has got problems with incremental code generation.