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
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
The supplied software is poor. Therefore, I analyzed the log. Do you have NAL-files with non-zero data on padding-positions ? Greetings Dennis
I have hundreds of logs here. The paddings seem always to contain zero values. I also observed that height is obviously baroheight. Regards, Christian
i found a page with many formulas for bearing and distance http://www.movable-type.co.uk/scripts/latlong.html
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.
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; }
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.
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!
1 | Index: Makefile.in
|
2 | ===================================================================
|
3 | RCS file: /cvsroot/gpsbabel/gpsbabel/Makefile.in,v
|
4 | retrieving revision 1.178
|
5 | diff -u -r1.178 Makefile.in
|
6 | --- Makefile.in 6 Mar 2011 23:02:33 -0000 1.178
|
7 | +++ Makefile.in 20 Jun 2012 05:29:40 -0000
|
8 | @@ -65,7 +65,8 @@
|
9 | jtr.o sbp.o sbn.o mmo.o skyforce.o itracku.o v900.o delbin.o \ |
10 | pocketfms_bc.o pocketfms_fp.o pocketfms_wp.o naviguide.o enigma.o \ |
11 | vpl.o teletype.o jogmap.o bushnell.o bushnell_trl.o wintec_tes.o \ |
12 | - subrip.o garmin_xt.o explorist_ini.o \
|
13 | + wsg2000.o \
|
14 | + subrip.o garmin_xt.o explorist_ini.o
|
15 | |
16 | FMTS=@FMTS@ |
17 | |
18 | Index: vecs.c
|
19 | ===================================================================
|
20 | RCS file: /cvsroot/gpsbabel/gpsbabel/vecs.c,v
|
21 | retrieving revision 1.225
|
22 | diff -u -r1.225 vecs.c
|
23 | --- vecs.c 11 Nov 2010 03:32:47 -0000 1.225
|
24 | +++ vecs.c 20 Jun 2012 05:29:41 -0000
|
25 | @@ -174,6 +174,7 @@
|
26 | extern ff_vecs_t wintec_tes_vecs; |
27 | extern ff_vecs_t subrip_vecs; |
28 | extern ff_vecs_t format_garmin_xt_vecs; |
29 | +extern ff_vecs_t wsg2000_vecs;
|
30 | |
31 | static |
32 | vecs_t vec_list[] = { |
33 | @@ -1020,6 +1021,12 @@
|
34 | "Wintec TES file", |
35 | "tes" |
36 | }, |
37 | + {
|
38 | + &wsg2000_vecs,
|
39 | + "wsg2000",
|
40 | + "Wintec WSG-2000 NAL file",
|
41 | + "nal"
|
42 | + },
|
43 | { |
44 | &subrip_vecs, |
45 | "subrip", |
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.
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.