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

2015-09-06 9:47 GMT+02:00 Jef Driesen <jef@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@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@libdivecomputer.org
http://libdivecomputer.org/cgi-bin/mailman/listinfo/devel