RATIO iX3M DEEP computers compatibility and connection/configuration problem

Gregory Sin uranicus at gmail.com
Mon Aug 21 20:29:43 PDT 2017


Dear Dirk,

Please find testing result and files/log/screens below.

DC:			iX3M DEEP (Os 4.0.26/013). Clean DC, no dives logged.
Mac:			10.12.4
SUBSURF:	4.6.4.737
BT:			Only DC and Mouse are paired, but only DC connected.

No errors reported.
Can we carefully conclude that BT comm works? ;)
I will be try same DC with dives/log after one week and revert.
Sorry, we have 3 Ratio DC here, but all pristine new w/o dives.

Few more words.
It crashed on 10.9.5. No compatibility.

CONFIGURATION feature require development.

Guide me if I can help further.

thanks
Gregory



On 21 Aug, 2017, at 22:51, Dirk Hohndel <dirk at hohndel.org> wrote:

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170822/bd624355/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 170822_subsurface.log
Type: application/octet-stream
Size: 784 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170822/bd624355/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170822/bd624355/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-08-22 at 11.15.56.png
Type: image/png
Size: 114937 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170822/bd624355/attachment-0003.png>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170822/bd624355/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-08-22 at 11.16.50.png
Type: image/png
Size: 222251 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170822/bd624355/attachment-0004.png>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170822/bd624355/attachment-0008.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-08-22 at 11.18.24.png
Type: image/png
Size: 148385 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170822/bd624355/attachment-0005.png>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170822/bd624355/attachment-0009.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170822/bd624355/attachment-0001.sig>


More information about the subsurface mailing list