There are a host of factors that contribute to data loss in APRS, to name just some:
- non-standard / sub-standard / poorly configured digipeaters;
- defect ridden iGates that lose, duplicate and corrupt packets;
- poorly configured mobiles;
- network congestion and interference;
- unpredictable equipment failures;
- basic geographical coverage of the network; and
- dependence on the ionosphere for HF APRS.
This article describes an enhancement to the popular TinyTrak (and its clones) to also capture the GPS stream to an inexpensive local data logger.
The logger does not interfere with normal radio APRS, it coexists with it and creates a properly timestamped fine detail log of positions over a very long time, a log that can be post processed into a range of graphic / map and tabular reports.
The datalogger used in an OpenLog. It is a simple logger that writes data to a micro SD card, costs about $A12 (inc post) for the logger and about A$10 (inc post) for a 16GB Class 10 micro SD card. (A slower card could be used, but they aren’t much cheaper.)
Above, the OpenLog data logger.
Blackbox flight data recorder
The logger purchased on eBay was a Blackbox flight data recorder. It is OpenLog hardware with a customised firmware for UAV logging, and comes cheaper than OpenLog labelled product.
For this project, I have used OpenLog_v3_Light, built from the latest source and libraries. OpenLog_v3_Light trades the command interpreter facility for increased buffer space which reduces the risk of data overruns. The changes include compatibility with the latest SdFat and SerialPort libs.
The new hex file is loaded using the installed Optiboot loader, AVRDUDE is used with a serial adapter to write the flash image to the OpenLog. (Remember to reset to activate the bootloader.)
The OpenLog should be supplied with Arduino bootloader installed and lock bits set to protect it… but you never know what comes out of China.
avrdude -p atmega328p -c arduino -P COMx -b 115200 -D -U flash:w:OpenLog_v3_Light.hex
Most TinyTrak’s will use a 4800Bd interface for the GPS, in which case copy the config file (link to zip below) to the root directory of the SD card and insert it in the OpenLog (cycle the power first time so that any changes take effect).
In this example, the hardware is a Foxtrak with TT3+ chip on board.
Above is a pic of the data logger cable connections to the tracker chip. The cable is routed along a smooth part of the board under the chip and held in place with a small dot of hot melt adhesive. The cable exits the tracker case and plugs onto the OpenLog.
The Foxtrack input circuit is very simple, and essentially the signal on pin 3 is /TD and requires inversion for the external logger which like most TTL RS-232 interfaces expects non-inverted TD. The solution is a FET inverter with ‘open collector’ output.
The inverter is so simple that it can conveniently be incorporated in the cable to the logger. Above, a 2N7000 is connected source to -ve, gate to signal from MCU and drain to the output signal wire. A dot of hot melt glue and some heatshrink protects the inverter physically and electrically and it is tucked inside the Foxtrack enclosure.
Above, the OpenLog wrapped in heatshrink to protect it. A dot of velcro is used to secure it to the Foxtrack case.
Of course an ordinary FTDI USB-TTL RS232 adapter could be used to log the data to a computer.
GND OpenLog (1) – chip (5), 5V/Vcc OpenLog (3) – chip (4),RXI OpenLog (5) – chip (3).
The simplest way to process the log is to remove the SD card, mount it on a computer and copy the data, then delete the SD log to free up space.
Data logged will depend on the NMEA sentences enabled in the GPS, but budget for up to 1kB per second which means towards 3GB for a month of full time recording.
If just the $GPRMC and $GPGGA are logged, budget on 150B/s average, around 400MB for a month of full time recording.
There are lots of apps for processing GPS NMEA logs and converting them into all manner of formats.
Above is an overlay of the capture from the datalogger and the data simulaneously captured by APRS (from aprs.fi) of a ‘drive around the block’. This is within 20km of a digipeater on a prominent hill top, channel activity was very low, coverage is fairly good, and the digi could be heard well around the entire trip (it has a distinctive sound due to its gross audio overdrive). The VHF tx was using 65W to a quarter wave in the roof of the car. The more complete data of the OpenLog capture is obvious.
The Tinytrak rounds uncompressed positions to hundredths of a minute, or 0.000166° (about 20m latitude) whereas my GPS supplies positions to 0.000001°. Now that improved precision does not directly translate to accuracy, but more of the direct NMEA track spots coincide with the Google Maps satellite image so it is usefully more accurate, but not 166 times more accurate.
The APRS track was saved from aprs.fi (click on the Google Earth KML view), and the OpenLog capture was uploaded to GPS Visualizer and saved to Google Earth format.