My Sagrantino Cup 2020 flights

How to do it

These are GPX files unloaded from my Garmin 695 and processed with gpsvisualizer.com. If you look closely at the end of say, the dark blue track, and click at one of the bullets along the track, you will find this:

This popup shows a speed value (22km/h just before a rather rough landing). Gpsvisualizer needs this speed value to be in the GPX file before uploading – however, Garmin GPX files do not contain this value. Let’s look at a fragment of a GPX file as unloaded from the Garmin 695:

      <trkpt lat="42.761791000" lon="12.408886000">
        <ele>189.036</ele>
        <time>2020-08-06T05:02:47Z</time>
      </trkpt>

No speed value there – just latitude, longitude, time, elevation. However, one can add speed values to a GPX file with the venerable gpsbabel utility like so (I’m using a shell command here, but you should be able to find a GUI version of gpsbabel for your platform):

 $ gpsbabel -t -i gpx -f input.gpx -x track,speed -o gpx,gpxver=1.0 -F output.gpx

After this step, looking at ‘output.gpx’ we find the speed value (6m/s or 22km/h) was added by looking at time and position of neighbouring points:

      <trkpt lat="42.761791000" lon="12.408886000">
        <ele>189.036</ele>
        <time>2020-08-06T05:02:47Z</time>
        <speed>6.152827</speed>
      </trkpt>

And if you get a track from Ultramagic Flightpack..

you are in for a surprise: great application, and the ~~most brain-dead~~ suboptimal track export format in the industry: a KML file which does NOT have a machine readable starting time, nor do the waypoints have timestamps. There is NO way to automatically convert this track to a GPX file with timestamps – you need an editor and look at the file contents to retrieve the starting time and waypoint interval. Let’s look at this beauty:

<?xml version="1.0" encoding="UTF-8"?><kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<name>track 15_08_2019 06_33_21.kml</name>
<description>Track created by Ultramagic FlightPack - Starting at time 15_08_2019 06_33_21 - Sampling period is 3 seconds - Flight duration is 1 h 8 min</description>
<Style id="path0Style"><LineStyle><color>7f00ffff</color><width>20</width></LineStyle></Style>
<Placemark><name>track 15_08_2019 06_33_21.kml</name>
<styleUrl>#path0Style</styleUrl>
<LineString><altitudeMode>absolute</altitudeMode><coordinates>
15.632430883139,48.4467375744585,314.975244567425 
15.632430883139,48.4467375744585,314.918412871592

So the fact that this track starts at Aug 15, 2019 05:33:21 and each point is sampled 3 seconds apart is hidden in a comment – meaning all KML-processing programs will ignore it.

Again, gpsbabel helps into making this mess usable again – it can add ‘fake timestamps’ as starting time and equally spaced for each waypoint – so after getting the clue from above we can do this:

$ gpsbabel -i kml -f 'track_15_08_2019 06_33_21.kml' -x track,faketime=f20190815063321+3 -o gpx -F output.gpx
$ gpsbabel -i gpx -f output.gpx  -x track,speed -o gpx,gpxver=1.0 -F final.gpx

Gpsbabel needs two steps to fix this up. Thereafter, final.gpx looks usable:

      <trkpt lat="48.450746052" lon="15.634726184">
        <ele>517.158</ele>
        <time>2019-08-15T06:42:51Z</time>
        <speed>2.132435</speed>
      </trkpt>

I’ve reported this to Ultramagic last August, asking them to fix it. I got an unpleasant reply. Other than that, Flightpack is still producing nonsense. Thanks, guys!

Next step: visit gpsvisualizer and add all processed GPX files in the list of uploads. Also, set the parameters according to this image: