Hi,
I reverse engineered a bit the M1 data format and would like to add events like "deco", "slow warning" etc in the data stream. Actually the format is similar to other mares computers (nemo), just shifted a bit. How do I submit patches?
Tschau,
Björn
On 2012-03-26 21:47, Björn Spruck wrote:
I reverse engineered a bit the M1 data format and would like to add events like "deco", "slow warning" etc in the data stream. Actually the format is similar to other mares computers (nemo), just shifted a bit. How do I submit patches?
You can send your patches directly to me, or the mailinglist. Preferably patches generated with 'git format-patch' such that a proper commit message, author name, etc is already in place. But if you're not familiar with git, don't worry, I accept plain patches too.
Please note that the events as they exist now, are deprecated and will be removed in the near future. The current design (which is heavily biased towards the Suunto's) isn't scalable to the large number of devices supported by the libdivecomputer library. There is no (final) replacement design yet, but I'm leaning towards delivering events as raw binary data (so no information is ever lost) and simply document the format. See also item #6 on the roadmap:
http://sourceforge.net/mailarchive/forum.php?thread_name=4EEBBA98.6080606%40...
Jef
Am 27.03.2012 10:28, schrieb Jef Driesen:
You can send your patches directly to me, or the mailinglist. Preferably patches generated with 'git format-patch' such that a proper commit message, author name, etc is already in place. But if you're not familiar with git, don't worry, I accept plain patches too.
Please note that the events as they exist now, are deprecated and will be removed in the near future.
"near" is order(month) or order(year)? Anyway I think its worth adding this even so it will be removed lateron.
The current design (which is heavily biased towards the Suunto's) isn't scalable to the large number of devices
supported by the libdivecomputer library. There is no (final) replacement design yet, but I'm leaning towards delivering events as raw binary data (so no information is ever lost) and simply document the format. See also item #6 on the roadmap:
sound good. Is there some documentation of the internal formats (beside the decoding/parser sourcecode) yet?
PS: for debugging it would be nice if one can re-parse an already downloaded dump. Is this foreseen somehow?
On 2012-03-27 10:47, Björn Spruck wrote:
Am 27.03.2012 10:28, schrieb Jef Driesen:
Please note that the events as they exist now, are deprecated and will be removed in the near future.
"near" is order(month) or order(year)?
Usually I don't give time frames, because it greatly depends on the amount of spare time I have available to work on the libdivecomputer. And as many people, I'm always short of free time. Need to reserve some time to go diving/photography too :-)
But it should be closer to months.
Anyway I think its worth adding this even so it will be removed lateron.
I agree. If it's already in the code, it's less likely I'll forget to port it to the new api, whatever that will be :-)
Is there some documentation of the internal formats (beside the decoding/parser sourcecode) yet?
Some formats were already documented, and I maintain links here:
http://www.divesoftware.org/libdc/links.html
I intend to cleanup and publish my internal notes on the libdivecomputer website some day, but at the moment I simply don't have the time for it. Anyway, the result should be something like this page I made for the Uemis:
http://www.divesoftware.org/libdc/uemis.html
PS: for debugging it would be nice if one can re-parse an already downloaded dump. Is this foreseen somehow?
This is already possible today. I have written a dive computer simulator tool that emulates the communication protocol and serves a memory dump loaded from a file to an application. This is a great aid during development because it allows me to work without needing any real hardware. At the moment the simulator isn't available from the website, because it started live for internal purpose only, which means ugly (but functional) code. But if there is a demand, I don't mind sending it on request or even making it available for download as-is.
To use it you'll have to setup your development environment according to these instructions:
http://www.divesoftware.org/libdc/simulator.html
An alternative is to use the xxx_extract_dives() functions. These functions parse a full memory dump and extract the individual dives, like the device_foreach() does. In fact if an xxx_extract_dives() function is present, that means the device_foreach() function will call it internally. These functions were never intended to be used by applications, but they ended up in the public api for testing purposes. At some point these functions will be removed from the public api, because applications shouldn't use them. But we could always provide some configuration option to export them anyway for debugging builds, or something like that.
Jef
Some formats were already documented, and I maintain links here:
the mares nemo link is dead. do you have a local copy?
I intend to cleanup and publish my internal notes on the libdivecomputer website some day, but at the moment I simply don't have the time for it. Anyway, the result should be something like this page I made for the Uemis:
maybe it would be nice to add that tho the repo as documentation?
On 2012-03-27 12:21, Björn Spruck wrote:
Some formats were already documented, and I maintain links here:
the mares nemo link is dead. do you have a local copy?
Yes. I uploaded it here:
http://www.divesoftware.org/libdc/tmp/iris.html
I intend to cleanup and publish my internal notes on the libdivecomputer website some day, but at the moment I simply don't have the time for it. Anyway, the result should be something like this page I made for the Uemis:
maybe it would be nice to add that tho the repo as documentation?
Or maybe a wiki to make editing a little easier?
Jef
--- /tmp/tmpo7eqew-meld/src/mares_darwin_parser.c +++ /home/bjoern/Dokumente/libdivecomputer/src/mares_darwin_parser.c @@ -185,21 +185,60 @@
unsigned int time = 0;
- unsigned int pressure = array_uint16_be (abstract->data + 0x17); + int temperature = abstract->data [10] ;// in M1 this is temp in °C + unsigned int pressure = array_uint16_be (abstract->data + 0x17);
unsigned int offset = parser->headersize; while (offset + parser->samplesize <= abstract->size) { parser_sample_value_t sample = {0}; + + unsigned int value = array_uint16_le (abstract->data + offset); + unsigned int depth = value & 0x07FF; + unsigned int ascent = (value & 0xE000) >> 13;/// ascent 0-5 seen, (6&7 not possible from display) + ///bool violation = (value & 0x1000);/// this is a guess, to be verified!!! + unsigned int deco = (value & 0x0800)!=0; /// boolean
// Surface Time (seconds). time += 20; sample.time = time; if (callback) callback (SAMPLE_TYPE_TIME, sample, userdata);
+ if( temperature!=-1){ + sample.temperature=temperature; + if (callback) callback (SAMPLE_TYPE_TEMPERATURE, sample, userdata); + temperature=-1; + } + // Depth (1/10 m). - unsigned int depth = array_uint16_le (abstract->data + offset) & 0x07FF; sample.depth = depth / 10.0; if (callback) callback (SAMPLE_TYPE_DEPTH, sample, userdata); + + // Ascent rate + if (ascent>0) { + sample.event.type = SAMPLE_EVENT_ASCENT; + sample.event.time = 0; + sample.event.flags = 0; + sample.event.value = ascent; + if (callback) callback (SAMPLE_TYPE_EVENT, sample, userdata); + } + + // Deco violation? +// if (violation) { +// sample.event.type = SAMPLE_EVENT_CEILING; +// sample.event.time = 0; +// sample.event.flags = 0; +// sample.event.value = 0; +// if (callback) callback (SAMPLE_TYPE_EVENT, sample, userdata); +// } + + // Deco stop + if (deco) { + sample.event.type = SAMPLE_EVENT_DECOSTOP; + sample.event.time = 0; + sample.event.flags = 0; + sample.event.value = 0; + if (callback) callback (SAMPLE_TYPE_EVENT, sample, userdata); + }
if (parser->samplesize == 3) { unsigned int type = (time / 20 + 2) % 3;
-
Björn Spruck -
Jef Driesen