Aeris A300CS patches [V3]

[Jef Driesen]

On 12-10-14 04:25, Dirk Hohndel wrote:
> On Fri, Oct 10, 2014 at 02:20:20PM +0200, Jef Driesen wrote:
>>> 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.
>
> Sure. I used the patches that I sent you.
> I did exactly what you suggested I should do.
> It took about five attempts to get the drivers to install in Windows (what
> a crap OS that pile of rubbish is).
> After that all I did was to start the simulator on /dev/ttyGS0 and to have
> the Windows app talk to the fake device.

The Windows driver still fails to load for me. Not sure why.

> I wrote a few little scripts that allowed me to easily edit the data file
> that I used and then it was all just a matter of dealing with the
> unbearably stupid Aeris app. This thing is so bad, it wants me to go all
> Linus and curse and stuff.

:-)

>> 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;
>> }
>
> Yes, that is equivalent to my case statement.
>
>> 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
>
> Correct
>
>> guess that in real data, we'll only see these 4 bit patterns:
>>
>> 001 -> 1
>
> nope: 111 is what they use for 1 (1C, actually)
>
>> 010 -> 2
>> 100 -> 3
>> 000 -> 4
>
> I'll need to look what I can find in this week's dives as I simulated
> having two and three tanks.

Maybe it's something like this then:

111 -> 1
110 -> 2
100 -> 3
000 -> 4

Thus for every 1 bit one tank gets removed. If tanks can only be disabled in 
order (e.g. disabling the 3th tank is only allowed if the 4th tank is disabled 
too) that even makes sense.

Is it possible to disable all 4 tanks? Because that doesn't seem to be possible 
with just 3 bits. Could there be a 4th bit?

> BTW: your patches are completely unusable. I recommend against pushing
> them as they are and claiming A300CS support. At least not with my SOB
> line.
>
> I have 27 dives on my A300CS. The download has been running for 15 minutes
> now. We're on dive 6. No, you cannot simply say "oh, the A300CS supports
> B1, let's force using that". This turns a perfectly usable dive computer
> which downloads half a dozen dives in under 10 seconds into a completely
> unusable piece of garbage that takes forever to download a day's worth of
> diving.

There's probably a performance difference of roughly a factor 16 between the B1 
and B8 commands.

 From your previous email, I understood that you were okay with already applying 
those 4 patches now and postpone the implementation of the more efficient B8 
command later. But if you prefer to wait until we have a complete solution 
that's fine too.

The current status is as follows:

1. Your patch #1 changes the multipage code to always create aligned reads. But 
the vtpro and veo250 backends, for which the multipage algorithm was created, 
doesn't need aligned reads. So this results in more I/O operations. Probably not 
a great deal on its own, but if possible I would like to avoid this.

One question for you. Did you tried unaligned reads on your A300CS. I know the 
Aeris/Oceanic software always does aligned reads, but that might be due to how 
it reads the data. It always starts at the first page, and then advances to the 
next. Of course this always results in aligned reads by definition. But maybe 
unaligned reads work too?

2. Your patch #2 switches between B1, B4 and B8 commands dynamically, depending 
on the alignment and length. But for the Aeris F11, it seems that it's not 
possible to use the B1 command for reading pages past 64K. If that's indeed 
correct (I'm still waiting for confirmation here), then we'll have to stick to 
one variant of the read command only.

So applying those two patches now, while there is good indication that they 
won't work for other devices, sounds like a bad idea. So that's why I proposed 
to already apply the other ones, and address the performance issue later, once 
we know exactly what we need there. But right now, I'm still waiting for 
confirmation on the F11 issue.

Jef