GPSBabel, MacOS X and a Marine User

Overview

For some time I had been looking for an application, which would allow me to generate, manage and load waypoint information for my Raymarine RayNav 300 navigator. The problem is that many applications designed for marine GPS use are chart plotting as well as GPS management. While this added functionality might be useful it really was unavailable to me due to the lack of reliable chart data in a format suitable which covers my sailing area (coastal Australia). So when I saw GPSBabel on sourceforge.net I thought this might be the answer.

Details

When passage planning the traditional method is to work out the legs of each section of the voyage and plot them on the appropriate scale charts (marine maps are called charts for you landlubbers). Special attention needs to be paid to passage timing, tides in effect at the proposed time as obstructions/shallows, which may present themselves at low tides (drying heights etc). Once a safe path is laid in and appropriate clearances are allowed for then waypoints can be selected on the path, which provide interim points of navigation. This is where an easy to use tool will speed up the process. Most GPS hardware has a user interface that really is barely useable when it comes to waypoint entry. This process can be error prone and that can be very dangerous when coastal cruising. This is where some assistance can be really helpful.

I chose to enter the waypoints in a spreadsheet in the format:

 

Waypoint Location

Latitude

Longitude

Notes

Name

Hastings Channel

38 19.50 S

145 13.35 E

Marina channel entrance

WPT001

WP Channel #23

38 21.40 S

145 14.10 E


WPT002

WP Channe #17

38 24.15 S

145 14.95 E


WPT003

WP Channel #13

38 26.00 S

145 12.95 E


WPT004

WP Channel #7

38 27.40 S

145 09.35 E


WPT005

WP Fairway

38 30.45 S

145 05.30 E

Fairway marker buoy

WPT006

Cape Shanck

38 30.85 S

144 53.20 E


WPT007

 

Table 1. Waypoint data in spreadsheet

 

The waypoint location is a memory aid for me about where the waypoint is located. The latitude and longitude are pretty obvious but there is a warning about these points. Care must be exercised due to datum shifts.

Marine charts are published in varying chart datums. Generally in Australia there are 2 major types of charts. More recently produced/updated charts have been converted to metric soundings and use the WGS84 chart datum for latitude and longitude. Older charts have soundings fathoms (1 fathom = 6 feet) and the chart datum can be varied but are generally not WGS84. This requires the user to make adjustments to latitude and longitude data taken off the chart before entering this data into a GPS. Generally these correction factors are noted on the chart and can be manually added to any readings taken off the chart.

The notes are used for anything of interest about the waypoint location. Last the Name is a waypoint identifier, which is appropriate for the GPS hardware. I serialize mine and over time this may change but at this point they are automatically generated by the spreadsheet. This format allows me to print off a copy of my current waypoint list and keep it at the navigation station on the boat.

At this point you may be wondering that what I've described seems a bit antiquated given the availability of modern GPS hardware with embedded charting applications. The problem is that these charts while useful are not the legal charts as far as marine authorities are concerned. The Australian Hydrographic Office (HO) maintains the official charts covering Australia. This group is part of the Royal Australian Navy and is tasked with carrying out all the work associated with chart maintenance and publishing. This chart data is available in several different formats. First are the traditional paper charts that marine users have been using for a very long time. These products are the results of the HO's cartographic expertise in presenting an enormous amount of information in a clear and concise and internationally recognised way. These paper charts are available at a large number of outlets around Australia and therefore are easily obtained. A very workable 'low-tech' solution.

The HO has more modern solutions that are geared to the commercial user and these are the Raster Nautical Chart series (RNC) and the vector Electronic Charting and Display Information System (ECDIS) (an international standard from the International Maritime Organization) compliant data sets. Because this data is used by commercial concerns the HO has to certify correct operation and presentation of data in any system that uses its data so a licensing scheme has been implemented which ensures compliance. The only problem for recreational sailors like myself is that this adds significantly to the costs associated with using official data sets. In some ways I envy the US sailor due to the availability of official chart data in BsB formatted data sets at very low cost!

This is all-important as it is a requirement that maritime users must have 'official' charts for the areas in which they are sailing. If you have an accident without the appropriate chart information you can be held responsible for what amounts to 'negligence'. C-Map and Navionics charts notwithstanding only HO charts are recognised by maritime authorities.

Virtually all GPS hardware designed for the maritime user (except for low end consumer units) support the NMEA interface specifications for waypoint uploading/downloading. This allows the GPS to provide data for other maritime systems (radar and autopilot) as well as receive information from other instruments (depth, speed, wind strength/direction, water temperature). This is accomplished via the NMEA serial interface specification. This specification defines the electrical as well information structure passed over the interface. The information is defined in a sentence structure and is a unidirectional protocol. That is there is no ack/nak or handshaking involved in an individual sentence transfer which amounts to broadcasting data over the serial link. The effect of this style of transfer is that whoever needs the data listens for the appropriate sentence and retrieves the information it needs. This is changing somewhat with the new NMEA 2000 specification but very little hardware makes use of this high-speed interface yet.

The one sentence we are vitally interested in is the waypoint load (GPWPL). This sentence is used to upload information into the GPS or for the GPS to download information to another unit. The structure of the sentence is as follows:

$GPWPL,3819.500,S,14513.350,E,WPT001*36
$GPWPL,3821.400,S,14514.100,E,WPT002*3F
$GPWPL,3824.150,S,14514.950,E,WPT003*36
$GPWPL,3826.000,S,14512.950,E,WPT004*31
$GPWPL,3827.400,S,14509.350,E,WPT005*35
$GPWPL,3830.450,S,14505.300,E,WPT006*3C
$GPWPL,3830.850,S,14453.200,E,WPT007*32

These are the NMEA sentences which correspond to the data in Table 1. The salient bits of this structure are the sentence identifier (verb $GPWPL) followed by the latitude formatted as DDMM.MMM (where DD is the decimal degrees and MM.MMM is the decimal minutes). This is followed by the direction sense of the latitude (N or S). This is followed by the longitude formatted as DDDMM.MMM (where DDD is the decimal degrees and MM.MMM is decimal minutes). This is followed by the directional sense of the longitude (E or W). The next piece of information is the waypoint identifier. The '*' denotes the end of the record and is followed by the xored checksum of all the characters between the '$' and the '*' in 2 hex digits. The NMEA receiver of the data recalculates this checksum when a sentence is received and the sentence is discarded if it does not match the one in the transmitted sentence. There is no provision for forcing a retransmission or even detecting a dropped sentence. This is not a problem for most sentences as the data is repeated periodically and if missed this time it will in all likelihood get through the next time.

Specific Problems

So far what I've described is pretty basic and it all will work to provide a good solution for the problem I've described. Well almost.

The first problem is getting the data out of the spreadsheet in a form that GPSBabel can work on. One of the easiest ways is to use the ability of virtually all spreadsheet programs to provide comma separated values (CSV) in a text file format. Gpsbabel provides an extremely flexible way to input data in csv format. This is accomplished via csv style files. A style file allows the user to define how the data is organised and is very general in its operation. The style file (CSV.style) for reading the data outlined in Table 1. is as follows:

 
#
# Style definition for expanded CSV formatted
#
FIELD_DELIMITER COMMA
RECORD_DELIMITER NEWLINE
SHORTLEN 6
#
# Actual field definitions for an input record
#
# Wpt_Name, Latitude, Longitude, Note, Waypoint_Name
#
IFIELD DESCRIPTION,"","%s" # Waypoint Name text d
IFIELD LAT_HUMAN_READABLE,"","%d %f %c" # itude
IFIELD LON_HUMAN_READABLE,"","%d %f %c" # itude
IFIELD NOTES,"","%s" # Waypoint comment
IFIELD SHORTNAME,"","%s" # GPS Waypoint name suitable for RayNav 300 WPTnnn

A write-up on style files can be found in the README.style file in the gpsbabel/style subdirectory. This is an extremely flexible solution and allows a great deal of freedom in how you format your spreadsheet data.

The next problem after creating the text file from the spreadsheet (in this example I used save as CSV file and called the file Waypoints.csv) that you encounter is the differences between MacOS X text file record delimiters and Unix text file record delimiters. MacOS X places a <cr> (carriage return, hex 0D) at the end of a record. Unix however is expecting to see a <nl> (Newline character, hex 0B) at the end of the record. If this is not corrected GPSBabel when reading the input file sees only 1 very long record. To correct this problem there is a simple Unix command tr (translate) that allows for the translation of characters. The command to perform this conversion is:

tr '\r' '\n' < Waypoints.csv > makewpt.tmp

the \r specifies the carriage return character and the \n specifies the newline character. We now have a properly formatted comma separated value file which GPSBabel can work on. But first we must remove the first record in the file as it contains the column headers from the spreadsheet. An easy way to do this is via the Unix command sed. Sed is a stream editor which allows you to specify one or more editing commands to be performed on one or more files via a command line. The command to remove the first line of the translated csv file is:

sed '1,1d' < makewpt.temp >makewpt.tempa

The command to convert this file into the appropriate NMEA sentences using GPSBabel is:

~/gpsbabel/gpsbabel -i xcsv,style=./CSV.style -f makewpt.tempa -o nmea -F Waypoints.nmea

The result of this command is a NMEA formatted sentence file with the data in a format that is ready to load into the GPS. All of this has been put into a shell script called makewpt which simplifies things:

#!/bin/tcsh
#
# Shell script to take care of the conversion of waypoint csv a to NMEA
# sentences suitable for downloading into a Raymarine RayNav 300 igator
#
# Usage:
# makewpt filename
# where filename is the name of an excel csv exported text e
#
# first lets make sure the filename was specified and
# it actually exists and is readable
#
if (${#argv} == 0 ) then
echo "${0}: Input file not specified"
exit 1
else
if (! -r ${argv[1]}) then
echo "${0}: File: ${argv[1]} is not readable"
exit 2
endif
endif
#
# file exists so we now need to fix it up for Unix use
#
tr '\r' '\n' < ${argv[1]} > makewpt.temp
#
# now we must remove header line from the csv file
#
sed -e '1,1d' makewpt.temp > makewpt.tempx
#
# reconstruct the filename by using all the characters up to a p> # this becomes the root for the output filename
#
~/gpsbabel/gpsbabel -i xcsv,style=./CSV.style -f makewpt.tempx \
-o nmea -F "${argv[1]:r}.nmea"
#
# now we clean up after ourselves
#
rm makewpt.temp*
exit 0

At this point we now need to work out how we are going to load the GPS. The easiest way is to use a terminal emulator and use a serial port to connect to the GPS. However, all modern Macs do not have serial ports and the terminal application does not support serial port output. So how do we do it?

Keyspan make a very good USB to RS-232 port adapter. Mine is an older model the USA-19QW. This device and in fact all the current Keyspan serial port products are well supported in MacOS X. So this solves one part of the problem. The second part is the actual terminal emulator. A quick trip to www.versiontracker.com to search for terminal emulation software yielded an interesting result.

For anyone who has been associated with Macs for over 10 years this piece of software will ring a bell. Zterm was one of the most popular bulletin board access tools of its day. It was a wonderful piece of software and provided a very functional terminal emulator coupled with all the file download protocols which were in use prior to the widespread use of the internet. Can you remember Kermit? David Alverson did a splendid job on Zterm and has ported it to MacOS X. It is still in beta so expect some rough edges but it works and it really is a 'blast from the past'. With Zterm you can select the USB serial port hardware and can monitor all the NMEA data being sent from the GPS. You can also capture the information and save it to a file for later analysis. This is how I will download waypoint data from the GPS to the Mac in the future. Zterm also allows you to send a text file and this is how you load waypoint data into the GPS. You will remember that NMEA uses a broadcast technique to transmit data from one device to another so you first need to put the GPS into listening mode for waypoint data. This will vary on each different GPS hardware but the concept is the same for all. You then transmit the Waypoints.nmea file to the GPS which will populate its waypoint list with the data.

The ease of use is great and the functionality of GPSBabel plus Zterm ensure a good working solution at low cost. It is well worth learning how to use the MacOS X terminal application and the underlying power of the core Unix components to achieve a really worthwhile result. Thanks to all the GPSBabel contributors and a special thanks for Robert Lipe for working with me on sorting out some problems in the NMEA support. The application is great keep it up guys!

- John Proctor