Incorrect tank info.

[Ďoďo]

O.K. So with D6 last changes are reading air and nitrox  correctly.

However there is one more bug. I was editing then the old dives and
changed the Nitrox to air, finished the editing then clicked second
times O.K. and ... nothing was changed. If it is feature and not a
bug, then I should be informed that I can not change the mix of
computer red data.

thanks

Dodo


On Fri, Sep 21, 2012 at 12:04 AM, Jef Driesen <jefdriesen at telenet.be> wrote:
> On 20-09-12 22:56, Dirk Hohndel wrote:
>>
>> Jef Driesen <jefdriesen at telenet.be> writes:
>>
>>> On 24-08-12 11:03, Jef Driesen wrote:
>>>>
>>>> What exactly happens if you set the device to air mode? Can you still
>>>> configure the gasmixes, or is access to the gasmix settings
>>>> completely
>>>> disabled? I'm just trying to understand the logic used by the device.
>>>> Then we can fix the libdivecomputer code to match that logic.
>>>>
>>>> Based on the comments so far, this seems to be what is happening:
>>>>
>>>> if (air) {
>>>>       Ignore the gasmix settings, and assume a single mix with air.
>>>> The
>>>> gasmix settings retain their previous (non-air) values only as a
>>>> convenience, so you don't have to adjust the settings for your next
>>>> nitrox and/or multigas dive, but they are not used.
>>>> } else {
>>>>       Use the gasmix settings.
>>>> }
>>>
>>>
>>> I would like to fix this issue before the 0.2.0 release. I have
>>> attached a work-in-progress patch that needs some testing. I think it's
>>> correct for the older generation models (Vyper 2, D9, etc), but I
>>> suspect that for the newer models (Helo2, D4i, D6i, D9tx, etc) the gas
>>> model byte is stored at a different offset.
>>>
>>> Normally I can easily test this kind of stuff myself, but for some
>>> reason the latest Suunto Dive Manager (SDM) doesn't accept arbitrary
>>> serial ports anymore. I guess there is some kind of check for the USB
>>> VID/PID, or the FTDI driver. I used to have a linux kernel module to
>>> emulate an FTDI usb-serial chip (using the usb gadget interface), but it
>>> doesn't compile anymore with recent kernels :-( So for now, I can't get
>>> my test data into SDM to confirm the patch is correct, and thus I need
>>> some testing with real hardware.
>>
>>
>> There's this guy on this mailing list who might be able to help you with
>> getting this to compile under the latest Linux kernel. Have you asked
>> him for help? :-)
>
>
> No, I didn't ask. But I'm sure he reads this :-)
>
> I made some progress today. The virtual FTDI module compiles again, and I
> can even get the FTDI driver to recognize the virtual device, but I can't
> get any data passing through it.
>
> Anyway, if anyone wants to have a look, the source code is located here:
>
> http://www.divesoftware.org/libdc/tmp/serial-module.tar.bz2
> http://www.divesoftware.org/libdc/tmp/ftdi-module.tar.bz2
>
> The first one is the code that used to work (on kernel 2.6.X, where X was
> something like 39 I think). The second one is my current rewrite (using code
> from kernel 3.3.0).
>
>
>> Also, Linus, you have a Vyper Air. Anyone else with Suuntu computers who
>> could help test Jef's code?
>
>
> I have an updated patch attached. For the older devices, I can still use an
> older version of SDM (2.x), and everything looks good for the few devices I
> tried. The newer devices (Helo2, D4i, D6i, D9tx) are the problematic ones
> because they are only supported with a recent version of SDM (3.x). As far
> as I can tell from just the parser output it looks okay, but I can't confirm
> with data from SDM.
>
> I don't think the patch is any worse than the current code, so if necessary
> I can release it without testing. But being able to test is always better of
> course.
>
> Jef
>
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>