Ratio ix3m Pro on Android

[liquid tcp]

On Thu, Sep 12, 2019 at 10:25 AM Anton Lundin <glance at acc.umu.se> wrote:

> On 11 September, 2019 - liquid tcp wrote:
>
> > On Wed, Sep 11, 2019 at 4:45 PM Anton Lundin <glance at acc.umu.se> wrote:
> >
> > > On 11 September, 2019 - Dirk Hohndel wrote:
> > >
> > > > On Wed, Sep 11, 2019 at 09:07:51AM +0200, liquid tcp wrote:
> > > > >
> > > > > Since I'm completely new to diving, let me first thank you all for
> what
> > > > > seems to me as the best available divelog!
> > > > >
> > > > > I do have a Ratio ix3m Pro (Deep) computer that downloads fine to
> > > subsurface
> > > > > In the Android app [2.2.0(4.9.1.40) - playstore beta] the pros are
> not
> > > > > listed, and I can't download the logs to subsurface-mobile (via
> USB-C
> > > > > adapter)
> > > >
> > > > The Pro models don't support BLE - and on Android support of cable
> based
> > > > downloads is mostly non-existant. Yes, for FTDI cables this appears
> to
> > > > work for a small number of people who's phones' Android version
> doesn't
> > > > block access to the way we try to open the USB port, but it appears
> for
> > > > the vast majority of phones even the FTDI download fails. And I
> /think/
> > > > the Ratio download cable isn't FTDI based, anyway.
> > > >
> > >
> > > Which serial chip do they use?
> > >
> > > Plug the dive computer into your phone and run a app like:
> > >
> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
> > >
> > > And send the info here, and I'll tell you.
> > >
> >
> > Like Ricardo wrote: FTDI FT230X Basic UART
> >
> > Device Info
> > Device Path: /dev/bus/usb/001/002
> > Device Class: Use class information in the Interface Descriptors (0x0)
> > Vendor ID:  0403
> > Vendor Name (reported):  FTDI
> > Vendor Name (from DB):  Future Technology Devices International, Ltd
> > Product ID:  6015
> > Product Name (reported):  FT230X Basic UART
> > Product Name (from DB):  not found
>
> Then its just our filter logic that needs updating.
>
> I'd love to be able to disable that logic for cases like this, and just
> show everything and let the user pick what device and communication
> method. Like we have the ShowNonDiveComputers , we should have a show
> all dive computers, even if they probably don't work.
>
> >
> > >
> > > > > Is there anything I can do to (help) make it available?
> > > > > Unfortunately I have never worked with C++ before (well, actually I
> > > only
> > > > > "played lego" with .Net ;-) except of some assembler basics back in
> > > school)
> > > > > I've tried and downloaded the repo, but must admit I do not yet
> > > understand
> > > > > the divecomputer interface, and didn't even find the android
> related
> > > code.
> > > > > so I fear I can't be much help with actual coding anytime soon
> > > >
> > > > We in theory know how this situation could be improved. But the only
> > > > developer who really seems to fully understand what needs to be done
> > > > doesn't have the time to work on this, and those who care enough and
> > > might
> > > > have the time, don't have sufficient understanding how to make the
> > > libusb2
> > > > integration with the native USB port access implementation on newer
> > > > Android work.
> > >
> >
> > OK, thanks. My phone does react kind of unexpected when I try to change
> the
> > USB mode from client to OTG (switching back stating couldn't switch)
> > So a workaround might be using an old android device as a downloader? Or
> > wouldn't this work anyways since the ProductID isn't implemented on
> > subsurface-mobile?
>
> Sounds like your phone isn't that healthy. OTG is a requirement to be
> able to download from a ftdi device.
>
> All the bits are there, just that the Ratio dc's isn't in the list of
> known ftdi dive computers.
>
> OTG is working fine with other devices. So i /think/ that is what Dirk
meant with Android blocking the way we access the USB.
I do have an older phone lying around in the office. I'll take it home and
see whether it behaves differently

> Well, on the other hand, downloading the dive shouldn't be so urgent that
> > it can't wait until I'm back on a real computer. - Since I'm not into
> tech
> > diving (yet) ;-)
>
> Downloading from a dc and tech diving have no correlation. Downloading
> data from your dc and keeping that in your logbook is one thing, tech
> diving is another thing.
>
> //Anton - Who thinks "Technical diving" is a really bad name
>
> What I meant to say: I don't need the detailed data for planning my next
dive. on the other hand, if I needed I'd most likely prefer a Notebook
anyways ;-)
Should I better say extended range?

best regards
Benji
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20190912/ed622ce0/attachment-0001.html>