Mares Smart Apnea

Sun Sep 6 10:12:42 PDT 2015

Hi,

thanks for your answer.

I have some good news:

I have found thaf each diving session is made by:
1) 4 byte header. The first two are the total size in bytes of the diving
session
2) a sequence of "NSAMPLES" dives. Each dive is composed by a 14 bytes
preamble (with dive time, surface time, max depth, ...) and a stream of
exactly "divetime" 16-bit dive measurements.
3) an 80 bytes footer with the session overall data: date, time,
temperature, max depth, ... I noticed that bytes 37 and 38  of this footer
 contain the TOTAL_DIVETIME, and that bytes 76 and 77 contain NSAMPLES.

So, to read backwards the diving session one could move back
HEADER_SIZE + NSAMPLES * SAMPLE_HEADER_SIZE + 2 *
TOTAL_DIVETIME+FOOTER_SIZE bytes,

where

HEADER_SIZE=4
NSAMPLES = 16 bit value at -6 bytes from end of session
SAMPLE_HEADER_SIZE = 14
TOTAL_DIVETIME = 16 bit value at -44 bytes from end of session
FOOTER_SIZE = 80

At that address you will find the first item of the session data which is,
by the way, exactly its size

Attaching here an archive with:
- a dump of my DC generated printing the "data[][]" and the "buffer[][]"
variables in the mares_iconhd_extract_dives function (run.log.20150906)
- an annotated version of the above dump with my notes about the meanings
of the data (run.log.20150906.annotated)
- the output.bin file generated by the "universal" utility
- a folder with the dump of the mares SW that I used to decode the dumps.
They are all CSV files, with an ODS that I used to do some calculations.

The relevant sessions are DiveOrganizer_2015-08-31T10.08.00 (quite long)
and DiveOrganizer_2015-08-10T18.56.00 (only 2 dives)

My weekend spare time is over and I still have to figure out how to fit
this in the library :(

Ciao

G

2015-09-06 9:47 GMT+02:00 Jef Driesen <jef at libdivecomputer.org>:

> I m currently travelling and will send a more detailed answer later.
>
> The backwards reading is by design. We always download the most recent
> dives first. That allows to stop downloading once we detect a previously
> downloaded dive. Normally we download dive per dive and not a full memory
> dump, but that has not been implemented yet for the iconhd. Thus starting
> at the start isnt even possible (especially if we only have the eop
> pointer).
>
> The format you describe reminds me of the nemo freedive format, which also
> records an entire freedive session as a dive. I need to have a closer first
> (on a phone only right now), but we may need to hop through all the samples
> to find the start of the dive.
>
> Larger attachments are fine if they are helpful. Try to compress them to
> keep size as small as possible.
>
> On September 6, 2015 2:00:14 AM CEST, Giorgio Marzano <
> marzano.giorgio at gmail.com> wrote:
>>
>> Again on the Mares Smart Apnea topic.
>>
>> I think I have found a problem on the current SW implementation and I
>> need some advice. Sorry for the long message.
>>
>>
>> I have dumped my DC logbook, and some cross checking between the code and
>> the expected results from the mares SW.
>>
>> I think I have found some problem in the code.
>> In the function  "mares_iconhd_extract_dives" it seems to me that the
>> code points to the very end of the buffer, then it starts crawling back to
>> the beginning of the last immersion:
>>
>> offset = layout->rb_profile_end - layout->rb_profile_begin;
>>
>>
>> unsigned int nbytes = 4 + headersize + nsamples * samplesize;
>> ...
>> // Move to the start of the dive.
>> offset -= nbytes;
>>
>> ...but it seems that on the Smart Apnea there is not a constant
>> samplesize: one immersion is a variable length (nsamples) sequence of dives
>> , each one having one header (dive time, surface time, temperature, ...)
>> and a stream of "dive time" depth measurements.
>>
>>
>> If this is true, the current approach can't work, as long as it is no
>> longer possible to compute "nbytes".
>>
>> Am I wrong?
>>
>> Is there any reason to start from the end and not from the beginning (the
>> "end of profile ring buffer" eop) and then move forward? I am getting
>> familiar with the memory layout of the DC but still have many many doubts
>> about the library code and architecture.
>>
>> Any help would be very appreciated. I can provide the annotated dump, but
>> I am not sure what the mailing list netiquette says about big attachments.
>>
>> Thank you in advance
>>
>> Giorgio
>>
>>
>> EXAMPLE:
>>
>> *** start immersion 2015 08 31 10.08
>>
>> 18 25 : LEN (in bytes)
>> 00 00 : ??
>> *** sample 1 ***
>> 0c 00 : maxdepth(1.2) sample 1
>> 13 00 : dive time (19 secs)
>> 00 00 : surface time (0)
>> fc 00 ??
>> fc 00 ??
>> 04 00 ??
>> 17 00 ??
>> 0b 00  depth //19 depth measurements: 1 per second
>> 0c 00 depth
>> 0b 00 depth
>> 0b 00 depth
>> 0b 00 depth
>> 0b 00 depth
>> 0b 00 depth
>> 0c 00 depth
>> 0c 00 depth
>> 0b 00 depth
>> 0b 00 depth
>> 0b 00 depth
>> 0b 00 depth
>> 0b 00 depth
>> 0b 00 depth
>> 0c 00 depth
>> 0b 00 depth
>> 0b 00 depth
>> 09 00 depth
>>
>> **** sample 2 ***
>> 11 00 maxdepth (1.2)
>> 2d 00 divetime
>> 3c 00 surftime
>> fc 00 ??
>> fc 00 ??
>> 05 00 ??
>> ...
>>
>> ------------------------------
>>
>> devel mailing list
>> devel at libdivecomputer.org
>> http://libdivecomputer.org/cgi-bin/mailman/listinfo/devel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20150906/d86a93e9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: annotated.tar.bz2
Type: application/x-bzip2
Size: 181378 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20150906/d86a93e9/attachment-0001.bin>