Geotech is GPS capable watch that i received with a magazine order. The looks bit like water-resistance it is not at all that is very clear if one studies it little closer. But it has GPS receiver and data-logging with usb interface and the batter gets recharged via USB. One should be able to use it as an GPS-mouse pointer as by default it works baud9600 NMEA0183 protocol. The full specifications can be found from the pdf document attached to this page. The watch comes with windows software, that is somewhat integrated to Google map services. The basic functionality to download data points works ok with wine-1.3.15.
For the kicks, i decided to hack the communications and write a command line open-source program, that i now call geotech_tool. The tool is able to query and set sampling rate (from 1s to 99s) and to download sampled points (coordinates + altitude + time). The downloaded points are then stored in GPX file format, that one can feed for example Google earth. You can find source code here or on the file links below.
The compiling process should be 'mkdir build; cd build; cmake ../ ; make ;' and the you can copy the built binary where you like. The program uses no external libraries so one should not need to install big bunch of packages.
It also seems that the original windows software does not produce proper GPX files. First of all the GPX format should store the timestamps in UTC time and not in local time . Secondly the software fails the UTC to local time conversion at least on my timezone (Helsinki, UTC +2 or +3) when daylight saving is active (UTC+3).
2012-09-30 Sundberg: Fixed issue with time stamp after 16:00 hours from midnight, thanks to Michal Kaut, Norway
2012-09-14 Sundberg: Fixed issues with serial reading, thanks to Erik Starbäck, Sweden
2012-04-14 Sundberg: First version created.
Image 2: Example image with route loaded in Google Earth. Here is example image from google earth and my route. The generated gpx file is also attached to this page. Note that the data points actually have height of 65k, that is not bug -- their own windows program produces same heights.
Hacking the device
The clock shows up nicely as serial device at /dev/ttyUSBX when attached. The lsusb gives:
ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
And dmesg shows:
[ 2923.980080] usb 5-3: new full speed USB device using ohci_hcd and address 3
[ 2924.224014] usbcore: registered new interface driver usbserial
[ 2924.224023] USB Serial support registered for generic
[ 2924.224041] usbcore: registered new interface driver usbserial_generic
[ 2924.224042] usbserial: USB Serial Driver core
[ 2924.231232] USB Serial support registered for pl2303
[ 2924.231573] pl2303 5-3:1.0: pl2303 converter detected
[ 2924.252361] usb 5-3: pl2303 converter now attached to ttyUSB0
[ 2924.252395] usbcore: registered new interface driver pl2303
[ 2924.252400] pl2303: Prolific PL2303 USB to serial adaptor driver
The real problem came with how to communicate with the device - what are the port settings and what are the messages used to download the datapoints. The com port settings i was able to figure out using wine with strace attached to a the running .exe pid just before the connection took place. The connection works so that the program first sends specific 'go to data transfer mode' and then changes from B9600 to B115200. After proper handshake it sends the command what to do, that is 'please send your sampling rate', 'please set the sampling rate to xx', 'please remove all datapoints', 'please send all the datapoints' or 'please reset to B9600 gps mouse mode'.
The communication is based on (mainly) 7 bytes messages and responses and most of them was easy to figure out. Most problematic was the datapoints downloading. It works so that device first sends 'i have N datapoints', after the PC can query 'please send me datapoints X'. The messages have checksums and the clock refuses to communicate if the checksum of request is wrong. After solving this (with pen and paper and suitable number of datapoints) i was able to download all datapoints. But the interpretation was bit harder: one item consists of 20 bytes of which some changes and some not. By leaving the clock on my balcony for a while it sampled same coordinates several times. Then it was matter of use the windows software to get datapoints transferred to GPS coordinates (which some were same) and then look at the raw data which parts of that was the same. So i was able to figure out what parts were longitude and what latitude but rest of the bytes were more or less unknown. To find out full coding scheme i used the .exe program fed with fake data. Here is how the message seems to work:
/// MSG responce 23 23 a7 10 02 7e 01 7c aa 96 03 27 00 20 4e af b9 02 31 27
/// BYTES : MEANING
/// 0-2 : HEADER
/// 3-6 : LONGITUDE encoded in 0.000001 * B0 + 0.000002 * B1 + 0.000004 * B2 ...
/// 7-10 : LATITUDE
/// 11 : HEIGH -- 0-255
/// 12 : HEIGH -- 256 ->
/// 13 : ???
/// 14 : ???
/// 15 : Seconds, 1=1s,2=2s ,.., 64=1min,128=2min
/// 16 : Minutes, 1=4min,2=8min,3=12min,4=16min,5=20min, 16=1h, 17=1h 4min, 32=2h, 64=4h,128=8h
/// 17 : 1 = 16h, 2=1d , 4=2d , 8=4d , 16=8d, 32=16d, 64=1m, 128=2m
/// 18 : 1 = 4m , 2=8m , 4=1y, 8=2y , 16=4y, 32=8y , 64=16y, 128=32y , years since 2000
/// 19 : Checksum : \sum of bytes 0..18 mod 0xFF + 0xBA
usage: ./geotech <device> <mode> <param>, where mode is one of following:
reset -- send reset pulse to device
query -- query device for the sampling rate
set -- set the device sampling rate given in <param>
download -- download all data points from the device, save in GPX format to file <param>
clear -- clear all data points from the device
`--> ./geotech_tool /dev/ttyUSB0 query
Debug (/home/sundberg/svn-personal/devel/geotech_tool/serial.c:367): opened device for fd 3
Debug (/home/sundberg/svn-personal/devel/geotech_tool/serial.c:505): CALL: Setting device for highspeed communication
Debug (/home/sundberg/svn-personal/devel/geotech_tool/serial.c:398): Device init ok.
Debug (/home/sundberg/svn-personal/devel/geotech_tool/serial.c:301): CALL: query for sample rate
SAMPLING STEP: 30 s
Debug (/home/sundberg/svn-personal/devel/geotech_tool/serial.c:469): CALL: Sending reset to device ..