Free the buffer before terminating the process.
Signed-off-by: Claudiu Olteanu <olteanu.claudiu@ymail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Removed the packed struct and replaced with byte offsets.
Fixed salinity for EMC.
Added start temp for CMDR and Gemini.
[Dirk Hohndel: whitespace cleanup]
Signed-off-by: John Van Ostrand <john@vanostrand.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It seems that an iteration will happen even if the function
returns 0, but this looks like a non-breaking change.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
cochran_parse_samples():
'ascent_rate' can be used at some point so we mark it
as unused with (void)
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I fixed up the decode and finished the parse for Cochran EMC, Commander
and Gemini computers. I suspect that this code may only work with files
from certain versions of Cochran Analyst. It works with my own CAN files
and with the samples that came with Analyst v4.01v.
A seemingly arbitrary offset of 0x4914 is needed to access data.
The previous code uses 0x4a14 and 0x4b14. I suspect these are from
different version of Analyst.
[Dirk Hohndel: whitespace cleanup, add files to subsurface.pro, made sure
this compiles without the corresponding patch to
libdivecomputer (that isn't upstream, yet), cleaned up the
usage of structs, removed a few unused variables]
Signed-off-by: John Van Ostrand <john@vanostrand.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I know everyone will hate it.
Go ahead. Complain. Call me names.
At least now things are consistent and reproducible.
If you want changes, have your complaint come with a patch to
scripts/whitespace.pl so that we can automate it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The Cochran CSV depth exports are indeed in tenths of feet, but the
decimal is always 0, 3, 5 or 8. Where the 3 and 8 are obviously 0.25
and 0.75 rounded up to one decimal place.
So Cochran does seem to be very much about imperial units, with depth
and cylinder pressure scaled by four (depth in quarter-foot increments,
pressume in 4-psi increments)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The code is pretty useless, the comments perhaps equally so. I'm trying
to figure out what the data pattern is for the cochran CAN files. There
definitely *is* a pattern, but it actually seems to be different for the
files of different people - and it's not obvious in any case.
There probably are multiple versions of the format, and there might be
things like "David has a high-pressure sensor, and Alex does not" going
on too.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This seems to do the dive data descrambling right for both files I have
access to. Except it uses a hardcoded (different) offset for the two.
I have yet to figure out how to automatically detect the offset itself
properly, so you have to compile for the right file.
I'll figure it out, but I'm committing this as a reasonable point in the
process.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It turns out the odd "different CAN files have different header offsets"
came from the fact that the decode block was different lengths, and I
had not picked the correct place to start - and instead had found two
different places that were at different offsets due to the decode block
length differences.
This fixes that up, and it looks like the dive header is correctly
descrambled (but what the data *means* is unclear, although there is now
an ASCII date and time visible, so at least one part of it is pretty
obvious).
The actual dive data unscrambling is still different for the two
test-files I have to play with, I do not know why.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This descrambles at least parts of the header data. Some of it has the
same pattern of data 4kB apart, it may be that there is a dive hiding in
there too (ie what I currently call a "header" may in fact be a header
_plus_ a dive).
But the 4kB thing may well be an artifact of the crazy scrambling code
itself. Who knows what kind of chunking the Cochran Analyst
"encryption" uses.
As with the dive data, there seems to be some offset differences between
different CAN files.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
So this descrambles all the dives in *one* of my cochran test files. I
still don't know what the dive data *means*, but it's not a random
jumble of bytes any more: there are very clear patterns.
However, the magic offsets that work for that particular CAN file are
not generic, because they don't work for another. So there is some
magic dynamic decoding that I don't know about. There is probably more
decode information in the initial decode block, over and beyond just the
scrambling bytes.
(The scrambling array is 234 bytes starting at 0x40001, but the first
actual *dive* data starts at 0x45e03, so there's tons of unknown stuff
in the file even outside the dives themselves)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Just do the hex-dump in the program, and print all the results to
standard output. Avoid the need to do 'od' by hand etc to see what
happens when you play with the decoder.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's broken, and currently only writes out a debug output file per dive.
I'm not sure I'll ever really be able to decode the mess that is the
Cochran ANalyst stuff, but I have a few test files, along with separate
depth info from a couple of the dives in question, so in case this ever
works I can at least validate it to some degree.
The file format is definitely very intentionally obscured, though.
Annoying. It's not like the Cochran software is actually all that good
(it's really quite a horribly nasty Windows-only app, I'm told).
Cochran Analyst is very much not the reason why people would buy those
computers. So Cochran making their computers harder to use with other
software is just stupid.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
