2017-04-27 18:18:03 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
Import Datatrak/WLog files
Sequentially parses a file, expected to be a Datatrak/WLog divelog, and
converts the dive info into Subsurface's dive structure.
As my first DC, back in 90s, was an Aladin Air X, the obvious choice of log
software was DTrak (Win version). After using it for some time we moved to WLog
(shareware software more user friendly than Dtrak, printing capable, and still
better, it runs under wine, which, as linux user, was definitive for me). Then,
some years later, my last Aladin died and I moved to an OSTC, forcing me to
look for a software that support this DC.
I found JDivelog which was capable of import Dtrak logs and used it for some
time until discovered Subsurface existence and devoted to it.
The fact was that importing Dtrak dives in JDivelog and then re-importing them
in Subsurface caused a significant data loss (mainly in the profile events and
alarms) and weird location of some other info in the dive notes (mostly tag
items in the original Dtrak software). This situation can't actually be solved
with tools like divelogs.de which causes similar if no greater data loss.
Although this won't be a core feature for Subsurface, I expect it can be useful
for some other divers as has been for me.
Comments and issues:
Datatrak/Wlog files include a lot of diving data which are not directly
supported in Subsurface, in these cases we choose mostly to use "tags".
The lack of some important info in Datatrak archives (e.g. tank's initial
pressure) forces us to do some arbitrary assumptions (e.g. initial pressure =
200 bar).
There might be archives coming directly from old DOS days, as first versions
of Datatrak run on that OS; they were coded CP437 or CP850, while dive logs
coming from Win versions seems to be coded CP1252. Finally, Wlog seems to use a
mixed confusing style. Program directly converts some of the old encoded chars
to iso8859 but is expected there be some issues with non alphabetic chars, e.g.
"ª".
There are two text fields: "Other activities" and "Dive notes", both limited to
256 char size. We have merged them in Subsurface's "Dive Notes" although the
first one could be "tagged", but we're unsure that the user had filled it in
a tag friendly way.
WLog adds some information to the dive and lets the user to write more than
256 chars notes. This is achieved, while keeping compatibility with DTrak
divelogs, by adding a complementary file named equally as the .log file and
with .add extension where all this info is stored. We have, still, not worked
with this complementary files.
This work is based on the paper referenced in butracker #194 which has some
errors (e.g. beginning of log and beginning of dive are changed) and a lot of
bytes of unknown meaning. Example.log shows, at least, one more byte than those
referred in the paper for the O2 Aladin computer, this could be a byte referred
to the use of SCR but the lack of an OC dive with O2 computer makes impossible
for us to compare.
The only way we have figured out to distinguish a priori between SCR and non
SCR dives with O2 computers is that the dives are tagged with a "rebreather"
tag. Obviously this is not a very trusty way of doing things. In SCR dives,
the O2% in mix means, probably, the maximum O2% in the circuit, not the O2%
of the EAN mix in the tanks, which would be unknown in this case.
The list of DCs related in bug #194 paper seems incomplete, we have added
one or two from WLog and discarded those which are known to exist but whose
model is unknown, grouping them under the imaginative name of "unknown". The
list can easily be increased in the future if we ever know the models
identifiers.
BTW, in Example.log, 0x00 identifier is used for some DC dives and from my own
divelogs is inferred that 0x00 is used for manually entered dives, this could
easily be an error in Example.log coming from a preproduction DC model.
Example.log which is shipped in datatrak package is included in dives
directory for testing pourposes.
[Dirk Hohndel: some small cleanups, merged with latest master, support
divesites, remove the pointless memset() before free() calls
add to cmake build]
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2014-11-05 18:38:27 +00:00
|
|
|
#ifndef DATATRAK_HEADER_H
|
|
|
|
|
#define DATATRAK_HEADER_H
|
|
|
|
|
|
|
|
|
|
#include <string.h>
|
2017-05-07 08:27:44 +00:00
|
|
|
#include "libdivecomputer.h"
|
Import Datatrak/WLog files
Sequentially parses a file, expected to be a Datatrak/WLog divelog, and
converts the dive info into Subsurface's dive structure.
As my first DC, back in 90s, was an Aladin Air X, the obvious choice of log
software was DTrak (Win version). After using it for some time we moved to WLog
(shareware software more user friendly than Dtrak, printing capable, and still
better, it runs under wine, which, as linux user, was definitive for me). Then,
some years later, my last Aladin died and I moved to an OSTC, forcing me to
look for a software that support this DC.
I found JDivelog which was capable of import Dtrak logs and used it for some
time until discovered Subsurface existence and devoted to it.
The fact was that importing Dtrak dives in JDivelog and then re-importing them
in Subsurface caused a significant data loss (mainly in the profile events and
alarms) and weird location of some other info in the dive notes (mostly tag
items in the original Dtrak software). This situation can't actually be solved
with tools like divelogs.de which causes similar if no greater data loss.
Although this won't be a core feature for Subsurface, I expect it can be useful
for some other divers as has been for me.
Comments and issues:
Datatrak/Wlog files include a lot of diving data which are not directly
supported in Subsurface, in these cases we choose mostly to use "tags".
The lack of some important info in Datatrak archives (e.g. tank's initial
pressure) forces us to do some arbitrary assumptions (e.g. initial pressure =
200 bar).
There might be archives coming directly from old DOS days, as first versions
of Datatrak run on that OS; they were coded CP437 or CP850, while dive logs
coming from Win versions seems to be coded CP1252. Finally, Wlog seems to use a
mixed confusing style. Program directly converts some of the old encoded chars
to iso8859 but is expected there be some issues with non alphabetic chars, e.g.
"ª".
There are two text fields: "Other activities" and "Dive notes", both limited to
256 char size. We have merged them in Subsurface's "Dive Notes" although the
first one could be "tagged", but we're unsure that the user had filled it in
a tag friendly way.
WLog adds some information to the dive and lets the user to write more than
256 chars notes. This is achieved, while keeping compatibility with DTrak
divelogs, by adding a complementary file named equally as the .log file and
with .add extension where all this info is stored. We have, still, not worked
with this complementary files.
This work is based on the paper referenced in butracker #194 which has some
errors (e.g. beginning of log and beginning of dive are changed) and a lot of
bytes of unknown meaning. Example.log shows, at least, one more byte than those
referred in the paper for the O2 Aladin computer, this could be a byte referred
to the use of SCR but the lack of an OC dive with O2 computer makes impossible
for us to compare.
The only way we have figured out to distinguish a priori between SCR and non
SCR dives with O2 computers is that the dives are tagged with a "rebreather"
tag. Obviously this is not a very trusty way of doing things. In SCR dives,
the O2% in mix means, probably, the maximum O2% in the circuit, not the O2%
of the EAN mix in the tanks, which would be unknown in this case.
The list of DCs related in bug #194 paper seems incomplete, we have added
one or two from WLog and discarded those which are known to exist but whose
model is unknown, grouping them under the imaginative name of "unknown". The
list can easily be increased in the future if we ever know the models
identifiers.
BTW, in Example.log, 0x00 identifier is used for some DC dives and from my own
divelogs is inferred that 0x00 is used for manually entered dives, this could
easily be an error in Example.log coming from a preproduction DC model.
Example.log which is shipped in datatrak package is included in dives
directory for testing pourposes.
[Dirk Hohndel: some small cleanups, merged with latest master, support
divesites, remove the pointless memset() before free() calls
add to cmake build]
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2014-11-05 18:38:27 +00:00
|
|
|
|
2017-05-07 08:27:44 +00:00
|
|
|
struct models_table_t {
|
|
|
|
|
int model_num;
|
|
|
|
|
int libdc_num;
|
|
|
|
|
const char *name;
|
|
|
|
|
dc_family_t type;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Set of known models and equivalences with libdivecomputer.
|
|
|
|
|
* Not included 0x14, 0x24, 0x41, and 0x73 known to exist, but not its model name.
|
|
|
|
|
* Unknown model equivalence is set to Air X which should cover most profiles.
|
|
|
|
|
* Nitrox and 02 models seems to keep its number more seriously than earlier
|
|
|
|
|
* series and OEMs. Info for unknown models is always welcome.
|
|
|
|
|
*/
|
|
|
|
|
static const struct models_table_t g_models[] = {
|
|
|
|
|
{0x00, 0x00, "Manually entered dive", DC_FAMILY_NULL},
|
|
|
|
|
{0x1B, 0x3F, "Uwatec Aladin Pro", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0x1C, 0x1C, "Uwatec Aladin Air", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0x1D, 0x3F, "Spiro Monitor 2 plus", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0x1E, 0x3E, "Uwatec Aladin Sport", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0x1F, 0x3F, "Uwatec Aladin Pro", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0x34, 0x44, "Uwatec Aladin Air X/Z", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0x3D, 0x3F, "Spiro Monitor 2 plus", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0x3E, 0x3E, "Uwatec Aladin Sport", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0x3F, 0x3F, "Uwatec Aladin Pro", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0x44, 0x44, "Uwatec Aladin Air X/Z", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0x48, 0x1C, "Spiro Monitor 3 Air", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0xA4, 0xA4, "Uwatec Aladin Air X/Z O2", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0xB1, 0x3E, "Citizen Hyper Aqualand", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0xB2, 0x3F, "Citizen ProMaster", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0xB3, 0x3F, "Mares Guardian", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0xF4, 0xF4, "Uwatec Aladin Air X/Z Nitrox", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0xFF, 0xFF, "Uwatec Aladin Pro Nitrox", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
{0xEE, 0x44, "Uwatec Unknown model", DC_FAMILY_UWATEC_ALADIN},
|
|
|
|
|
};
|
|
|
|
|
|
2024-03-01 12:09:20 +00:00
|
|
|
#define JUMP(_ptr, _n) if ((char *) (_ptr += _n) > (char *)maxbuf) goto bail
|
|
|
|
|
#define CHECK(_ptr, _n) if ((char *) _ptr + _n > (char *)maxbuf) goto bail
|
Import Datatrak/WLog files
Sequentially parses a file, expected to be a Datatrak/WLog divelog, and
converts the dive info into Subsurface's dive structure.
As my first DC, back in 90s, was an Aladin Air X, the obvious choice of log
software was DTrak (Win version). After using it for some time we moved to WLog
(shareware software more user friendly than Dtrak, printing capable, and still
better, it runs under wine, which, as linux user, was definitive for me). Then,
some years later, my last Aladin died and I moved to an OSTC, forcing me to
look for a software that support this DC.
I found JDivelog which was capable of import Dtrak logs and used it for some
time until discovered Subsurface existence and devoted to it.
The fact was that importing Dtrak dives in JDivelog and then re-importing them
in Subsurface caused a significant data loss (mainly in the profile events and
alarms) and weird location of some other info in the dive notes (mostly tag
items in the original Dtrak software). This situation can't actually be solved
with tools like divelogs.de which causes similar if no greater data loss.
Although this won't be a core feature for Subsurface, I expect it can be useful
for some other divers as has been for me.
Comments and issues:
Datatrak/Wlog files include a lot of diving data which are not directly
supported in Subsurface, in these cases we choose mostly to use "tags".
The lack of some important info in Datatrak archives (e.g. tank's initial
pressure) forces us to do some arbitrary assumptions (e.g. initial pressure =
200 bar).
There might be archives coming directly from old DOS days, as first versions
of Datatrak run on that OS; they were coded CP437 or CP850, while dive logs
coming from Win versions seems to be coded CP1252. Finally, Wlog seems to use a
mixed confusing style. Program directly converts some of the old encoded chars
to iso8859 but is expected there be some issues with non alphabetic chars, e.g.
"ª".
There are two text fields: "Other activities" and "Dive notes", both limited to
256 char size. We have merged them in Subsurface's "Dive Notes" although the
first one could be "tagged", but we're unsure that the user had filled it in
a tag friendly way.
WLog adds some information to the dive and lets the user to write more than
256 chars notes. This is achieved, while keeping compatibility with DTrak
divelogs, by adding a complementary file named equally as the .log file and
with .add extension where all this info is stored. We have, still, not worked
with this complementary files.
This work is based on the paper referenced in butracker #194 which has some
errors (e.g. beginning of log and beginning of dive are changed) and a lot of
bytes of unknown meaning. Example.log shows, at least, one more byte than those
referred in the paper for the O2 Aladin computer, this could be a byte referred
to the use of SCR but the lack of an OC dive with O2 computer makes impossible
for us to compare.
The only way we have figured out to distinguish a priori between SCR and non
SCR dives with O2 computers is that the dives are tagged with a "rebreather"
tag. Obviously this is not a very trusty way of doing things. In SCR dives,
the O2% in mix means, probably, the maximum O2% in the circuit, not the O2%
of the EAN mix in the tanks, which would be unknown in this case.
The list of DCs related in bug #194 paper seems incomplete, we have added
one or two from WLog and discarded those which are known to exist but whose
model is unknown, grouping them under the imaginative name of "unknown". The
list can easily be increased in the future if we ever know the models
identifiers.
BTW, in Example.log, 0x00 identifier is used for some DC dives and from my own
divelogs is inferred that 0x00 is used for manually entered dives, this could
easily be an error in Example.log coming from a preproduction DC model.
Example.log which is shipped in datatrak package is included in dives
directory for testing pourposes.
[Dirk Hohndel: some small cleanups, merged with latest master, support
divesites, remove the pointless memset() before free() calls
add to cmake build]
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2014-11-05 18:38:27 +00:00
|
|
|
#define read_bytes(_n) \
|
2015-03-10 22:23:14 +00:00
|
|
|
switch (_n) { \
|
|
|
|
|
case 1: \
|
2017-05-07 12:26:56 +00:00
|
|
|
CHECK(membuf, _n); \
|
2017-05-07 09:44:47 +00:00
|
|
|
tmp_1byte = membuf[0]; \
|
2015-03-10 22:23:14 +00:00
|
|
|
break; \
|
|
|
|
|
case 2: \
|
2017-05-07 12:26:56 +00:00
|
|
|
CHECK(membuf, _n); \
|
2017-05-07 09:44:47 +00:00
|
|
|
tmp_2bytes = two_bytes_to_int (membuf[1], membuf[0]); \
|
2015-03-10 22:23:14 +00:00
|
|
|
break; \
|
|
|
|
|
default: \
|
2017-05-07 12:26:56 +00:00
|
|
|
CHECK(membuf, _n); \
|
2017-05-07 09:44:47 +00:00
|
|
|
tmp_4bytes = four_bytes_to_long(membuf[3], membuf[2], membuf[1], membuf[0]); \
|
2015-03-10 22:23:14 +00:00
|
|
|
break; \
|
2017-05-07 09:44:47 +00:00
|
|
|
} \
|
|
|
|
|
JUMP(membuf, _n);
|
Import Datatrak/WLog files
Sequentially parses a file, expected to be a Datatrak/WLog divelog, and
converts the dive info into Subsurface's dive structure.
As my first DC, back in 90s, was an Aladin Air X, the obvious choice of log
software was DTrak (Win version). After using it for some time we moved to WLog
(shareware software more user friendly than Dtrak, printing capable, and still
better, it runs under wine, which, as linux user, was definitive for me). Then,
some years later, my last Aladin died and I moved to an OSTC, forcing me to
look for a software that support this DC.
I found JDivelog which was capable of import Dtrak logs and used it for some
time until discovered Subsurface existence and devoted to it.
The fact was that importing Dtrak dives in JDivelog and then re-importing them
in Subsurface caused a significant data loss (mainly in the profile events and
alarms) and weird location of some other info in the dive notes (mostly tag
items in the original Dtrak software). This situation can't actually be solved
with tools like divelogs.de which causes similar if no greater data loss.
Although this won't be a core feature for Subsurface, I expect it can be useful
for some other divers as has been for me.
Comments and issues:
Datatrak/Wlog files include a lot of diving data which are not directly
supported in Subsurface, in these cases we choose mostly to use "tags".
The lack of some important info in Datatrak archives (e.g. tank's initial
pressure) forces us to do some arbitrary assumptions (e.g. initial pressure =
200 bar).
There might be archives coming directly from old DOS days, as first versions
of Datatrak run on that OS; they were coded CP437 or CP850, while dive logs
coming from Win versions seems to be coded CP1252. Finally, Wlog seems to use a
mixed confusing style. Program directly converts some of the old encoded chars
to iso8859 but is expected there be some issues with non alphabetic chars, e.g.
"ª".
There are two text fields: "Other activities" and "Dive notes", both limited to
256 char size. We have merged them in Subsurface's "Dive Notes" although the
first one could be "tagged", but we're unsure that the user had filled it in
a tag friendly way.
WLog adds some information to the dive and lets the user to write more than
256 chars notes. This is achieved, while keeping compatibility with DTrak
divelogs, by adding a complementary file named equally as the .log file and
with .add extension where all this info is stored. We have, still, not worked
with this complementary files.
This work is based on the paper referenced in butracker #194 which has some
errors (e.g. beginning of log and beginning of dive are changed) and a lot of
bytes of unknown meaning. Example.log shows, at least, one more byte than those
referred in the paper for the O2 Aladin computer, this could be a byte referred
to the use of SCR but the lack of an OC dive with O2 computer makes impossible
for us to compare.
The only way we have figured out to distinguish a priori between SCR and non
SCR dives with O2 computers is that the dives are tagged with a "rebreather"
tag. Obviously this is not a very trusty way of doing things. In SCR dives,
the O2% in mix means, probably, the maximum O2% in the circuit, not the O2%
of the EAN mix in the tanks, which would be unknown in this case.
The list of DCs related in bug #194 paper seems incomplete, we have added
one or two from WLog and discarded those which are known to exist but whose
model is unknown, grouping them under the imaginative name of "unknown". The
list can easily be increased in the future if we ever know the models
identifiers.
BTW, in Example.log, 0x00 identifier is used for some DC dives and from my own
divelogs is inferred that 0x00 is used for manually entered dives, this could
easily be an error in Example.log coming from a preproduction DC model.
Example.log which is shipped in datatrak package is included in dives
directory for testing pourposes.
[Dirk Hohndel: some small cleanups, merged with latest master, support
divesites, remove the pointless memset() before free() calls
add to cmake build]
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2014-11-05 18:38:27 +00:00
|
|
|
|
2015-03-10 22:23:14 +00:00
|
|
|
#define read_string(_property) \
|
2017-05-07 12:26:56 +00:00
|
|
|
CHECK(membuf, tmp_1byte); \
|
2024-03-01 12:09:20 +00:00
|
|
|
{ \
|
2015-10-02 01:10:11 +00:00
|
|
|
unsigned char *_property##tmp = (unsigned char *)calloc(tmp_1byte + 1, 1); \
|
2024-03-01 12:09:20 +00:00
|
|
|
_property##tmp = (unsigned char*)memcpy(_property##tmp, membuf, tmp_1byte);\
|
2015-10-02 01:10:11 +00:00
|
|
|
_property = (unsigned char *)strcat(to_utf8(_property##tmp), ""); \
|
2017-05-07 09:44:47 +00:00
|
|
|
free(_property##tmp);\
|
2024-03-01 12:09:20 +00:00
|
|
|
JUMP(membuf, tmp_1byte); \
|
|
|
|
|
}
|
Import Datatrak/WLog files
Sequentially parses a file, expected to be a Datatrak/WLog divelog, and
converts the dive info into Subsurface's dive structure.
As my first DC, back in 90s, was an Aladin Air X, the obvious choice of log
software was DTrak (Win version). After using it for some time we moved to WLog
(shareware software more user friendly than Dtrak, printing capable, and still
better, it runs under wine, which, as linux user, was definitive for me). Then,
some years later, my last Aladin died and I moved to an OSTC, forcing me to
look for a software that support this DC.
I found JDivelog which was capable of import Dtrak logs and used it for some
time until discovered Subsurface existence and devoted to it.
The fact was that importing Dtrak dives in JDivelog and then re-importing them
in Subsurface caused a significant data loss (mainly in the profile events and
alarms) and weird location of some other info in the dive notes (mostly tag
items in the original Dtrak software). This situation can't actually be solved
with tools like divelogs.de which causes similar if no greater data loss.
Although this won't be a core feature for Subsurface, I expect it can be useful
for some other divers as has been for me.
Comments and issues:
Datatrak/Wlog files include a lot of diving data which are not directly
supported in Subsurface, in these cases we choose mostly to use "tags".
The lack of some important info in Datatrak archives (e.g. tank's initial
pressure) forces us to do some arbitrary assumptions (e.g. initial pressure =
200 bar).
There might be archives coming directly from old DOS days, as first versions
of Datatrak run on that OS; they were coded CP437 or CP850, while dive logs
coming from Win versions seems to be coded CP1252. Finally, Wlog seems to use a
mixed confusing style. Program directly converts some of the old encoded chars
to iso8859 but is expected there be some issues with non alphabetic chars, e.g.
"ª".
There are two text fields: "Other activities" and "Dive notes", both limited to
256 char size. We have merged them in Subsurface's "Dive Notes" although the
first one could be "tagged", but we're unsure that the user had filled it in
a tag friendly way.
WLog adds some information to the dive and lets the user to write more than
256 chars notes. This is achieved, while keeping compatibility with DTrak
divelogs, by adding a complementary file named equally as the .log file and
with .add extension where all this info is stored. We have, still, not worked
with this complementary files.
This work is based on the paper referenced in butracker #194 which has some
errors (e.g. beginning of log and beginning of dive are changed) and a lot of
bytes of unknown meaning. Example.log shows, at least, one more byte than those
referred in the paper for the O2 Aladin computer, this could be a byte referred
to the use of SCR but the lack of an OC dive with O2 computer makes impossible
for us to compare.
The only way we have figured out to distinguish a priori between SCR and non
SCR dives with O2 computers is that the dives are tagged with a "rebreather"
tag. Obviously this is not a very trusty way of doing things. In SCR dives,
the O2% in mix means, probably, the maximum O2% in the circuit, not the O2%
of the EAN mix in the tanks, which would be unknown in this case.
The list of DCs related in bug #194 paper seems incomplete, we have added
one or two from WLog and discarded those which are known to exist but whose
model is unknown, grouping them under the imaginative name of "unknown". The
list can easily be increased in the future if we ever know the models
identifiers.
BTW, in Example.log, 0x00 identifier is used for some DC dives and from my own
divelogs is inferred that 0x00 is used for manually entered dives, this could
easily be an error in Example.log coming from a preproduction DC model.
Example.log which is shipped in datatrak package is included in dives
directory for testing pourposes.
[Dirk Hohndel: some small cleanups, merged with latest master, support
divesites, remove the pointless memset() before free() calls
add to cmake build]
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2014-11-05 18:38:27 +00:00
|
|
|
|
|
|
|
|
#endif // DATATRAK_HEADER_H
|
