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