Aeris A300CS patches [V3]

[Dirk Hohndel]

On Sun, Oct 12, 2014 at 12:08:10PM +0200, Jef Driesen wrote:
> >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.

There are multiple ways to install it. I think for me installing it from
within the Aeris app was what finally worked.

> >>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?

Careful. You don't "disable tanks" manually on the Aeris. It simply tells
you how many were used. So this value changes when you change gas.

> >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.

While I find this frustating, sure, go ahead, apply them. Carrying them
outside of libdivecomputer makes no sense.

> 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.

So let's just do the alignment if bigpage is 16.

> 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?

I tried and got NAK back. That's when I noticed that the multipage code
doesn't align the reads in the first place :-)

> 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.

Here I disagree. We have to stick with one variant FOR THE F11. There is
no reason to do suboptimal implementation for the other DCs just because
one of them doesn't support something. Again, we could trigger the
different behavior based on either the actual DC type or on whether
bigpage is 8 or 16.

> 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.

So let's apply the four and consider my proposal above for making the
other two not break older Oceanic devices.

/D