RATIO iX3M DEEP computers compatibility and connection/configuration problem

[Jef Driesen]

On 2017-08-21 16:51, Dirk Hohndel wrote:
> BTW: I have added some annotation in the Subsurface-branch to help us
> decide which dive computers to offer as choices on mobile devices
> (this is in src/descriptor.c):
> 
> [...]
> 
> This basically just adds a comment at the end of every line that
> follows a strict syntax: two slashes, one space, then a token. There
> can be more than one such comment, e.g.:
> 
>         /* Shearwater Petrel family */
>         {"Shearwater", "Petrel",    DC_FAMILY_SHEARWATER_PETREL, 3},
> // BT // BLE
>         {"Shearwater", "Petrel 2",  DC_FAMILY_SHEARWATER_PETREL, 4},
> // BT // BLE
>         {"Shearwater", "Nerd",      DC_FAMILY_SHEARWATER_PETREL, 5},  
> // BT
>         {"Shearwater", "Perdix",    DC_FAMILY_SHEARWATER_PETREL, 6},
> // BT // BLE
>         {"Shearwater", "Perdix AI", DC_FAMILY_SHEARWATER_PETREL, 7},  
> // BLE
> 
> (yes, I know this looks wrong, as the Petrel has no BLE version, but
> the Petrel 2 unfortunately identifies itself as Petrel).
> 
> Would you be willing to take a patch that adds this for
> libdivecomputer master? This would make our lives easier and it
> certainly shouldn't cause any problems on your end as this is all just
> comments...
> Please let me know and I'll be happy to submit one clean patch to just 
> add that.

I don't understand what you gain with those comments. I mean it's just 
comments. Don't you need this kind of info at runtime instead? Something 
like what I proposed for the I/O refactoring:

For the I/O refactoring, I'm already planning to add an extra field with 
the transport type. Since some devices support multiple transports, the 
transport type will need to change into a bitfield. So something like 
this:

{"Shearwater", "Petrel 2",  DC_FAMILY_SHEARWATER_PETREL, 4,
DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH | DC_TRANSPORT_BLE},

With this information, an application knows exactly which transport 
types are supported for each device, and can setup the appropriate I/O 
channel (built-in or custom implementation).

>> To find out what goes wrong, you'll need to enable the libdivecomputer 
>> logfile checkbox. Without the logfile, we have no idea where exactly 
>> it goes wrong. Screenshots are useless because they don't give the 
>> low-level detailed info.
> 
> I keep wanting to improve the error messages that we are able to give
> - right now the useless default error that implies incorrect
> permissions does a lot more harm than anything else. I just can't seem
> to find the time with all the other things on my plate. A feeling that
> I know you are well familiar with, Jef.
> 
> But until then, the libdivecomputer log file certainly is the correct
> next step. Actually, I might be able to add a quick and dirty change
> that suggests this to the user... then at least people using the test
> builds would get that hint.

Just an idea: Why not always enable the logfile? Then whenever the 
download fails, you can notify the user about the error as usual, but 
also point to the log file. You probably don't want to show the contents 
of the log, but just the location of the file. That makes it very easy 
to report errors, because all the info is right there. Diving Log does 
something similar, and it works very well.

Jef