U-BLOX LEA-6T GPS module – for experiments

This article documents a LEA-6T module build for general experiments.

The LEA-6T is an inexpensive GPS module (~$40 at time of purchase, but getting cheaper) that can supply raw pseudo range data.


The module above is supplied for use on UAVs of various kinds, and came complete with a plastic radome and cables to suit an APM copter. The module also contains a 3D compass (magnetometer) which is not used here.


Above is the internals of the module with a custom cable to pick up just the RS232-TTL signals from the GPS (and supply 5V). The connector is a 8pin Hirose DF13. Continue reading U-BLOX LEA-6T GPS module – for experiments

APRS duplicate removal – trial #3

The undetected long-delayed duplicate posits that are a feature of APRS VHF are a significant corruption of mapping.

In an attempt to limit the propagation of posits and hence the probability of corruption / delay etc, I have experimented with a path of WIDE1-1 on a recent trip to Canberra (about 400km for the round trip).

Whilst this should prevent packets getting to the Wagga, Newcastle and Tamworth regions which have been the main cause of corrupted posits and mapping defects, it does so at the risk of some loss of posits as some digi infrastructure was never updated to the “New N paradigm” of more than a decade ago and they ignore WIDE1.

Screenshot - 06_03_16 , 14_15_51

Above is a zoomed in view of the Canberra end of the trip, and I am pleased to say that the zig zag double backs that have been evident in recent trips did not occur. The principal reason is that with a path of WIDE1-1, the packets did not pass through VK2RWG-1/VK2KAW. Continue reading APRS duplicate removal – trial #3

APRS duplicate removal – trial #2

The undetected long-delayed duplicate posits that are a feature of APRS VHF are a significant corruption of mapping.

Program code has been written to collect posit records direct from APRS-IS and where the record contains a HMS timestamp (as mine do), to apply a timestamp consistent with that timestamp, and then to not write records with duplicate timestamps to the database.

Screenshot - 04_02_16 , 15_57_38

The above map has two journeys, one a loop to the north of home to Mittagong, and another SW to Marulan and back. The Marulan trip extended to 40km from the prominent digi VK2RHR-1, and coverage in the area became poor, evidenced by the poorer APRS mapping in that region.

The map can be browsed interactively at http://owenduffy.net/map/20160204.htm. The red trace is APRS VHF derived using the processing detailed below.


The cyan trace is from stand alone GPS logger above attached to the case of the TinyTrak 3+. The transmitter is 65W output to a quarter wave in the middle of the wagon roof. Continue reading APRS duplicate removal – trial #2

APRS duplicate removal

I have written about duplicate position records assigned different timestamps in the APRS – APRS-IS – archiver network, and the corruption of mapping as a result of false timestamps which causes zig zags in the mapping.

Most recently, I demonstrated that at APRS – APRS-IS latency.

I have been challenged that this just does not happen.

As a by product of developing code to circumvent the defects in the design and implementation, I have been running a rover stationary on the driveway during the day to supply test data to the filtering code, and of course these exceptions have occurred.

Here is an extract of the raw packets log from aprs.fi for just one case.

2016-01-26 16:20:25 AEDT: VK2OMD-8>APT314,WIDE1-1,WIDE2-2,qAR,VK2OMD-3:/052024h3429.91S/15027.12E>110/000/A=002263
2016-01-26 16:23:17 AEDT: VK2OMD-8>APT314,VK2RHR-1,WIDE1,VK1RGI-1,VK2RWG-1,WIDE2*,qAS,VK2KAW:/052024h3429.91S/15027.12E>110/000/A=002263

Inspection will reveal that both records have the GPS derived timestamp 052024h, and the message contents are identical, they are both a result of a single posit report at 052024UTC, the relay via VK2KAW has been assigned a timestamp some 173s (almost 3m) later and were the rover moving, this corrupted report would cause a track back and the next valid report would leap forward.

In six hours of operation, there were 36 posits transmitted, and 11 corrupt posits via VK2KAW logged by APRS-IS, that is 31% of valid posits have a false and corrupted posit generated in the wider network.

APRS fails by design, the core infrastructure does not detect these anomalies and discard them. Note that this scenario is ONLY provable because the tracker sends the HMS format timestamp… which almost no-one does.

This is only one source of corruption of posits, vulnerability to this one is designed into APRS, but it is detectable and fixable in core infrastructure.


APRS – APRS-IS latency

A fundamental problem with APRS-IS is that archives assign a timestamp to a position report (posit) when the posit is received from the APRS-IS network. They do this even when the posit contains a timestamp which is almost always derived from the GPS and is quite accurate.

The archives such as findu.com and aprs.fi are not formally part of APRS-IS, but they are the visible interface to APRS-IS for many and are treated as part of the wider APRS-IS network in this article.

The APRS-IS network is designed to permit, encourage even, multiple submissions of the same originating posit via multiple iGates over multiple digipeater radio links.

You might expect that the maximum latency of two or three digipeater links might be a couple of seconds but not only is it ordinarily longer than that due to an overcommitted network, but defective infrastructure using old and misconfigured software can introduce much larger delays.

The effect of delayed duplicates is that they create false back and forth zig zags in a track, and make the mapping hopelessly inaccurate.

For this article, I will use data gained from a recent 100km rural trip using VHF APRS. For all of the trip, the rover was in range of a prominent digipeater which is monitored by many iGates, and for about half of the trip, the rover was in working distance of one of the iGates. About 200 posits were captured by APRS-IS, and they have a GPS derived HHMMSS timestamp.

Lets look at the latency.

Clip 114

Above is a chart of the difference between APRS archive timstamp and the GPS timestamp. A very large number of posits takes more than a couple of seconds to reach the APRS-IS archives. Continue reading APRS – APRS-IS latency

Canberra trip – APRS / GPS logger

I had occasion to make a trip to Canberra for a few days this week.


It presented as a good opportunity to explore APRS by VHF radio and the stand alone GPS logger above attached to the case of the TinyTrak 3+. The transmitter is 65W output to a quarter wave in the middle of the wagon roof.

Over the three days, the extract from findu was 6240 APRS records (the vehicle was in a covered car park by night), and 389693 NMEA records (~20MB) logged to the logger, from which 6150 track records were extracted using GPSBABEL for track simplification. Both track sources were converted to kml files.

googleearth 14/01/16 , 07:57:54 Google Earth

Above is a screen shot comparing the track around Majura park for GPS logger in red and APRS in cyan. There are several instances of false double backs on the APRS track (a problem inherent to APRS and quite common), and very coarse track despite being less than 8km from the prominent digi on Black Mountain, and very good view of the digi on Mt Ginini.
Continue reading Canberra trip – APRS / GPS logger

Trial of prototype stand alone GPS logger

An upcoming project calls for a stand alone GPS logger.

The requirement is for a GPS stream that allows correction using RTKLIB, but this trial is of a lesser GPS as proof of concept.


Above, the equipment consists here of a Ublox NEO-6M based GPS module (~A$15 incl on eBay) at left, an Openlogger (~A$15 incl post on eBay) at right, and a 12V-5V converter (~A$7 from Hobbyking) at bottom. The latter is a 5A converter, way overkill, but it was on hand. The GPS module has a 3V regulator on board for the NEO-6M chip.
Continue reading Trial of prototype stand alone GPS logger

Backtracking in APRS

Always interesting to look at glitches on APRS maps and investigate the cause. In this case, a local NMEA log provides evidence that the APRS track is faulty.

googleearth 14/11/2015 , 12:18:38 Google Earth

Above is an image of a track, red is from APRS and blue from a local NMEA capture.  Two ‘backtracks’ are evident on the red trace and not on the blue trace, they are artifacts of the design of APRS. Continue reading Backtracking in APRS

Mapping trips from APRS archives

I recently created a map from APRS archives of a recent trip by some friends over about eight weeks through central and north west Australia and back by the southern coast.

Google Earth googleearth 01/11/2015 , 08:43:23

Above is a graphic of the created map, but the ‘real’ map is not simply an image, but it is a kml file for Google Earth which you can view / zoom / scroll, for example in Google Maps by clicking on the map above.
Continue reading Mapping trips from APRS archives

Zig zags in APRS tracks

There are many causes of zig zag errors in APRS tracks, and they fall generally into two main categories:

  1. incorrect positions (ie the tracker was never there); and
  2. correct positions with incorrect timestamps.

The first is common and has a number of causes, but principally defects in software used in iGates, most of which is not maintained either by the iGate operator or original developer. APRS is pretty static, but most old software has significant defects.

The second category is again common, and mostly the result of the design of the APRS radio network and its vulnerability to network delays (some of which can be caused by defective equipment).

This article looks at a case in the second category where a vehicle appears to have done a U-turn on the highway, travelled back some distance then another U-turn and caught up their original track speed at the next posit. It is clearly an out of order packet. This article shows how to diagnose the cause from the raw packet log for the tracker.


Screenshot - 30_10_2015 , 08_36_44

Above is a map of the glitch that is not uncommon in APRS for one of several reasons. No, VK2HJ has not done U-turns on the highway, the zig zag track is incorrect. Continue reading Zig zags in APRS tracks