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. The author describes how to build complete mobile device which can be realised all needed functions.

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

 1: # Simple Makefile by Volker Oth (c) 1999
 2: # edited by AVRfreaks.net nov.2001
 3:  
 4: ########### change this lines according to your project ##################
 5:  
 6: #put the name of the target mcu here (at90s8515, at90s8535, attiny22, atmega603 etc.)
 7: MCU = atmega323
 8:  
 9: #put the name of the target file here (without extension)
10:    TRG = FOAPack
11:  
12: #put your C sourcefiles here 
13:    SRC = tnc.c $(TRG).c
14:  
15: #put additional assembler source file here
16:    ASRC =
17:  
18: #additional libraries and object files to link
19:    LIB = c:avrgcclibavr-libc-20011126srcavr5libm.a
20:  
21: #additional includes to compile
22:    INC    = 
23:  
24: #assembler flags
25:    ASFLAGS = -Wa, -gstabs
26:  
27: #compiler flags
28:    CPFLAGS = -g -Os -Wall -Wstrict-prototypes -Wa,-ahlms=$(<:.c=.lst)
29:  
30: #linker flags
31:    LDFLAGS = -Wl,-Map=$(TRG).map,--cref
32:  
33: ########### you should not need to change the following line #############
34: include $(AVR)/avrfreaks/avr_make
35:  
36: ###### dependecies, add any dependencies you need here ###################
37: tnc.o : tnc.c
38: $(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.

Listing 2. A compilation script called gcc_cmp.bat

1: @echo -------- begin --------
2: @set AVR=c:avrgcc
3: @set CC=avr-gcc
4: @set PATH=c:avrgccbin
5: call make %1
6: @echo -------- end --------

Each project must contain a makefile (Listing 1), containing instructions for the compiler about how to compile the program in question. We assign atmega323 to the parameter MCU because there are no header files exclusively for the ATMEGA32 chip; the version 323 is fully compatible with ATMEGA32. If we want our program to perform floating-point arithmetics and make use of mathematical function, a path to the library lib.m should be provided in the attribute LIB. One could also experiment with the compiler flag specifying optimisation level. The values -O1 ... -O6 will make the program faster by a few percent, but can radically increase code size; my recommendation is to stick with -Os, which generates the most compact code. If the program is to consist of several files, each of them must be listed in the attribute SRC and added at the end of the makefile in the section dependencies.

Listing 3. An example test program

1: #include <io.h>
2: int main(void) {
3:    DDRA=0xff;       //port A as output
4:    while (1) {
5:       sbi(PORTA,0); // pin A.0 on
6:       cbi(PORTA,0); // pin A.0 off
7:    }
8: }

In order to test the installed development environment I suggest compiling and running, in the AVR-Studio debugger, the code shown in Listing 3. The program sets up port A of the microcontroller in such a way that its lines are output. Inside an endless loop, we enable and disable voltage on the zero pin of port A. It is not possible to exit the function main - microcontrollers have no operating system one could return to; if we forget to loop the main program, the microcontroller will start executing random instructions, sooner or later causing the circuit to hang or get reset.

Secrets of Microcontroller Programming

ATMEGA32 features four eight-bit I/O ports. Each port has got three configuration registers, e.g. the port A has got registers called DDRA, PORTA and PINA. Writing a one into DDRA switches appropriate pins to output, making it possible to e.g. control a LED connected to this pin by setting or clearing the relevant bit in the register PORTA. If we write a zero into DDRA, the port will work in input mode, making it possible to e.g. read the voltage at the port's pins by reading the register PINA, checking if a key was pressed for instance. Writing a one into PORTA when the port is set to input enables internal pull-up resistors. In many cases part of a port is used for input and part for output, for example while working with a matrix keyboard.

Certain pins of ports can be switched to dedicated modes, for example pin "0" of port D is used to receive RS232 signal and its pin "1" is used to transmit that signal. Of course if we don't use serial communication, both pins can be used as general-purpose input/output.

Memory

AVR microcontrollers feature 3 kinds of memory, all of which are addressed starting with zero.

FLASH

The FLASH memory is used to store program code together with constant array data. It is non-volatile and programmed using an external programming device. ATMEGA32 features 32kB of FLASH memory which, according to documentation, can survive up to 10000 erase-write cycles. Strings in program code should be implemented as static arrays of characters:

• static char setting_str [] PROGMEM = "Smart Beacon";

or can be provided directly as arguments to functions:

• print_string( PSTR ("Smart Beacon ") );

reading such definitions byte-by-byte can be accomplished using a special macro:

• byte = PRG_RDB(setting_str + offset);

This memory is managed by the compiler.

SRAM

The SRAM memory is ordinary RAM. Its first 32 bytes are general-purpose registers. Further 96 bytes are reserved for function registers, which provide information about current state of the microcontroller or allow one to control the core or internal peripherals. The content of this memory is not preserved over power losses. It is extremely fast compared to other two types of memory. ATMEGA32 has got 2kB of SRAM, which also contains the stack of the program. This memory too is managed by the compiler.

EEPROM

The EEPROM memory is typically used to store configuration settings. It is possible to write to it from within program code, but it is rather slow - reading on the other hand is very fast. Stored data is preserved over power losses. ATMEGA has got 1kB of this memory which allows for, according to the documentation, 100,000 erase-write cycles. This type of memory can be accessed using dedicated functions understood by the C compiler:

• eeprom_wb(address, data) - used to write a single byte at the specified address,

• data = eeprom_rb(address) - used to read one byte from the specified address,

• dataW = eeprom_rw(address) - used to read a single word from the specified address.

It is up to the programmer to manage EEPROM memory. The most convenient way of doing this is to wrote a header file containing definitions specifying what memory cell is used for what purpose, e.g.:

• #define EEPROM_CURRENT_FIXED_POSITION 100

There are other compilers available as well - e.g. CodeVision AVR, which features a qualifier eeprom specifying that the declared variable or array is to be stored in the EEPROM memory. Under such circumstances, the programmer doesn't have to assign addresses by hand.

Timers

A timer is a sort of a counter which increments its value independently from the program, either with every clock cycle or every certain cycle, depending on configuration of the so-called prescaler. Timers can be handled in two ways: the first approach involves testing the timer overflow flag, the second - using interrupts. ATMEGA32 features two eight-bit and one sixteen-bit timer.

Listing 4. Configuring and using a timer

 1: #define XOSC 11059200
 2: #define TIME_19200 (256-(XOSC/8)/19200)
 3: TCCR0=2;            // timer0 works with XOSC/8
 4: TCNT0=TIME_19200;   // add time constant for requested interval
 5: TIFR=1<<TOV0;       // cut overloaded flag
 6:  
 7: void test_timer_overflow(void) {
 8: if ((inp(TIFR)&(1<<TOV0))==0) return; // wait for setting
 9: TCNT0=TIME_19200;             // add time constant again
10: TIFR=1<<TOV0;                 // cut overloaded flag
11: [...]
12: }

Interrupts

One might wonder what is better: testing overflow flags or using interrupts. The first approach is better in that it allows easier synchronisation of our application; on the other hand, using interrupts relieves the CPU from having to periodically query peripheral devices and take appropriate actions if certain conditions have been met. AVR microcontrollers offer many interrupts, with varying priorities. If an interrupt is generated while a handler for a lower-priority one is being executed, the latter will be suspended until the higher-priority interrupt has been handled; in opposite situations the lower-priority interrupt has to wait. Once all interrupts have been handled, control is returned to where it was interrupted. Interrupts can be generated by:

• applying appropriate voltage to certain terminals (useful while building counters);

• having received or transmitted a character over the serial port;

• an overflow of an internal timer.

A more elegant, precise and reliable way of handling Packet Radio frames will be to use interrupts. In order to do that we must set the timer to CTC (Clear Timer on Compare match) mode, see Listing 5; work in this mode involves zeroing the timer upon a comparison match between the registers TCNT and OCR. Every such occurrence can generate an interrupt (see Listing 6), which we can handle simply by reading modem input and processing received data.

Listing 5. Configuring a timer to work with interrupts in CTC mode

1: void Packet_RX_Init(void) {
2:    TCCR0 = 2|(1<<WGM01); // timer0 works with Fosc/8
3:    TCNT0=0x00;            // start counting form0
4:    OCR0 = ((XOSC/8)/19200)-1; // set boundary value
5:    TIFR = 1<<OCF0;            // cut overloaded flag
6:    TIMSK = 1<<OCIE0;          // switch interrupt when it is overloaded
7: }

Listing 6. An interrupt handler

1: SIGNAL(SIG_OUTPUT_COMPARE0) {
2:    packet_rx = PACKED_IN & (1<<PACKET_RX_BIT);
3:    [...]
4: }

RS232 Transmission

Listing 7. Configuring and using the serial port

 1: #define XOSC        11059200
 2: #define UART_BAUD_RATE    4800    /* baudrate */
 3: #define UART_BAUD_SELECT    (XOSC/(UART_BAUD_RATE*16l)-1)
 4:  
 5: UCSRB=(1<<RXCIE) |(1<<TXCIE)|(1<<RXEN) |(1<<TXEN);
 6: UBRR=UART_BAUD_SELECT;
 7: UCSRC=(1<<URSEL) | (1<<UCSZ1) | (1<<UCSZ0); // 8 Bit,1 Stop, no parity
 8:  
 9: unsigned char *pSerialTx;
10: // Receive Interrupt Routine
11: SIGNAL(SIG_UART_RECV) /* signal handler for receive complete interrupt */
12: {
13:    unsigned char recbuf;
14:    recbuf=UDR;
15:    my_function(recbuf);
16: }
17: // Transmit Interrupt Routine
18: SIGNAL(SIG_UART_TRANS)   /* signal handler for transmit complete interrupt */
19: {
20:    if (*pSerialTx)
21:    UDR = *pSerialTx++;
22:    else
23:    cbi(UCSRB,TXEN); // Disable Transmit complete interrupt
24: }
25: void serial_send (unsigned char *ptr) {
26:    pSerialTx = ptr;
27:    sbi(UCSRB,TXEN); // Enable Transmit complete interrupt
28:    UDR = *pSerialTx++;
29: }

In Listing 7, first of all we specify clock and transmission speed as macros. Next, we switch appropriate inputs from general-purpose I/O to serial transmission mode, then enable interrupts. When a byte has been successfully received, an interrupt is generated which will be handled by the function SIG_UART_RECV. The received byte is stored in the queue and awaits retrieval by reading the register UDR; meanwhile, the UART can be receiving more data and microcontroller can be processing a recently-retrieved byte. One shouldn't make interrupt handlers too long, otherwise once another byte has been received the chip won't be able to generate another interrupt - the last one is still being handled. This could result in losing received data; in order to avoid this one should either decrease transmission speed or optimise the processing procedure. Transmission involves writing a value into UDR; once its transmission has been completed another interrupt is generated, which we can use to start sending more data. This approach is often employed whenever there is a need of transmitting a string of bytes. Transmission of e.g. 100 bytes at 4800 baud takes over 21 ms, we mustn't occupy the CPU for that long. Thanks to interrupts all we have to do is initiate the transmission by calling serial_send(), after which control can be returned to the main loop.

Building FOA-Pack

The name of this device has come from the suffix of the ham-radio call sign of its designer (i.e. the author of this article). It can be used for APRS both at home or in a car. It cooperates with any UHF transceiver and NMEA-compliant GPS receiver. The device is not sold anywhere, neither as a whole or as a self-assembly kit. All the elements can be obtained at most electronics shops. Detailed assembly instruction, schematics and a list of components can be found at the author's home page (http://sq2foa.republika.pl).

The complete program code can be obtained from the author on condition of sending a picture of an assembled device - however, I encourage everyone to write your own programs, or even to design your own electronics circuit to operate as the mobile device.

Concatenation of received frames into a list

Due to limited memory on board of the chip, the list contains 8 entries. If the device has received a frame already on the list, it removes the old entry and appends the new one to the end of the list. Frames are compared using the call sign of the source and the type of the information field (the first byte). If the list is full, the first entry is deleted. Unread messages to the user are not deleted.

Displaying details

By choosing the entry number on the keyboard we can display appropriately-formatted data about the position of the base station, velocity and bearings of moving stations and weather information. One can also peek at the source of the frame or check the distance, the azimuth and the position on the map of Europe.

Sending messages

While in details mode, one can send a message to the station in question. The message can be either one of the standard templates of written manually.

Monitoring

All appropriately-formatted frames are displayed.

Configuration

The device can be configured using the keyboard only, with all the settings stored in non-volatile EEPROM memory. One could set one's own call sign, position of the base station and information text, define a standard message for MIC-E or set up frame filtering.

Filtering

One can filter out certain kinds of frames, so that e.g. not to display information about base and/or mobile stations. Filtering out Internet frames shows only stations detectable over the radio, directly or via relays; that way we do not filter out messages addressed to the operator.

Digipeater

FOA-Pack repeats station frames which have RELAY in their path.

Co-operation with Other Devices over the Serial Port RS232

FOA-pack can send received position data to the GPS as WayPoints, or retrieve position from the GPS and send it over the radio in the MIC-E format. Here it makes use of the SmartBeaconing algorithm, which varies frame-transmission interval depending on velocity and turns. Communication with the GPS is based on the NMEA-0183 format.

FOA-pack can work as a TNC controller in KISS mode; it is possible to work with such programs as UI-View.

Two actors can be distinguished here: one is the user of the FOA-Pack, another is an unsupervised device.

I will present only one usage example that is most directly connected with APRS, in which FOA-Pack manages communication over the radio waves.

After a frame has been successfully received, it gets processed. Depending on internal settings, it is sent over the serial port either to a computer in the KISS format or to a GPS in NMEA format. If the received data contained a private message for the user, the message is stored and a delivery confirmation is sent. All data is stored in a list, so that the operator can see who is working; due to limited amounts of microcontroller's memory we only store 8 most recent frames there. If the device has relaying enabled, frames with appropriate paths are sent further. Once in a while FOA-Pack transmits its position and resends messages it hasn't received delivery confirmation for. Data to be sent is stored in a transmit buffer. After the radio channel has become available, all stored data is sent.

Radio Transmission

The packet radio system employs frequency-shift modulation, with the shift of 1000 Hz. The frequencies 1200 Hz and 2200 Hz are used, in accordance with the standard BELL 202. There is no permanent assignment of low-frequency tones to values of "mark" and "space", instead they are distinguished by detecting shifts from one tone to another (NRZ-I differential encoding). Information transmitted using the AX.25 protocol is assembled into packets, containing in addition to data, addresses of its recipients and a checksum making it possible to detect errors in transmission or receiving. APRS transmission uses only UI (unnumbered information) packets - unnumbered, not confirmed.

No change of the signal level indicates a logical 1, a change of the level indicates a logical 0. A frame consists of an opening flag, data proper and a closing flag. The opening and closing flags consist of six ones and a zero. In order to prevent such a string from appearing within the content of the frame, every five subsequent '1' bits are followed by an additional '0' bit, which is automatically removed by the receiver. Bits are transmitted starting with the least significant one. Having received a closing flag, one should compute a checksum of all the received bytes - a standard CCITT CRC calculated using the polynomial:

If the checksum is correct, we can move on to analysing the received data set. Its first seven bytes is are the destination address, the next seven - the source address, next we can find up to eight relay-path addresses. After that there is a control-field and protocol-identification byte, followed by the information field of up to 256 bytes in length. Finally, at the end there is a two-byte checksum.

Plotting Vector Maps

One of the main elements of working with APRS are maps (http://www.googleaprs.com/).

One can use scanned (bitmap) maps used by the program UI-View or vector ones used by APRSDOS. It is impossible to show everything at the same time - e.g. roads, forests, lakes and rivers - on a small, black-and-white graphical display. It is also impossible to directly use maps dedicated to stationary computers. We have to prepare a map for our device by ourselves. The best program to use for this purpose will be MapEdit (http://www.geopainting.com/en/); using it we will prepare a map containing only those elements which can be properly displayed on a LCD. MapEdit stores map data in text files, in the so-called Polish Format; such a file contains a description of the map in terms of points (RGN10 and RGN20), lines (RGN40) and polygons (RGN80). Each element is plotted using an appropriate colour, depending on the type.

For example, one element in such a file, describing a street, looks like this:

[RGN40]

Type=0x7

Label=Trawiasta

Data0=(53.737136,17.510812),(53.737587,17.511135),(53.738979,17.511606)

[END-RGN40]

The file itself contains a lot of textual redundancy, furthermore using floating-point numbers expressed as text would significantly slow down plotting and scaling of the map. Therefore, we have to create a converter which will convert data from such a file into a C array. Floating-point geographic coordinates ought to be converted into integers encompassing the whole map area: for Poland for example, the point 0,0 should correspond with coordinates N48, E14, and 65535, 65535 - N56, E23. Depending on our needs, the array should contain two two-byte coordinates of beginnings of lines (e.g. the state border), followed by single-byte position offsets of subsequent points; this will significantly reduce the size of the map in memory.

GPS Support

Most GPS devices transmit acquired data over the RS232 serial port. Format of this data complies with the standard NMEA-0183 (National Marine Electronics Association) (http://www.nmea.org/). The data contains complete geodetic information (position, velocity and time), calculated by the GPS receiver. The concept of the NMEA standard is to transmit lines of data (statements) which are independent from each other and contain certain information. Standard statements exists for each category of devices, but it is also possible to define one's own, custom NMEA sentences. All standard statements have got a two-character prefix which specifies the class of the device (for GPS units the prefix is 'GP'). The prefix is followed by three characters 3 specifying the type of the statement. NMEA is a text protocol. Each statement begins with a '$' characters and ends with a newline. No statement can be longer than 80 characters of visible text (plus the newline character). Data within a statement are separated with commas. Data too is ordinary ASCII text; under certain special circumstances it can be split into several statements, normally however it is passed in single variable-length statements. Their length may vary due to changing precision of presented information, for example, time can be specified up to tenths of a second and position up to three or four decimal places; for that reason programmers shouldn't rely on fields having fixed size and should use commas as field separator. In addition, the standard defines a checksum at the end of each statement which can be verified; it is mandatory for certain kinds of statements. The checksum sequence consists of a '*' character and a two-digit hexadecimal number obtained by performing a XOR operation on all characters between '$' and '*' exclusive. The NMEA standard recommends the following transmission parameters: 4800 baud, 8 data bits, no parity and 1 stop bit (4800 8N1); they can however be different for some GPS devices. The NMEA protocol is based on statements. The first word of each statement specifies its type and specifies how to interpret the following words. Every statement type has its specific interpretation, defined by the NMEA standard. Thanks to this, a device or a program receiving such data can look for certain interesting sentences - ignoring everything else. The standard lacks commands which would enforce a certain mode of operation of the device; instead, it transmits all data expecting that most of it will be ignored anyway. For the purpose of our device we will make use of the RMC statement, containing a set of necessary positioning data (position, velocity, time), and the WPL statement, providing positioning information about received stations.

These two statements look as follows:

$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A

where:

• RMC - Minimal navigational information

• 123519 - measurement up-to-date at 12:35:19 UTC

• A - state: A=valid or V=expired.

• 4807.038,N - latitude 48 deg 07.038' N

• 01131.000,E - longitude 11 deg 31.000' E

• 022.4 - ground velocity, in knots

• 084.4 - bearing, in degrees

• 230394 - date - 23 March 1994

• 003.1,W - magnetic variation

• *6A - checksum, always starts with *

$GPWPL,4807.038,N,01131.000,E,WPTNME*5C

where:

• WPL - Waypoint Location

• 4807.038,N - latitude

• 01131.000,E - longitude

• WPTNME - name of the waypoint

• *5C - checksum, always starts with *

The way of reading a RMC statement off the GPS depends on the amount of free RAM available on the device.

SmartBeacon

SmartBeaconing(TM) has been invented by Steve Bragg (KA9MVA) and Tony Arnerich (KD7TA). Its main goal is to alter the rate of transmitting position depending on one's speed and turn angle. It is not possible to use APRS to broadcast all measurements obtained by the GPS unit, as it would saturate the band and make it unavailable to everyone else. On the other hand, sending reports at a fixed interval of e.g. 5 minutes is not good too, because that way we could distort our track record by omitting the moment of a turn. It is also not a good idea to send information about each turn - navigating a roundabout or parking would generate unnecessary network traffic. The SmartBeacon algorithm has been designed to resolve this kind of problems.

The algorithm is defined using seven parameters:

Low Speed

Velocity, in miles per hours, below which SmartBeaconing is turned off. While moving below this speed, frames are sent at an interval of the parameter Slow Rate.

High Speed

Velocity, in miles per hour, above which the interval of sending frames is constant and equal to the parameter Fast Rate.

Slow Rate

Interval in seconds between subsequent sent frames, when the velocity is below Low Speed.

Fast Rate

Interval in seconds between subsequent sent frames, when the velocity is above High Speed.

Min Turn Angle

Minimal turn angle, above which a beacon is sent regardless of velocity (if it's above Low Speed).

Turn Slope

A factor for reducing sensitivity to low-velocity turning. Arbitrary units.

Min Turn Time

Minimal time which must elapse before another frame can be sent. This parameter protects us from continuous transmission of frames while turning, e.g. while reversing on a roundabout or manoeuvring in a parking lot.

An example implementation of the aforementioned algorithm can be found in Listing 8. The function SmartBeacon is called every second.

Listing 8. An example implementation of the SmartBeacon algorithm

 1: // global variables
 2: int old_angle, secs_since_beacon, current_beacon_rate;
 3:  
 4: void SmartBeaconing (int speed, int angle) {
 5:   int beacon_rate;
 6:    int turn_threshold;
 7:    int heading_change_since_beacon;
 8: secs_since_beacon++;
 9:    if (speed <= LOW_SPEED) {
10:       beacon_rate = SLOW_RATE;
11:    } else {
12:       // Start with turn_min degrees as the threshold
13:       turn_threshold = TURN_MIN_ANGLE;
14:  
15:       if (speed > HIGH_SPEED)
16:          beacon_rate = FAST_BEACON_RATE;
17:       else {
18:          // We're between the high/low limits. Set a between rate
19:          beacon_rate = FAST_BEACON_RATE * HIGH_SPEED / speed;
20:          // Adjust turn threshold according to speed
21:          turn_threshold += TURN_SLOPE * 10 / speed;
22:       }
23:  
24:       // Force a maximum turn threshold of 80 degrees (still too high?)
25:       if (turn_threshold > 80)
26:          turn_threshold = 80;
27:  
28:       // Corner-pegging. Note that we don't corner-peg if we're
29:       // below the low-speed threshold.
30:  
31:       heading_change_since_beacon = abs(old_angle-angle);
32:  
33:       if (heading_change_since_beacon > 180)
34:          heading_change_since_beacon = 360 - heading_change_since_beacon;
35:  
36:       if (heading_change_since_beacon > _turn_threshold)
37:          if (secs_since_beacon > TURN_TIME) {
38:             secs_since_beacon = current_beacon_rate; // extortion send
39:          }
40:       }
41:  
42:       if (current_beacon_rate > _beacon_rate)
43:          current_beacon_rate = _beacon_rate;
44:  
45:       if (secs_since_beacon >= current_beacon_rate) {
46:          secs_since_beacon = 0;
47:          current_beacon_rate = _beacon_rate;
48:          old_angle = angle;
49:          send_beacon(); // real send
50:       }
51:    }
52: }

Summary

Having done all this we have obtained a complete, portable device which, depending on our needs, could be extended with software to implement additional features, not necessarily related with APRS or ham radio. One of alternate solutions for using this electronic circuit could be programming it in such a way that it would play chess with us. Numeric keyboard around the key "5" would be used to move the cursor, with the "5" itself - for grabbing and lowering the pieces. The keys: "*", "0" i "#" could be programmed in any way, for instance to pause the game, undo a move or enter a menu. The serial port could be used to transmit our game to a stationary computer.