SkyTraq Venus based loggers (download) (skytraq)

This format can...

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.18. Devices supported by skytraq module

ManufacturerModelUSB (baud)Bluetooth (baud)
SJA"3-in-1" GPS loggerup to 2304009600
NavilockBT-455PDLuntesteduntested
PolarisTravel Honeyup to 2304009600
Pearl DiffusionKeymate STV-5untesteduntested
CanmoreGT-730FL-Suntestedn/a
CanmoreGT-750Funtesteduntested
GisteqDPL900up to 230400untested
Adapt MobileKeychain Prountesteduntested
Adapt Mobile Keychain Pro96009600

Windows users of GPSBabel version 1.5.2 or less may have to explicitly specifiy a bit rate of 115200 or lower.

Example 3.34. 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.35. 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.36. 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


erase option

Erase device data after download.

targetlocation option

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.37. 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.


configlog option

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.38. Set the logging parameters for Skytraq device

gpsbabel -i skytraq,configlog=6:3600:0:10000 -f /dev/ttyUSB0


baud option

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.

initbaud option

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.

read-at-once option

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 option

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.39. 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 option

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-file option

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.

no-output option

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).

gps-utc-offset option

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 option

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.19. GPS week rollover dates

Starting from:gps-week-rollover value:
1980-01-06 00:00:00 UTC0
1999-08-21 23:59:47 UTC1
2019-04-06 23:59:42 UTC2

The default behaviour 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.