Posts Tagged ‘GPS’

Adventures In Ubuntu, VMs, and GPS

21 April 2016

NERD ALERT:  Nerdy talk follows!

Since I switched my HP laptop to Ubuntu Linux, I have made a fairly smooth transition in terms of software. I can get company email via webmail (using a security token for the connection), even though the webmail is Microsoft Outlook Web Access and the browser is Chrome. In the past couple days, I’ve used LibreOffice to build briefings, create documents, and read stuff for work, used various Google apps to transfer files around, and generally had a problem-free transition. There are a couple nits. One thing that sounds silly, I edit pictures quite a bit. In Windows, I could use Paint to add text and draw lines that are pointers. In Linux, GIMP does the text just fine, but it doesn’t draw lines. I’ll figure that out.

The one thing that’s weird is working with GPS files. I do a lot of GPS work for planning hiking and backpacking, and then downloading the saved tracks from the trips. Those require a bit of editing to clean them up, join tracks from each day, and the like.

We just got back from a nice trip to Eastern Oklahoma, and it was a bit of an effort to get the tracks out of the two GPS units. I carried a Garmin GPSMap60, and Ian carried a Garmin GPS62s.

I’ve tried a couple Linux tools to extract the tracks (via a USB connection), and had trouble getting them to recognize the devices. I also tried to install the Garmin Basecamp tool I’ve used forever using Wine, and had no luck. One tool (QmapShack) I tried to install from source, and between requiring a specific version of cmake and other oddities I couldn’t get it to work. I tried installing the Windows version, but it requires the Visual C redistributable, and that wouldn’t install. So that was just Too Hard.

BTW, the command I used was:

gpsbabel -t -i garmin -f usb: -o gpx -F [trackname.gpx]

In the end, I decided to use the Basecamp tool that was in the Virtual Machine of my previous HP 6930p, which I had brought into Virtual Box under Ubuntu. The problem was trying to get the GPS tracks to the VM. I tried some stuff to make the GPS units visible to Basecamp under VirtualBoxm, no way. With the 60, it took an obscure command line using GPSBabel (which was installed on the computer when Ubuntu was installed to get the track data our and into Linux. The same didn’t work for the 62s. Turns out the 62s mounts as a USB stick as far as Ubuntu is concerned, and the track data is in a folder a couple levels deep.

So now I had the files, but still needed to get them to Basecamp. USB sticks were tried with no luck. I’m pretty sure the stick(s) were visible to the VM, but they didn’t show up.

In the end, it took a roundabout way. My laptop had Apache installed on it. I made a connection to WiFi (that got an IP address for the laptop). Then I copied the two GPX files to the root of the web server and started Apache. I went to the VM, fired up a Windows command prompt, and could ping the IP address the laptop had from the WiFi. I fired up Chrome, typed the IP address, added the filename of each GPX. That got them downloaded.  They came in from Chrome with an additional xml extension (so they look liker gpsmap60.gpx.xml), but a rename fixed that.

Then I fired up BaseCamp and imported the tracks, and editing worked well.  Once the tracks were in and edited, I displayed them on a topo map, and as an altitude plot.  In both cases, I did a screen capture of the display that included the Windows VM, and the capture was saved in the pictures folder of the Linux box.  From there, I brought the captures up in GIMP for annotation, and from there they went to Google+ with the photos I took on the hike.

This was all pretty cool and easy for me, but I think for a non-geek it would have been sorta hard.

GPS Comparison Testing

29 October 2015

This past weekend, I took a group of Scouts from Troop 15 on a 10-mile hike for the Hiking Merit Badge. We went out to Lake Thunderbird State Park, where there are a number of hiking/biking trails that total just under 20 miles.

One of the things I wanted to do was check out the GPS capabilities of several of the units. When we go on these hikes, we typically start a GPS, and hike until it shows 10 miles.

I also had a secondary objective, which was to check out my Garmin GPSMap 62s battery usage. We had taken that unit to our backpacking trip in Colorado, and it seemed to use an entire set of batteries in less than a day. My GPSMap 60 usually gets about five days of use out of a battery pair. In this case, I completely reset the 62s, put in fresh batteries, and at the end of the day, the battery indicator showed full. So that was probably the issue.

Anyway, I tested the following units: Garmin GPSMap 60 and 62s, a Samsung Galaxy S6, and a Google Nexus 5. Both of the phones ran Runkeeper.

Our hike was over a trail network that has a significant amount of weaving in and out, in order to maximize the mileage in the limited surface area.

At the end of the hike, these were the mileages displayed:


Unit       Displayed   GPX   Points Captured
GPSMap 60:     10.02     9.7   1148
GPSMap 62s:   9.97   9.5   1748
S6:           9.90   9.9   1604
Nexus:         8.20   8.2

These results are pretty annoying to me. I’ve noticed the GPX track shortage (by way of example, displaying 10.02 while the downloaded GPX is 9.7) numerous times over the years, but I do not understand why it should be.

The difference is particularly pronounced in the GPX for the 62s. It’s a newer unit, and it has a setting to control the granularity of the data taken. For this hike, it was set to the most granular setting, and generated the largest number of data points, but the reported GPX is a half mile less, which is 5% and significant. I suspect that the better granularity of the 62s is the “real” mileage, as it would capture the numerous sharp bends in the trail network. But that is contradicted by the significantly shorter length of the GPX.

Note the very short mileage for the Nexus. We noticed the mileage displayed being less and less of the other units. Ian checked out GPS settings, and found a power-saving mode that was set that limited GPS update.

Have a look at the ground tracks. Here is an overlay of the tracks of the two phones:

S6 and Nexus 5 Tracks

S6 and Nexus 5 Tracks

You can see that the S6 (green track) and the Nexus (red track), are close together for a bit, then they diverge (the series of straight red lines), then come back together again. It’s easy to see where the longer green tracks near the straight lines are the source of the mileage difference. The question is, why did the first mile+ match up very well, then diverge?

Here are the overlays of the tracks of the 60 (green), 62s (dark), and the S6 (red) (I did not include the Nexus track due to the divergence):

Hiker and phone GPS overlaid

As I look at the tracks, I see about six areas where the green track diverges (in some places, significantly) from the other two tracks, adding mileage to the total. The 62s and S6 tracks (and most of the Nexus tracks) are very, very close.

My conclusion is that the newer GPS units are closer to showing true mileage.

I also looked at the altitude displays. These trails were fairly flat (relatively! 🙂 ). I used Mapsource to generate altitude plots and captured them as identically-sized jpegs, but there wasn’t an easy way I could see to merge them together (I tried GIMP). So instead, I exported the altitude data to an Excel spreadsheet. The number of data points didn’t match, so I wrote a q&d program to read in the data points, and insert an identical value every x lines. That got the dataset lengths pretty close. Then I imported them back into Excel and ran an XY plot:

Altitude_Comparison

I noted previously that the altitude recorded by the GPSMap 60 is way spiky. The 62s are as well, but less so. The altitude differences between the two Garmin units is significant. Three notes: the 60 tends to show altitude significantly less than the 62s for the most part (there are only two places where the altitudes match, and the altitude is 40 or so feet less than the 62s); the altitude shown by the 60 lags the 62s by some amount, and the altitude for the last couple miles is really, really off.

The altitude recorded by the S6 is closer to the 62s altitude, and also lags the 62s, but in both cases not as much as the 60. The S6 is almost smooth, not spiky.

I am going to take the units out in a car and drive about 10 miles and check the odometer reading against the GPS display and GPX. I will report on that after I do it.

I think I need to take all four units in a straight-line test to see how those mileages compare.

Using GPS to Track People

7 August 2010

The Washington Post had an article yesterday about an appeals court ruling:

http://www.washingtonpost.com/wp-dyn/content/article/2010/08/06/AR2010080604946.html

The case involved a guy suspected of something (the article does not say what). The police put a GPS tracker on the guys car, with a warrant approving doing so, but left the device on after the warrant had expired.

The key thing here is the warrant. The police have to have a reasonable suspicion that a crime has been committed before doing unlimited surveillance, and if it was that important, they should have been able to make the case to the judge to extend the warrant (I think there is a lot of judicial rubberstamping going on as it is).

While the police argument is that they could have just tailed the guy around, and the GPS is just like another officer, that argument is specious. The GPS device could have been removed and put on another car for a period of time without the police knowing. It could even have been tampered with to put different data into it (you have to be able to download the data, and if you can download, you can upload as well).

My bottom line on this, if the cops can track a suspect for weeks or months without a warrant, they can do it to anyone. I would question what value the GPS device brings anyway. They don’t work well in cities, parking garages, under thick trees, tunnels, etc.: the accuracy of the device degrades quickly as the number of satellites it can see drops.

If a crime requires that a person be tracked, better to put a set of training eyeballs on the job instead of a piece of electronics. Our protection of liberty demands no less.