Aeris A300CS patches [V3]

[Jef Driesen]

On 2014-10-08 12:27, Dirk Hohndel wrote:
> On Tue, Oct 07, 2014 at 09:09:35PM +0200, Jef Driesen wrote:
>> On 02-10-14 19:49, Dirk Hohndel wrote:
>> So I would like to already go ahead and apply the other patches:
>> 
>> Patch #3 and #4 look good to me. As explained before, the DTR/RTS 
>> shouldn't
>> cause any problems for other devices, because if it did I would 
>> already had
>> received plenty of bug reports from Windows users. One minor issues is 
>> that
>> I'm pretty sure the rb_profile_end field of the layout is actually 
>> 0x3FE00
>> instead of 0x40000. That's why I asked you for a full memory dump.
> 
> Sorry, busy flying to Bonaire and diving.
> 
>> For patch #5, where did you get the density value 1003 from? According 
>> to
>> your patch, only the water type is stored in the data, but not the 
>> density.
>> Since this is optional value, maybe we better leave this as zero?
> 
> OK

I have attached a slightly modified versions of your four patches. If 
you're happy with the changes I made, I'll push them already to the 
master branch.

>> Patch #6 is the only one where I don't understand the logic. Are they 
>> really
>> using this very weird encoding, or are we missing something? Am I 
>> correct
>> that if only 1,2,3 or 4 tanks are enabled, these are always the first 
>> ones?
> 
> I spent an evening playing with the simulator and their app. Trying 
> every
> single value this is the logic that I found. I think it would be a nice
> feature not to get the unused tanks, but my confidence that this is 
> 100%
> correct is not 100% :-/. The problem is... the only way to get this 
> more
> widely tested is to add the code and wait if it works as expected in 
> all
> circumstances.

Does that mean you found the trick to make the Aeris application talk to 
the simulator? Can you share what you did, because I had so success so 
far.

I think I found the logic. Look at the three relevant bits:

001 -> 1
011 -> 1
101 -> 1
111 -> 1
010 -> 2
110 -> 2
100 -> 3
000 -> 4

There is clearly a pattern here. All 4 combinations that map to one tank 
have the lowest bit set. With two tanks, the second bit is set. And so 
on. Thus this code should do the trick:

if (data[0x39] & 0x04) {
     *((unsigned int *) value) = 1;
} else if (data[0x39] & 0x08) {
     *((unsigned int *) value) = 2;
} else if (data[0x39] & 0x10) {
     *((unsigned int *) value) = 3;
} else {
     *((unsigned int *) value) = 4;
}

I included this change already in the attached patches.

Originally I was puzzled by the fact that there are multiple ways to 
encode some values. And that makes no sense at all. But then I realized 
you probably made up data with the simulator to try all possible bit 
patterns. I guess that in real data, we'll only see these 4 bit 
patterns:

001 -> 1
010 -> 2
100 -> 3
000 -> 4

Jef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-initial-support-for-the-Aeris-A300CS.patch
Type: text/x-diff
Size: 8334 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141010/af8b4f16/attachment-0004.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Aeris-A300CS-add-support-for-NDL-deco-data.patch
Type: text/x-diff
Size: 1469 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141010/af8b4f16/attachment-0005.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Aeris-A300CS-add-reporting-of-water-type-fresh-salt.patch
Type: text/x-diff
Size: 1349 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141010/af8b4f16/attachment-0006.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Aeris-A300CS-detect-the-number-of-cylinders-used.patch
Type: text/x-diff
Size: 1858 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141010/af8b4f16/attachment-0007.patch>