This format can...
read waypoints
read tracks
This format has the following options: erase, targetlocation, configlog, baud, initbaud, read-at-once, first-sector, last-sector, dump-file, no-output, gps-utc-offset, gps-week-rollover .
Serial download protocol for GPS data loggers based on Skytraq Venus 5 and Venus 6 chipsets. This chipset is used by a number of devices from different manufacturers. If your logger came with the Windows software iTravelTech GPS Photo Tagger, chances are that you can use this format to read its memory.
Following a list of devices which should be supported by this module (Note that not all of them have actually been tested, so if you can confirm that additional models work, please mail the gpsbabel-misc group with your success, tips, and any pertinent links for your model.):
Table 3.17. Devices supported by skytraq module
Manufacturer | Model | USB (baud) | Bluetooth (baud) |
---|---|---|---|
SJA | "3-in-1" GPS logger | up to 230400 | 9600 |
Navilock | BT-455PDL | untested | untested |
Polaris | Travel Honey | up to 230400 | 9600 |
Pearl Diffusion | Keymate STV-5 | untested | untested |
Canmore | GT-730FL-S | untested | n/a |
Canmore | GT-750F | untested | untested |
Gisteq | DPL900 | up to 230400 | untested |
Adapt Mobile | Keychain Pro | untested | untested |
Adapt Mobile | Keychain Pro | 9600 | 9600 |
Windows users of GPSBabel version 1.5.2 or less may have to explicitly specify a bit rate of 115200 or lower.
Example 3.32. Command showing skytraq download of tracks and erasing the logger on Linux
gpsbabel -i skytraq,erase -f /dev/ttyUSB0 -o gpx -F out.gpx
Example 3.33. Command showing skytraq erasing the logger without download on Linux
gpsbabel -i skytraq,erase,no-output -f /dev/ttyUSB0
If available, reading the logger using bluetooth should also work. However, many devices support only one
specific baud rate over bluetooth, e.g. 9600. In that case you should use the option baud=0
to tell GPSBabel to use that default baud rate:
Example 3.34. Command showing skytraq download tracks via bluetooth on Linux
rfcomm bind 0 <bdaddr>
gpsbabel -i skytraq,baud=0 -f /dev/rfcomm0 -o gpx -F out.gpx
Set location finder target location as lat,lng.
The device provides a location finder built from eight LEDs and can use those LEDs to guide you to a location. You can set the target location with the 'targetlocation' option. Use ':' as the delimiter between latitude and longitude. Note that GPSBabel terminates after writing the location info to the device, i.e. no logging data will be read from it.
Example 3.35. Set the target location of the Skytraq location finder
gpsbabel -i skytraq,targetlocation=12.34:-56.78 -f /dev/ttyUSB
0 -o unicsv -F -
Sets latitude and longitude of the location finder to N12.34 and W56.78 respectively. The arrows on the device will point you to this location as soon as it has a satellite fix.
Configure logging parameter as tmin:tmax:dmin:dmax.
Set the logging configuration as tmin:tmax:dmin:dmax. Here tmin and tmax are in seconds, and dmin and dmax in meters. With dt = time since last log, dx = distance since last log, and v the current speed, the device logs if
(dt > tmin and dx >= dmin and v >= vmin) or dt > tmax or dx > dmax or v > vmax
If you use this option, vmin is fixed at 0 and vmax at 65535 km/h.
Example. Set the device to log every 6 seconds (or 10km, whichever happens first!)
Example 3.36. Set the logging parameters for Skytraq device
gpsbabel -i skytraq,configlog=6:3600:0:10000 -f /dev/ttyUSB0
Baud rate used for download.
The following baud rates can be used: 4800, 9600, 19200, 38400, 57600, 115200, 230400. Note that your logger might not support all of them (especially 230400 which isn't documented in the chipset manual, though there are known devices that are capable of this speed).
If baud=0
(zero) download takes place at the baud rate the
device is currently set to. This is especially useful for Bluetooth connections since they
often don't allow changing the baud rate.
Baud rate used to init device (0=autodetect).
The "initbaud" option might be helpful if autodetection fails or takes too long. With this option you can tell GPSBabel the baud rate the device is currently set to. In contrast, the option "baud" specifies the rate at which the actual download should take place. If it is different than "initbaud" (or the autodetected rate, if initbaud wasn't given), the initial setting will be restored after finishing the download.
Number of sectors to read at once (0=use single sector mode).
If read-at-once
>= 1, batch mode is enabled with that many sectors being read at a time.
A value of zero disables batch mode and switches to single read mode. Not all devices support batch mode; in that case
gpsbabel automatically switches to single read mode.
Under normal circumstances, the larger this number the faster the transfer.
Reducing read-at-once
or even switching to single sector mode might help when you get
transmission errors/aborts.
First sector to be read from the device.
The logger's memory is organized in sectors, serially numbered starting at 0. Each sector takes 4096 bytes of data. Typical devices hold about 250 sectors. The memory is always filled from sector 0 on, until it is full or the device being erased again by the user.
Normally you can safely omit this option. However, it might be useful to read data from erased devices: we observed that on erase, only the first two sectors are actually cleared. The following example shows how to read the remaining data:
Example 3.37. Command showing how to read data from an erased device
gpsbabel -i skytraq,first-sector=2 -f /dev/ttyUSB0 -o gpx -F out.gpx
Last sector to be read from the device (-1: smart read everything).
A value of -1 (the default) enables automatic mode, i.e. reading is stopped when an empty sector is encountered. We observed that sometimes the device doesn't report the correct number of used sectors, which confuses the Windows software, so that it might not get all trackpoints. In contrast, our algorithm ensures that everything is being read (please report if it doesn't work for you).
Dump raw data to this file.
Writes raw data as it is read from the logger to the file given as this option's argument (additional to decoding it as usual). The resulting binary files can be read and decoded by the skytraq-bin format. Mainly useful for debugging/development purposes.
Disable output (useful with erase).
If this option is given, no GPS log data will be read from the device (unless "dump-file" is given too; in that case only decoding will be disabled).
Seconds that GPS time tracks UTC (0: best guess).
gps-utc-offset is used to override the built-in table of offsets of the offset between GPS time and UTC time. This chipset reports only GPS time to the host and relies on software to know every time an adjustment is made. Since GPS time offsets can change without a new version of GPSBabel is released, those that care about total accuracy can override it.
gpsbabel
-i skytraq.bin,gps-utc-offset=15 -f filename.bin
Indicates that GPS is ahead of UTC by fifteen seconds, as was the case in 2009.
Consult formal explanation of GPS time vs. UTC time if you're into that.
GPS week rollover period we're in (-1: best guess).
gps-week-rollover is used to override the best-guessing of GPS week rollover period we're currently in: skytraq log data contains dates in the form of GPS weeks, which roll over to 0 every 1024 weeks (close to 20 years).
Table 3.18. GPS week rollover dates
Starting from: | gps-week-rollover value: |
---|---|
1980-01-06 00:00:00 UTC | 0 |
1999-08-21 23:59:47 UTC | 1 |
2019-04-06 23:59:42 UTC | 2 |
The default behavior when gps-week-rollover isn't given (or is a negative number) is to assume the input data has been logged within the preceding 1024 weeks from the time gpsbabel is run, which should be perfectly fine in almost all cases.
The following example:
gpsbabel -i skytraq.bin,gps-week-rollover=1 -f filename.bin
indicates that logged data is assumed to be from the period between 21/22 Aug 1999 and 6/7 April 2019.