Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed
Christof Arnosti
charno at charno.ch
Sat Mar 7 08:59:46 PST 2020
Hi Stephen,
On 07.03.20 17:46, Stephen Goodall wrote:
> Hi Christof,
> The Cressi worked 😁
Good to hear!
> 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.
Not so good to hear...
I'm sure you did it the right way, but Suunto Zoop and Suunto Zoop Novo
use different driver classes, you did select the correct one?
Sadly libdivecomputer is built with logging disabled for subsurface, so
the generic error message "Dive data import error" is the only thing I
get here, and from this I don't really have a point to start working on.
@Dirk: Since I would expect that there might be quite some errors when
trying to import with the new method, would it be possible to enable
libdivecomputer-logging for android builds? Also, would these messages
also end up in the log which is accessible from inside the application?
Best regards
Christof
>
> 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
> <mailto: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
>> <mailto:subsurface at subsurface-divelog.org>> wrote:
>>
>>
>>
>>> On Mar 7, 2020, at 5:27 AM, Christof Arnosti
>>> <charno at charno.ch <mailto: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
>> <mailto: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/20200307/ca140bc7/attachment.html>
More information about the subsurface
mailing list