WINTEC WSG-2000 G-Trender 2

[Dennis Heynlein (Gast)]

Habe mal da Logformat dieses GPS-Empfängers analysiert da die 
beigelieferte Software ein schlechter Witz ist.

Dateiendung: .NAL
Dateiformat: binär, 32 Byte feste Blocklänge
Blockaufbau:

#pragma pack(1)
struct data32
{
unsigned char pointtype;    // 0 - normal , 1 - start , 2 - marked
unsigned char padding1;

unsigned int second:6,minute:6,hour:5;
unsigned int day:5,month:4,year:6;        // add 2000 to year

signed int latitude,longitude;       // divide by 1E7 for degree
signed short height;        // m
signed char temperature;    // °C
unsigned short pressure;    // hPa
unsigned char cadence;      // RPM
unsigned char pulse;        // BPM
signed char slope;          // degree

signed short compass;       // degree
signed short roll;          // degree
signed short yaw;           // degree

unsigned char bikespeed;    // km/h
unsigned char padding2[3];
}

cadence ist die Rattrittfrequenz
slope ist die durch das GPS ermittelte Neigung

Wenn das Gerät in einem gedachten karthesischen Koordinatensystem liegen 
würde mit der längsten Seite des Gerätes auf der Y-Achse und liegend bei 
Nullauslenkung auf der X-Y-Ebene wäre
roll die Drehung um die X-Achse
yaw die Drehung um die Y-Achse
und
compass die Drehung um die Z-Achse

[Greg A. Woods (Gast)]

Danke schön!

Apologies for posting my reply in English....

I'm very glad to have finally found a description of the .NAL file 
format!

The attached test code seems to read the files properly.  I will now 
work on converting them to a proper GPS interchange format of some sort 
(ideally one that my photo tagging software can read!).  If I get 
inspired enough to try to understand the quagmire of gpsbabel I may try 
to write a conversion module for it as well.

--
Greg A. Woods

[Dennis H. (c-logic)]

The supplied software is poor.
Therefore, I analyzed the log.

Do you have NAL-files with non-zero data on padding-positions ?

Greetings Dennis

[guest (Gast)]

I have hundreds of logs here. The paddings seem always to contain zero 
values.

I also observed that height is obviously baroheight.

Regards, Christian

[Dennis H. (c-logic)]

i found a page with many formulas for bearing and distance

http://www.movable-type.co.uk/scripts/latlong.html

[Greg A. Woods (Gast)]

Indeed, all pad bytes have been zero so far.

--
Greg.

[Greg A. Woods (Gast)]

now with some simple data field validation

(my current set of 69 files containing 1.3 million records all validate 
OK so far)

One thing I'm curious about though -- where is the UV data stored?

--
Greg.

[Dennis H. (c-logic)]

I think UV-Datas only buffered in RAM.

--
Dennis

[Dennis H. (c-logic)]

C-Implementation for Distance & Bearing from 
http://www.movable-type.co.uk/scripts/latlong.html

{
  static signed int oldlong=0;
  static signed int oldlat=0;
  double dist;
  double brng;
  if(oldlong || oldlat)
  {
    CalcDist2(oldlong,oldlat,rec.longitude,rec.latitude,&dist,&brng);
    printf(" distance: %0.2lf m bearing: %0.1lf°\n",dist,brng);
  }
  oldlong=rec.longitude;
  oldlat=rec.latitude;
}

void CalcDist2(signed int long1,signed int lati1,signed int long2,signed 
int lati2,double *dist,double *brng)
{
  const double R = 6371000;

  double lat1=lati1/1E7*M_PI/180.;
  double lat2=lati2/1E7*M_PI/180.;
  double lon1=long1/1E7*M_PI/180.;
  double lon2=long2/1E7*M_PI/180.;
  double dLat = (lat2-lat1);
  double dLon = (lon2-lon1);
  double dPhi = log(tan(lat2/2.+M_PI/4.)/tan(lat1/2.+M_PI/4.));
  double q = (dPhi != 0.) ? dLat/dPhi : cos(lat1);  // E-W line gives 
dPhi=0

  // if dLon over 180° take shorter rhumb across 180° meridian:
  if(fabs(dLon) > M_PI) {
    dLon = dLon>0. ? -(2.*M_PI-dLon) : (2.*M_PI+dLon);
  }
  *dist = sqrt(dLat*dLat + q*q*dLon*dLon) * R ;
  *brng = atan2(dLon, dPhi)*180./M_PI;
}

[Greg A. Woods (Gast)]

The parts of this code that do not refer to "nal_t" should now work any 
2's compliment CPU architecture that there is a working standard C 
compiler for....

I.e. I've written a portable marshalling function to read the binary 
data into a C-friendly data structure.

[Dennis H. (c-logic)]

Great work, Greg.

[Greg A. Woods (Gast)]

Well, that wasn't as hard as I thought it might be, at least for a first 
attempt.  I was able to avert my eyes from most of the more ugly bits of 
GPSbabel internals and just add a few very simple wrapper functions to 
my main marshalling function.

This isn't quite complete and in what will no doubt be the final form 
necessary for release, but the following changes, along with the 
attached file, shoe-horns my code into GPSbabel in such a way that it 
will at least appear to work when compiled on systems with 
BSD-compatible libc's, and perhaps on Linux with GNU libc as well 
(though maybe not with the warn()/warnx() calls).  I've done very little 
testing as yet, but in case anyone else is eager to do something more 
useful with the data structure that Dennis reverse engineered, here it 
is!

Index: Makefile.in
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/Makefile.in,v
retrieving revision 1.178
diff -u -r1.178 Makefile.in
--- Makefile.in  6 Mar 2011 23:02:33 -0000  1.178
+++ Makefile.in  20 Jun 2012 05:29:40 -0000
@@ -65,7 +65,8 @@
   jtr.o sbp.o sbn.o mmo.o skyforce.o itracku.o v900.o delbin.o \
   pocketfms_bc.o pocketfms_fp.o pocketfms_wp.o naviguide.o enigma.o \
   vpl.o teletype.o jogmap.o bushnell.o bushnell_trl.o wintec_tes.o \
-  subrip.o garmin_xt.o explorist_ini.o \
+  wsg2000.o \
+  subrip.o garmin_xt.o explorist_ini.o
 
 FMTS=@FMTS@
 
Index: vecs.c
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/vecs.c,v
retrieving revision 1.225
diff -u -r1.225 vecs.c
--- vecs.c  11 Nov 2010 03:32:47 -0000  1.225
+++ vecs.c  20 Jun 2012 05:29:41 -0000
@@ -174,6 +174,7 @@
 extern ff_vecs_t wintec_tes_vecs;
 extern ff_vecs_t subrip_vecs;
 extern ff_vecs_t format_garmin_xt_vecs;
+extern ff_vecs_t wsg2000_vecs;
 
 static
 vecs_t vec_list[] = {
@@ -1020,6 +1021,12 @@
                 "Wintec TES file",
                 "tes"
         },
+        {
+                &wsg2000_vecs,
+                "wsg2000",
+                "Wintec WSG-2000 NAL file",
+                "nal"
+        },
   {
     &subrip_vecs,
     "subrip",

[Greg A. Woods (Gast)]

I think I found a minor "bug" in the data definition, and a more 
important bug in my conversion code.

I think the "type" byte is actually a set of binary flags.  I managed to 
find one of my log files where the first record was both a track start 
and a waypoint -- i.e. it had a value of 3.

Also I made an off-by-one error in converting the GPS time to "struct 
tm" values, specifically in the month number.  (somehow I didn't notice 
until I was viewing some of my tracks on the map in PhotoLinker and 
realized the most recent ones were one month in the future!)

The attached files replace those attached to my previous postings.

[Greg A. Woods (Gast)]

This version is potentially more portable -- bitfield order is defined 
by the platform API, so I've added some preprocessor logic to try and 
guess the correct order.  I've only tested on an older OS X running on a 
PowerPC system.

The patch file is for the "old" SourceForge version of gpsbabel, i.e. 
the pure C version.  You can still check it out from the SourceForge CVS 
servers:

  http://sourceforge.net/p/gpsbabel/code/?source=navbar