RATIO iX3M DEEP computers compatibility and connection/configuration problem

[Dirk Hohndel]

Hi Jef,

Thanks for these clarification - this really helps.

> On Aug 21, 2017, at 7:23 AM, Jef Driesen <jef at libdivecomputer.org> wrote:
> 
> I suspect the correct port should be /dev/tty.usbserial-DN02DP66. The others are certainly not the correct for usb-serial adapters on Mac.

That was my assumption as well.

> In one of the screenshots, you have selected a model from the iDive series. That won't work with a model from the iX3M series. This is one of the cases where the actual model matters because there is a small but important difference in the communication protocol! (You can still choose any model from the iX3M series).
> 
> Support for the APOS4 firmware was added a few months ago, so I don't think that's the problem here. (Unless you are using a subsurface build where this change wasn't included yet.)

The latest binary that I made available a few hours ago (http://subsurface-divelog.org/downloads/test/Subsurface-4.6.4-736-g6554e4f21e4d.dmg) should have all changes that are in upstream libdivecomputer. We try to stay reasonably close to your code, as you know - it's getting increasingly difficult, but we'll do our best.

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):

static const dc_descriptor_t g_descriptors[] = {
        /* Suunto Solution */
        {"Suunto", "Solution", DC_FAMILY_SUUNTO_SOLUTION, 0},   // FTDI
        /* Suunto Eon */
        {"Suunto", "Eon",             DC_FAMILY_SUUNTO_EON, 0}, // FTDI
        {"Suunto", "Solution Alpha",  DC_FAMILY_SUUNTO_EON, 0},  // FTDI
        {"Suunto", "Solution Nitrox", DC_FAMILY_SUUNTO_EON, 0},  // FTDI
[...]
        /* Suunto EON Steel */
#ifdef USBHID
        {"Suunto", "EON Steel", DC_FAMILY_SUUNTO_EONSTEEL, 0},  // BLE
#endif
        /* Uwatec Aladin */
        {"Uwatec", "Aladin Air Twin",     DC_FAMILY_UWATEC_ALADIN, 0x1C},  // FTDI
        {"Uwatec", "Aladin Sport Plus",   DC_FAMILY_UWATEC_ALADIN, 0x3E},  // FTDI
[...]
        /* Uwatec Memomouse */
        {"Uwatec", "Memomouse", DC_FAMILY_UWATEC_MEMOMOUSE, 0},  // FTDI
        /* Uwatec Smart */
#ifdef IRDA
        {"Uwatec", "Smart Pro",     DC_FAMILY_UWATEC_SMART, 0x10},
        {"Uwatec", "Galileo Sol",   DC_FAMILY_UWATEC_SMART, 0x11},
        {"Uwatec", "Galileo Luna",  DC_FAMILY_UWATEC_SMART, 0x11},
   
etc.
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.

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

Thanks

/D