Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Stephen Goodall]

Hi Christof,
The Cressi worked 😁
The Suunto said there was an error (attached) - I've not used this on my
phone before as it's my partner's computer so it's possible that I'm doing
something wrong with it! It did read it and show the device ID so it must
be talking to it.

On both of them, the intent thing pops up and the Cressi/Suunto is pre
selected still like it used to. I just picked the model and the usb serial
option, then force download all dives to be sure.

Cheers!

On Sun, 8 Mar 2020, 3:26 am Christof Arnosti, <charno at charno.ch> wrote:

> Hi Stephen,
>
> I hope that it will work with most computers using usb-to-serial
> interfaces. The underlying usb-serial-for-android implementation supports
> quite some chipsets.
>
> I'd love for you to test the implementation!
>
> You can grab a CI-Built apk from
> https://github.com/Subsurface-divelog/subsurface/suites/505662208/artifacts/2634973
> for testing. The source can be found at
> https://github.com/charno/subsurface/tree/android-serial-clean, the pull
> request at https://github.com/Subsurface-divelog/subsurface/pull/2647.
>
> Best regards
> Christof
> On 07.03.20 17:22, Stephen Goodall wrote:
>
> Will this affect all USB computers with Android? Very exciting!! I had a
> look but made no progress (C++ is not something I've worked with so it
> would have been a miracle if I had made progress :D )
>
> I've got a Cressi Leonardo and a Suunto Zoop, and an Android 9 phone if
> you want me to test those out with any changes. Let me know the branch and
> I can build it and test it out
>
> Cheers!
>
> On Sun, 8 Mar 2020, 3:14 am Dirk Hohndel via subsurface, <
> subsurface at subsurface-divelog.org> wrote:
>
>>
>>
>> On Mar 7, 2020, at 5:27 AM, Christof Arnosti <charno at charno.ch> wrote:
>>
>> Hi Dirk,
>>
>> I did the integration of the Icon HD VID/PID pair, so if the testing is
>> successful I think there is nothing left for me to do before a merge.
>>
>>
>> I will play with this in a couple of hours and most likely merge your
>> changes.
>>
>> Someone just tested with an Mares Nemo Wide (Serial < 50000), and it did
>> also work.
>>
>>
>> Excellent.
>>
>> Just for clarification about the possible UI changes (now that I'm more
>> awake again), I would envision a workflow like this:
>> - When opening the divecomputer-screen, or pressing the refresh button
>> ("Neu Scannen" in german), get all UsbDevices by issuing
>> UsbManager.getDeviceList(). Use these to populate the connection
>> ("Verbindung") list. (Only show the entries with specified driver-class
>> when this is activated in the settings). I think there has to be done some
>> work in the bt-discovery part so that these two mechanisms can work
>> together.
>>
>>
>> I'm not sure what you mean by only showing the entries with a specified
>> driver class. I thought the driver class is something that you would select
>> in that Connection drop down as an alternative to the found devices.
>> My guess is that on the vast, vast majority of Android devices you will
>> only ever get one USB device. Maybe if someone uses a hub for some reason
>> (maybe to power the phone while reading dives?) one might see more, but in
>> general that would surprise me.
>> So we should optimize the user experience for the common case. Which
>> means to try and identify the one USB serial device that is connected.
>>
>> - When a device from the connection list is selected, maybe try to guess
>> Vendor / Model by data provided in the UsbDevice-Object. There is already
>> some code in QMLManager::showDownloadPage. I'm not sure how much there can
>> be done since it seems that a lot of devices use the same PID/VIDs.
>>
>>
>> Correct - I played with that back when working on the Intent code and
>> while there are a couple you can explicitly identify, for most that is not
>> possible
>>
>> - When the download-button is pressed, the UsbDevice-Object of the
>> selected connection (and if selected the name of the driver-class) should
>> be passed to serial_android_usb_open. From there on I can do the work.
>>
>>
>> So again, you are suggesting to have a second (or actually, fourth?) drop
>> down with a driver class?
>>
>> There would probably also have to be done some changes when receiving the
>> USB_DEVICE_ATTACHED intent so that the correct entry of the list is
>> preselected.
>>
>>
>> I believe so.
>>
>> /D
>> _______________________________________________
>> subsurface mailing list
>> subsurface at subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200308/2132de89/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20200308-034201.jpg
Type: image/jpeg
Size: 695477 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200308/2132de89/attachment-0001.jpg>