Update: You can find the latest version here.
I own a Navigr Bike GPS (with a model descriptor of ‘NAVBIKE-GPS’). My primary use for it is recording tracks for OpenStreetMap, and it works well enough for my needs: small, fairly accurate, decent battery when recording and a seemingly infinite battery when left in a drawer and forgotten about. It has two problems: first, it doesn’t record altitude on the GPS tracks, which isn’t a big deal for me, and second, you can’t directly save tracks from the “Laser GPS” program bundled with it.
A side note: I lost the original disc, and there was no download listed on my particular product page, but the other sports products seem to use exactly the same software, so you can just download a replacement from, for example, here. (The Navigr products are just barely-rebranded LaserCo ones, and there aren’t any downloads at all on the original site.)
Writing a wholesale replacement or driver seemed overkill, since the software could already access and save the gps tracks on my computer – just not in a useable format. A bit of hunting with Process Monitor and some peeking inside files found them in a file called ‘BridgeMin.dll’ in the install directory. I still don’t know what the name refers to, but it’s actually a password-protected Jet database, which would easily be opened by Access if I knew the password.
Which turned out to be trivial. The password is “danger”.
The database has a few dozen tables and a few queries. The tables aren’t all used – some, such as ‘altimeter’ or columns relating to heart rate measurement aren’t supported by my device. The useful data is in a few of the many confusingly named tables:
- TrackPoint, which has the recorded GPS points
- TrackPoint1, which has summary data for the invididual tracks
- TimeZone, which seems to have the timezone set on the device
There are four more trackpoint tables – TrackPoint2, TrackPoint21, TrackPoint211, and TrackPoint3 – but they’re all empty for me, and seem to contain various combinations of the columns in the first two tables.
TrackPoint has a whole bunch of columns, only a few of which are useful:
- Id, a unique value but not actually a primary key
- Alti, which my device doesn’t use (always 0)
- Cnumber, which corresponds to the track a waypoint belongs to
- Setid (blank – no idea)
- Track_Date (blank)
- Longitude, in the format “123°45.6789”
- LonSign (E or W)
- Latitude, in the format “12°34.5678”
- LatSign (N or S)
- Speed (blank)
- HeartRate (always 0, as my device doesn’t support it)
- Tempreture (misspelled, and blank)
- LongitudeN, which is a decimal format of Longitude, e.g. 123.45678
- LatitudeN, which is a decimal format of Latitude
- TrackDist, an integer which increases along the same track – I didn’t use this or determine what units it’s recorded in
- TrackSpeed, which appears to be the (integer) speed in unknown units
- TrackTime, which records the local time on the device when the waypoint was recorded (accurate to the second)
- Cari, which increases along the track, but not at an obvious rate – possibly “calories”?
- UserName (always NEWCO)
- SerNo (oddly, an always increasing value)
- TimeInZone (relates to heartrate, so 0 for my device)
- IDNumber (always blank)
- RunType (always blank)
The waypoint IDs increase sequentially in the order they were recorded, fortunately, so there’s no need to get too fancy with retrieving them.
TrackPoint1 has the following columns:
- Id, the unique-but-not-primary-key column
- Track_Number (unsure)
- Cnumber, which relates to the Cnumber in Trackpoint
- Track_Date, which is the local time the recording started
- setid (blank)
- End_Date, the local time of the last waypoint
- TrackName (assigned by the device, just a string of digits with no obvious meaning)
- MaxSpeed (unknown units)
- MinSpeed (unknown units)
- TrackType (“Run”, at least for my device)
- Cari (blank)
- UserName (NEWCO)
- IDNumber (the serial number of the device, apparently)
- TrackDist, which records the total distance
The last of these, TrackDist, could at least be easily figured out, and at least for that column the units used are centimetres.
With all that information, the actual programming and conversion was fairly straightforward. I had to convert the latitude and longitude formats, and the time/date was a bit more annoying. I also decided not to trust the ‘speed’ column, or the TimeZone table data (which seemed to represent a list index of timezones, and not the direct timezone offset). I used TrackPoint1 to get a list of the recorded tracks, and then only the relevant waypoints from the TrackPoint table. The finished product:
Once I got it working and exporting valid files, I lost interest in adding the other planned features, like the optional metadata, or displaying more details about the selected track below the listbox to make them easier to differentiate (e.g. many short tracks on the same day). Even that ‘About…’ link doesn’t do anything.