Numpty's Progress

Interfacing the Pharos GPS-500 to Mac OS X

Posted on 2010/12/20 by scruss

I’m stopping short of calling this “Using the Pharos GPS-500 to Mac OS X” because all I’ve been able to do is read raw NMEA sentences from the device. But that might be of use to you.

The Source is clearing out copies of Microsoft Street & Trips with GPS 2008 for $20. The GPS is a very simple USB Pharos GPS-500, which uses the SiRF III chipset. Between the USB cable and the GPS is a small black box which looks suspiciously like a serial to USB converter. I have no use for the software, but the GPS is a bargain, considering a similar bare unit costs $60.

Plugging it into a Mac does nothing beyond being recognized as a “USB-Serial Controller D” from Prolific Technology, Inc. The ancient driver on Pharos’ website identifies the serial chipset as the Prolific PL2303. The only driver I could get to work with Snow Leopard was the failberg/osx-pl2303, a fork of an earlier project from Sourceforge. You’ll know if it’s working when you get a device called /dev/tty.PL2303-something appear.

Reading the data’s pretty simple if you have GNU Screen installed. I entered the following command:

screen /dev/tty.PL2303-12345678^XX^D?^XX 4800

and very quickly started to get NMEA data scrolling in the terminal:

$GPRMC,003322.000,A,4343.8349,N,07915.8845,W,0.38,112.13,211210,,,A*7B
$GPGGA,003323.000,4343.8351,N,07915.8838,W,1,05,2.8,174.3,M,-35.1,M,,0000*65
$GPGSA,A,3,09,18,14,21,22,,,,,,,,6.9,2.8,6.3*34
$GPRMC,003323.000,A,4343.8351,N,07915.8838,W,0.89,122.04,211210,,,A*76
$GPGGA,003324.000,4343.8351,N,07915.8843,W,1,06,1.5,176.0,M,-35.1,M,,0000*62
$GPGSA,A,3,27,09,18,14,21,22,,,,,,,3.4,1.5,3.1*30
$GPGSV,3,1,12,18,78,082,28,22,61,307,27,09,56,076,30,27,40,053,19*7F
$GPGSV,3,2,12,14,38,254,18,21,32,180,21,15,27,062,16,26,12,059,*7E
$GPGSV,3,3,12,19,10,302,,12,07,119,,06,04,261,,03,02,272,*7E

To stop screen, type Control-A Control-\. Do not just unplug the GPS, as you risk your machine crashing.

These NMEA sentences can easily be converted to GPX.

Posted in GIS | Tagged gps, microsoft, nmea, osx, serial, usb | 4 Comments

Magellan Triton 400 micro-review

Posted on 2010/12/13 by scruss

My office’s Garmin was stuck in a branch office last week, and we needed a GPS for the next morning, so we got a cheapo Magellan Triton 400 for $90 at Future Shop. I think that’s a clearance price, and none of the big-box retailers still carry it.

The Triton 400′s a Windows CE unit with a surprisingly good display for the price. I only had a little time to set it up and test it briefly outside the office, so all I can do is give you is first impressions.

Pros:

Cheap!
SIRFstarIII chipset for reasonably fast/accurate acquisition
SDHC card (worked with my 4GB card)
Bright display
Works with GPSBabel (as Magellan’s VantagePoint obviously installs a copy)
Doesn’t route

Cons:

Wouldn’t acquire any position until I updated the firmware (at which time I discovered that it basically updates a full Windows CE image from an archive)
Weird proprietary USB cable
Tiny buttons that aren’t very positive
Eats batteries
Overly simplistic menu structure makes it hard to set up
VantagePoint is buggy, and will repeatably crash under certainly (admittedly rare) menu items
Only works under Windows; the USB protocol is proprietary
Hard limit of 5000 points per track, and track logging stops when this limit is reached
SD card is only usable for maps and geotagged photos, not track storage.

I should be able to play with it in more detail in the new year. It was cheap, but not all cheap things are good.

More on the Magellan – OpenStreetMap Wiki page.

Posted in GIS | Tagged gps | Leave a comment

Got a receiver inside my head – writing Spectrum Direct data as CSV

Posted on 2010/10/29 by scruss

Industry Canada publishes the locations of all licensed radio spectrum users on Spectrum Direct. You can find all the transmitters/receivers near you by using its Geographical Area Search. And there are a lot near me:

While Spectrum Direct’s a great service, it has three major usability strikes against it:

You can’t search by address or postal code; you need to know your latitude and longitude. Not just that, it expects your coordinates as a integer of the format DDMMSS.
It’s very easy to overwhelm the system. Where I live, I can pretty much search for only 5km around me before the system times out.
The output formats aren’t very useful. You can either get massively verbose XML, or very long line undelimited text, and neither of these are very easy to work with.

Never fear, Perl is here! I wrote a tiny script that glues together Dave O’Neill‘s Parse::SpectrumDirect::RadioFrequency module (which I wonder if you can guess what it does?) to Robbie Bow‘s Text::CSV::Slurp module. The latter is used to blort out the former’s results to a CSV file that you can load into any GIS/mapping system.

Here’s the code:

#!/usr/bin/perl -w
# spectest.pl - generate CSV from Industry Canada Spectrum Direct data
# created by scruss on 02010/10/29 - for http://glaikit.org/

# usage: spectest.pl geographical_area.txt > outfile.csv

use strict;
use Parse::SpectrumDirect::RadioFrequency;
use Text::CSV::Slurp;
use constant MINLAT => 40.0;    # all of Canada is >40 deg N, for checking

my $prefetched_output = '';

# get the whole file as a string
while (<>) {
 $prefetched_output .= $_;
}

my $parser = Parse::SpectrumDirect::RadioFrequency->new();

# magically parse Spectrum Direct file
$parser->parse($prefetched_output) or die "$!\n";
my $legend_hash = $parser->get_legend();    # get column descriptions
my @keys        = ();
foreach (@$legend_hash) {

 # retrieve column keys in order so the output will resemble input
 push @keys, $_->{key};
}

# get the data in a ref to an array of hashes
my $stations = $parser->get_stations();

my @good_stations = ();

# clean out bad values
foreach (@$stations) {
 next if ( $_->{Latitude} < MINLAT );
 push @good_stations, $_;
}

# create csv file in memory then print it
my $csv = Text::CSV::Slurp->create(
 input       => \@good_stations,
 field_order => \@keys
);
print $csv;
exit;

The results aren’t perfect; QGis boaked on a file it made where one of the records appeared to have line breaks in it. It could filter out multiple pieces of equipment at the same call sign location. But it works, mostly, which is good enough for me.

Posted in GIS | Tagged csv, industry_canada, locations, perl, radio, spectrum | 1 Comment

making of the Canada Day post

Posted on 2010/09/15 by scruss

Making the My Neighbourhood, Canada Day 2010 post took a bit of planning.

Hardware

I attached an Ultrapod to the stem of my bike, and added another velcro wrap for security. The GPSMAP 60CSx fitted quite nicely under the bungees on the rear rack. The Ultrapod didn’t quite have enough stability to stay in place without drooping sometimes. I bought (but haven’t tried) the KODAK Adventure Mount, which might be more stable.

The Camera

… is a fairly basic Canon PowerShot SD790IS. What’s important is that it can run CHDK. I’d set it to take a 6MP picture approximately every 20s using the Ultra Intervalometer script.

Synching the camera to the GPS for geotagging

At the end of the trip, I took a picture of my GPS clock screen:

and then compared the time to the camera’s timestamp using jhead:

$ jhead IMG_0316.JPG
 ...
Date/Time    : 2010:07:01 16:59:50

So if the GPS time is 16:58:55, we need to subtract 55s from the camera time to make them match:

$ jhead -ta-0:00:55 IMG*JPG

And let’s check the result:

$ jhead IMG_0316.JPG
 ...
Date/Time    : 2010:07:01 16:58:55

Perfect.

Geotagging the pictures

I used ExifTool. You could also use Prune if you prefer something more graphical. Exiftool does this with minimal fuss:

$ exiftool -geotag canadaday2010-0.gpx IMG_0*JPG

(I realize I could have used exiftool instead of jhead for the timestamp check, but I’ve been using jhead for about a decade, so I know it well and like its compact output.)

You probably want to make use of a WordPress plugin like Add From Server to speed the upload process.

Adding the OpenStreetMap map

The www.Fotomobil.at » wordpress openstreetmap plugin is very flexible, but rather complex to work with. Here I’m calling the map with both markers (and lots of them) and a GPX trace:

[ osm_map lat="43.729" long="-79.275" zoom="14" width="640" height="480" marker_file="http://glaikit.org/wp-content/uploads/2010/07/canadaday2010marker.txt" gpx_file="http://glaikit.org/wp-content/uploads/2010/07/canadaday2010.gpx" ]

(Note that in the example, in order to stop WordPress from interpreting the shortcode, I’ve had to introduce a space after the [ and before the ]; in real life, they’re not there.)

The gpx file is just plain vanilla (canadaday2010.gpx) but the marker file (canadaday2010marker.txt) is a bit special. I must admit to have slightly misused the format, as I discovered that the fourth column, the description, is free-form HTML. As the default is to popup a small image thumbnail, I wedged in code to link to the full-sized image when the thumbnail was clicked. This required me to work out what attachment ID WordPress thought each picture would be. If you’re careful to upload sequentially to a single-user blog installation, you should be okay hitting the right links.

Each line of the marker file was made with a (loooong) shell one liner, an unholy mess of backticks and awk. I’m glad I can’t find it. It really wasn’t pretty at all.

Posted in GIS | Tagged bicycle, exiftool, gps, openstreetmap, toronto, wordpress | 1 Comment

Mac OS X killed my Garmin!

Posted on 2010/09/15 by scruss

My GPSMAP 60CSx had started to become unreliable: crashing after startup, randomly locking up in mid route, and just generally being an aggravating piece of kit. I was really close to replacing it.

The problem seemed to appear after I’d used USB Mass Storage to transfer archived track logs to the computer. As a last resort, I tried removing the hidden files that OS X creates on every removable disk, and now all is well. It’s annoying and inexcusable that Apple chooses to do this, but we work around.

To delete these files from the terminal and eject the device safely, enter these commands:

pushd /Volumes/GARMIN/
rm -rf .Spotlight-V100 .Trashes ._.Trashes .fseventsd
popd
disktool -e disk1

Your device might not be called /Volumes/GARMIN/, so check and change appropriately. If you have multiple drives on your machine, your GPS is probably not the disk1 device. You can find out which it is by entering disktool -l.

Posted in Uncategorized | Tagged garmin, gps, osx | 10 Comments

probably wouldn’t recommend the Blackberry Tour as a GPS logger

Posted on 2010/08/21 by scruss

I walked a local footpath carrying my (mostly) trusty Garmin GPSMap 60Csx, and a Blackberry Tour running bbTracker. Both had had a good satellite fix for about 10 minutes beforehand, and both were logging trackpoints every second. The smooth turquoise track from the Garmin is much more useful than the wibbly one from the Blackberry.

Posted in Uncategorized | Tagged blackberry, garmin, gps | 1 Comment

fallout from last night’s OSM 6th birthday Mappy Hour in Toronto

Posted on 2010/08/21 by scruss

It was fun – there were geo-aware cupcakes!

It is very easy to lose days in the David Rumsey Historical Map Collection.
Richard’s OpenStreetMap for the Beginner tutorials are actually really really good.

In a moment of geek worlds colliding, Emma showed up, and now I have people clamouring for tablet at Mappy Hour. Sigh, those old ecommons links just don’t fade …

Posted in Uncategorized | Tagged map, openstreetmap, toronto, tutorial | Leave a comment

proj.4 init annoyances: it’s all apple’s fault

Posted on 2010/08/08 by scruss

I was going to write a rant about how Ubuntu sets up proj.4 init files incorrectly, then I found that the problem actually lies with OS X. OS X is unusual for a Unix variant, as it uses a case-insensitive file system; flarp.txt is the same as FLARP.TXT. Under more traditional Unices, they’d be different files.

Most of the examples on this blog were written under OS X, and I was concerned when they didn’t work under Ubuntu. It seems that proj.4 uses a very simple way of defining initialization files. If you specify, say, “+init=EPSG:2958″, proj digs around in its configuration files for a file called EPSG, then searches for an identifier in that file which matches the ID 2958. Under OS X, you can specify EPSG, epsg, or even EpSg – they all work. Under Ubuntu, using anything other that epsg fails with this message:

<proj>:
projection initialization failure
cause: no system list, errno: 2

In short, use lower case init specifications, and it’ll work everywhere.

It seems that there are some other applications (mapserver?) that have problems calling proj, so if you’re seeing this error and it’s not something you can correct from the command line:

Find out where your installation keeps its initialization files. You can do this by setting PROJ_DEBUG=1:
PROJ_DEBUG=1 proj +init=epsg:2958
and you should get a message like:
pj_open_lib(epsg): call fopen(/usr/share/proj/epsg) - succeeded
cd /usr/share/proj (or wherever the last command said the epsg file was located)
sudo ln -s epsg EPSG

Now your installation should work no matter which case you use. Camel case, unfortunately, excluded.

Posted in GIS | Tagged epsg, osx, proj, ubuntu | Leave a comment

in which I discover OpenStreetMap editing

Posted on 2010/07/28 by scruss

While I’ve used OpenStreetMap data before, I’ve never added anything to it. That changed after going to Mappy Hour last night, and meeting Richard Weait. He has a bunch of useful tutorials on his website.