Re: Suunto Zoop log for Christof's android changes

[Miika Turkia via subsurface]

Official Suunto Vyper Air cable gives me this:

[63386.597279] usb 1-2: new full-speed USB device number 18 using xhci_hcd
[63386.752599] usb 1-2: New USB device found, idVendor=0403, idProduct=f680
[63386.752606] usb 1-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[63386.752611] usb 1-2: Product: Suunto Sports Instrument
[63386.752614] usb 1-2: Manufacturer: Suunto
[63386.752617] usb 1-2: SerialNumber: ST01
[63386.756520] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
[63386.756623] usb 1-2: Detected FT232BM
[63386.757039] usb 1-2: FTDI USB Serial Device converter now attached to
ttyUSB0

Unfortunately the cable is broken, so cannot test downloading with it.

On Wed, Mar 11, 2020 at 10:28 AM Miika Turkia 
wrote:

> Different cable, Vyper was a serial cable. I attached it using a random
> Chinese usb-serial adapter.
>
> On 11. Mar 2020, at 6.34, Christof Arnosti  wrote:
>
> 
>
> Hi Miika,
>
> Just a short question: Did you use the same cable for both the D4 and the
> Vyper? If not, could you also send me the PID/VID of the Vyper cable?
>
> Thanks
> Christof
> On 10.03.20 09:12, Miika Turkia wrote:
>
> Well, what do you know, everything worked with logcat running. Both D4 and
> Vyper Air started downloading fine. D4 ran all the way through. Vyper I
> terminated after a few dives were loaded. Will do more testing when I have
> time.
>
> On 10. Mar 2020, at 7.40, Miika Turkia 
>  wrote:
>
> 
> I should be able to run logcat once I have collected more test data. I
> just need to figure out how to do that over wifi or BT. Have always
> connected with usb cable before, but that is not an option this time :)
>
> BTW I just realized that Garmin is not supported, but it should probably
> be relatively easy to add. It is mounted as a disk and we need to just
> point to right mount point. Or am I missing something?
>
> On 10. Mar 2020, at 6.45, Christof Arnosti 
>  wrote:
>
> 
>
> Hi,
>
> Thanks. The Info (idVendor / idProduct) is already in the log you sent, so
> no need to download the app.
>
> I want to get some (more or less) statistical data about which
> usb-to-serial chipset behaves how. This is a big help! :)
>
> If you have some experience in the android world, could you maybe try to
> run "adb logcat" while downloading the dives? The logcat output might help
> with pinpointing the application crash, and I think until now yours is the
> only report of an actual application crash.
>
> Best regards
> Christof
> Am 09.03.20 um 23:39 schrieb Miika Turkia:
>
> On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface <
> subsurface@subsurface-divelog.org> wrote:
>
>> Thanks for the more in-depth ;-) test.
>>
>> Having a look at the serial-interface chipset-list at
>> http://libdivecomputer.org/drivers.html I noticed that suunto uses two
>> different chipsets. Maybe this could be a lead to follow up?
>>
>> Can the people owning a suunto computer maybe post the Vendor ID /
>> Product ID of their cable, and if it works or not? The App
>> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
>> shows these values.
>>
> This is what I get on dmesg when attaching the D4 cable:
> ---8<---
> [30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
> [30804.301648] usb 1-2: New USB device found, idVendor=0403, idProduct=6001
> [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [30804.301657] usb 1-2: Product: USB <-> Serial Cable
> [30804.301660] usb 1-2: Manufacturer: Smartinterface
> [30804.890118] usbcore: registered new interface driver ftdi_sio
> [30804.890187] usbserial: USB Serial support registered for FTDI USB
> Serial Device
> [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
> [30804.890728] usb 1-2: Detected FT232RL
> [30804.891105] usb 1-2: FTDI USB Serial Device converter now attached to
> ttyUSB0
> ---8<---
>
> Downloading from D4 with this cable on Android 7.1.1, the Subsurface
> crashes after about 4 dives. Do you think the OTG cable plays a part on
> this? I can try the app you mention if that would be beneficial.
>
> miika
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Miika Turkia via subsurface]

Different cable, Vyper was a serial cable. I attached it using a random Chinese 
usb-serial adapter.

> On 11. Mar 2020, at 6.34, Christof Arnosti  wrote:
> 
> 
> Hi Miika,
> 
> Just a short question: Did you use the same cable for both the D4 and the 
> Vyper? If not, could you also send me the PID/VID of the Vyper cable?
> 
> Thanks
> Christof
> 
>> On 10.03.20 09:12, Miika Turkia wrote:
>> Well, what do you know, everything worked with logcat running. Both D4 and 
>> Vyper Air started downloading fine. D4 ran all the way through. Vyper I 
>> terminated after a few dives were loaded. Will do more testing when I have 
>> time.
>> 
>>> On 10. Mar 2020, at 7.40, Miika Turkia  wrote:
>>> 
>>> 
>>> I should be able to run logcat once I have collected more test data. I just 
>>> need to figure out how to do that over wifi or BT. Have always connected 
>>> with usb cable before, but that is not an option this time :)
>>> 
>>> BTW I just realized that Garmin is not supported, but it should probably be 
>>> relatively easy to add. It is mounted as a disk and we need to just point 
>>> to right mount point. Or am I missing something?
>>> 
 On 10. Mar 2020, at 6.45, Christof Arnosti  wrote:
 
 
 Hi,
 
 Thanks. The Info (idVendor / idProduct) is already in the log you sent, so 
 no need to download the app.
 
 I want to get some (more or less) statistical data about which 
 usb-to-serial chipset behaves how. This is a big help! :)
 
 If you have some experience in the android world, could you maybe try to 
 run "adb logcat" while downloading the dives? The logcat output might help 
 with pinpointing the application crash, and I think until now yours is the 
 only report of an actual application crash.
 
 Best regards
 Christof
 
 Am 09.03.20 um 23:39 schrieb Miika Turkia:
> On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface 
>  wrote:
>> Thanks for the more in-depth ;-) test.
>> 
>> Having a look at the serial-interface chipset-list at 
>> http://libdivecomputer.org/drivers.html I noticed that suunto uses two 
>> different chipsets. Maybe this could be a lead to follow up? 
>> 
>> Can the people owning a suunto computer maybe post the Vendor ID / 
>> Product ID of their cable, and if it works or not? The App  
>> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
>>  shows these values.
>> 
> This is what I get on dmesg when attaching the D4 cable:
> ---8<---
> [30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
> [30804.301648] usb 1-2: New USB device found, idVendor=0403, 
> idProduct=6001
> [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=0
> [30804.301657] usb 1-2: Product: USB <-> Serial Cable
> [30804.301660] usb 1-2: Manufacturer: Smartinterface
> [30804.890118] usbcore: registered new interface driver ftdi_sio
> [30804.890187] usbserial: USB Serial support registered for FTDI USB 
> Serial Device
> [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
> [30804.890728] usb 1-2: Detected FT232RL
> [30804.891105] usb 1-2: FTDI USB Serial Device converter now attached to 
> ttyUSB0
> ---8<---
> 
> Downloading from D4 with this cable on Android 7.1.1, the Subsurface 
> crashes after about 4 dives. Do you think the OTG cable plays a part on 
> this? I can try the app you mention if that would be beneficial.
> 
> miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Christof Arnosti via subsurface]

Hi Miika,

Just a short question: Did you use the same cable for both the D4 and
the Vyper? If not, could you also send me the PID/VID of the Vyper cable?

Thanks
Christof

On 10.03.20 09:12, Miika Turkia wrote:
> Well, what do you know, everything worked with logcat running. Both D4
> and Vyper Air started downloading fine. D4 ran all the way through.
> Vyper I terminated after a few dives were loaded. Will do more testing
> when I have time.
>
>> On 10. Mar 2020, at 7.40, Miika Turkia  wrote:
>>
>> 
>> I should be able to run logcat once I have collected more test data.
>> I just need to figure out how to do that over wifi or BT. Have always
>> connected with usb cable before, but that is not an option this time :)
>>
>> BTW I just realized that Garmin is not supported, but it should
>> probably be relatively easy to add. It is mounted as a disk and we
>> need to just point to right mount point. Or am I missing something?
>>
>>> On 10. Mar 2020, at 6.45, Christof Arnosti  wrote:
>>>
>>> 
>>>
>>> Hi,
>>>
>>> Thanks. The Info (idVendor / idProduct) is already in the log you
>>> sent, so no need to download the app.
>>>
>>> I want to get some (more or less) statistical data about which
>>> usb-to-serial chipset behaves how. This is a big help! :)
>>>
>>> If you have some experience in the android world, could you maybe
>>> try to run "adb logcat" while downloading the dives? The logcat
>>> output might help with pinpointing the application crash, and I
>>> think until now yours is the only report of an actual application crash.
>>>
>>> Best regards
>>> Christof
>>>
>>> Am 09.03.20 um 23:39 schrieb Miika Turkia:
 On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface
 >>> > wrote:

 Thanks for the more in-depth ;-) test.

 Having a look at the serial-interface chipset-list at
 http://libdivecomputer.org/drivers.html I noticed that suunto
 uses two different chipsets. Maybe this could be a lead to
 follow up?

 Can the people owning a suunto computer maybe post the Vendor
 ID / Product ID of their cable, and if it works or not? The
 App 
 
 https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
 shows these values.

 This is what I get on dmesg when attaching the D4 cable:
 ---8<---
 [30804.146977] usb 1-2: new full-speed USB device number 12 using
 xhci_hcd
 [30804.301648] usb 1-2: New USB device found, idVendor=0403,
 idProduct=6001
 [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2,
 SerialNumber=0
 [30804.301657] usb 1-2: Product: USB <-> Serial Cable
 [30804.301660] usb 1-2: Manufacturer: Smartinterface
 [30804.890118] usbcore: registered new interface driver ftdi_sio
 [30804.890187] usbserial: USB Serial support registered for FTDI
 USB Serial Device
 [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter
 detected
 [30804.890728] usb 1-2: Detected FT232RL
 [30804.891105] usb 1-2: FTDI USB Serial Device converter now
 attached to ttyUSB0
 ---8<---

 Downloading from D4 with this cable on Android 7.1.1, the
 Subsurface crashes after about 4 dives. Do you think the OTG cable
 plays a part on this? I can try the app you mention if that would
 be beneficial.

 miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Jef Driesen via subsurface]

On 2020-03-10 01:22, Matt Thompson via subsurface wrote:

Device Path: /dev/bus/usb/001/002
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID:  0403
Vendor Name (reported):  Suunto
Vendor Name (from DB):  Future Technology Devices International, Ltd
Product ID:  f680
Product Name (reported):  Suunto Sports Instrument
Product Name (from DB):  not found


This the official interface from Suunto (FTDI 0403:f680).

Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Jef Driesen via subsurface]

On 2020-03-09 22:39, Miika Turkia via subsurface wrote:

This is what I get on dmesg when attaching the D4 cable:
---8<---
[30804.146977] usb 1-2: new full-speed USB device number 12 using 
xhci_hcd
[30804.301648] usb 1-2: New USB device found, idVendor=0403, 
idProduct=6001

[30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[30804.301657] usb 1-2: Product: USB <-> Serial Cable
[30804.301660] usb 1-2: Manufacturer: Smartinterface
[30804.890118] usbcore: registered new interface driver ftdi_sio
[30804.890187] usbserial: USB Serial support registered for FTDI USB 
Serial

Device
[30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter 
detected

[30804.890728] usb 1-2: Detected FT232RL
[30804.891105] usb 1-2: FTDI USB Serial Device converter now attached 
to

ttyUSB0


This is a third-party interface from Smartinterface (FTDI 0403:6001).


Downloading from D4 with this cable on Android 7.1.1, the Subsurface
crashes after about 4 dives. Do you think the OTG cable plays a part on
this? I can try the app you mention if that would be beneficial.


Can you send me the libdivecomputer log file from the download?

Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Miika Turkia via subsurface]

Well, what do you know, everything worked with logcat running. Both D4 and 
Vyper Air started downloading fine. D4 ran all the way through. Vyper I 
terminated after a few dives were loaded. Will do more testing when I have time.

> On 10. Mar 2020, at 7.40, Miika Turkia  wrote:
> 
> 
> I should be able to run logcat once I have collected more test data. I just 
> need to figure out how to do that over wifi or BT. Have always connected with 
> usb cable before, but that is not an option this time :)
> 
> BTW I just realized that Garmin is not supported, but it should probably be 
> relatively easy to add. It is mounted as a disk and we need to just point to 
> right mount point. Or am I missing something?
> 
>>> On 10. Mar 2020, at 6.45, Christof Arnosti  wrote:
>>> 
>> 
>> Hi,
>> 
>> Thanks. The Info (idVendor / idProduct) is already in the log you sent, so 
>> no need to download the app.
>> 
>> I want to get some (more or less) statistical data about which usb-to-serial 
>> chipset behaves how. This is a big help! :)
>> 
>> If you have some experience in the android world, could you maybe try to run 
>> "adb logcat" while downloading the dives? The logcat output might help with 
>> pinpointing the application crash, and I think until now yours is the only 
>> report of an actual application crash.
>> 
>> Best regards
>> Christof
>> 
>> Am 09.03.20 um 23:39 schrieb Miika Turkia:
>>> On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface 
>>>  wrote:
 Thanks for the more in-depth ;-) test.
 
 Having a look at the serial-interface chipset-list at 
 http://libdivecomputer.org/drivers.html I noticed that suunto uses two 
 different chipsets. Maybe this could be a lead to follow up? 
 
 Can the people owning a suunto computer maybe post the Vendor ID / Product 
 ID of their cable, and if it works or not? The App  
 https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator 
 shows these values.
 
>>> This is what I get on dmesg when attaching the D4 cable:
>>> ---8<---
>>> [30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
>>> [30804.301648] usb 1-2: New USB device found, idVendor=0403, idProduct=6001
>>> [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2, 
>>> SerialNumber=0
>>> [30804.301657] usb 1-2: Product: USB <-> Serial Cable
>>> [30804.301660] usb 1-2: Manufacturer: Smartinterface
>>> [30804.890118] usbcore: registered new interface driver ftdi_sio
>>> [30804.890187] usbserial: USB Serial support registered for FTDI USB Serial 
>>> Device
>>> [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
>>> [30804.890728] usb 1-2: Detected FT232RL
>>> [30804.891105] usb 1-2: FTDI USB Serial Device converter now attached to 
>>> ttyUSB0
>>> ---8<---
>>> 
>>> Downloading from D4 with this cable on Android 7.1.1, the Subsurface 
>>> crashes after about 4 dives. Do you think the OTG cable plays a part on 
>>> this? I can try the app you mention if that would be beneficial.
>>> 
>>> miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Matt Thompson via subsurface]

On Mon, Mar 9, 2020 at 5:29 PM Christof Arnosti  wrote:

> Thanks for the more in-depth ;-) test.
>
> Having a look at the serial-interface chipset-list at
> http://libdivecomputer.org/drivers.html I noticed that suunto uses two
> different chipsets. Maybe this could be a lead to follow up?
>
> Can the people owning a suunto computer maybe post the Vendor ID / Product
> ID of their cable, and if it works or not? The App
> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
> shows these values.
>
> Best regards
> Christof
>
>  Details from my working cable:
  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):  Suunto
Vendor Name (from DB):  Future Technology Devices International, Ltd
Product ID:  f680
Product Name (reported):  Suunto Sports Instrument
Product Name (from DB):  not found
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Dirk Hohndel via subsurface]

Yes, you are missing that Android is taking away access to things that look 
like storage from regular apps.
You can access pictures and media files, but you can no longer just read 
storage... Well, in Android 10 you still can, in 11 this will go away.

https://developer.android.com/preview/privacy/storage 


Because of that, I haven't bothered to implement this.

/D

> On Mar 9, 2020, at 4:40 PM, Miika Turkia via subsurface 
>  wrote:
> 
> I should be able to run logcat once I have collected more test data. I just 
> need to figure out how to do that over wifi or BT. Have always connected with 
> usb cable before, but that is not an option this time :)
> 
> BTW I just realized that Garmin is not supported, but it should probably be 
> relatively easy to add. It is mounted as a disk and we need to just point to 
> right mount point. Or am I missing something?
> 
>> On 10. Mar 2020, at 6.45, Christof Arnosti  wrote:
>> 
>> 
>> Hi,
>> 
>> Thanks. The Info (idVendor / idProduct) is already in the log you sent, so 
>> no need to download the app.
>> 
>> I want to get some (more or less) statistical data about which usb-to-serial 
>> chipset behaves how. This is a big help! :)
>> 
>> If you have some experience in the android world, could you maybe try to run 
>> "adb logcat" while downloading the dives? The logcat output might help with 
>> pinpointing the application crash, and I think until now yours is the only 
>> report of an actual application crash.
>> 
>> Best regards
>> Christof
>> 
>> Am 09.03.20 um 23:39 schrieb Miika Turkia:
>>> On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface 
>>> >> > wrote:
>>> Thanks for the more in-depth ;-) test.
>>> 
>>> Having a look at the serial-interface chipset-list at 
>>> http://libdivecomputer.org/drivers.html 
>>>  I noticed that suunto uses two 
>>> different chipsets. Maybe this could be a lead to follow up? 
>>> 
>>> Can the people owning a suunto computer maybe post the Vendor ID / Product 
>>> ID of their cable, and if it works or not? The App  
>>> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator 
>>> 
>>>  shows these values.
>>> 
>>> This is what I get on dmesg when attaching the D4 cable:
>>> ---8<---
>>> [30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
>>> [30804.301648] usb 1-2: New USB device found, idVendor=0403, idProduct=6001
>>> [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2, 
>>> SerialNumber=0
>>> [30804.301657] usb 1-2: Product: USB <-> Serial Cable
>>> [30804.301660] usb 1-2: Manufacturer: Smartinterface
>>> [30804.890118] usbcore: registered new interface driver ftdi_sio
>>> [30804.890187] usbserial: USB Serial support registered for FTDI USB Serial 
>>> Device
>>> [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
>>> [30804.890728] usb 1-2: Detected FT232RL
>>> [30804.891105] usb 1-2: FTDI USB Serial Device converter now attached to 
>>> ttyUSB0
>>> ---8<---
>>> 
>>> Downloading from D4 with this cable on Android 7.1.1, the Subsurface 
>>> crashes after about 4 dives. Do you think the OTG cable plays a part on 
>>> this? I can try the app you mention if that would be beneficial.
>>> 
>>> miika
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Miika Turkia via subsurface]

I should be able to run logcat once I have collected more test data. I just 
need to figure out how to do that over wifi or BT. Have always connected with 
usb cable before, but that is not an option this time :)

BTW I just realized that Garmin is not supported, but it should probably be 
relatively easy to add. It is mounted as a disk and we need to just point to 
right mount point. Or am I missing something?

> On 10. Mar 2020, at 6.45, Christof Arnosti  wrote:
> 
> 
> Hi,
> 
> Thanks. The Info (idVendor / idProduct) is already in the log you sent, so no 
> need to download the app.
> 
> I want to get some (more or less) statistical data about which usb-to-serial 
> chipset behaves how. This is a big help! :)
> 
> If you have some experience in the android world, could you maybe try to run 
> "adb logcat" while downloading the dives? The logcat output might help with 
> pinpointing the application crash, and I think until now yours is the only 
> report of an actual application crash.
> 
> Best regards
> Christof
> 
> Am 09.03.20 um 23:39 schrieb Miika Turkia:
>> On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface 
>>  wrote:
>>> Thanks for the more in-depth ;-) test.
>>> 
>>> Having a look at the serial-interface chipset-list at 
>>> http://libdivecomputer.org/drivers.html I noticed that suunto uses two 
>>> different chipsets. Maybe this could be a lead to follow up? 
>>> 
>>> Can the people owning a suunto computer maybe post the Vendor ID / Product 
>>> ID of their cable, and if it works or not? The App  
>>> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator 
>>> shows these values.
>>> 
>> This is what I get on dmesg when attaching the D4 cable:
>> ---8<---
>> [30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
>> [30804.301648] usb 1-2: New USB device found, idVendor=0403, idProduct=6001
>> [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=0
>> [30804.301657] usb 1-2: Product: USB <-> Serial Cable
>> [30804.301660] usb 1-2: Manufacturer: Smartinterface
>> [30804.890118] usbcore: registered new interface driver ftdi_sio
>> [30804.890187] usbserial: USB Serial support registered for FTDI USB Serial 
>> Device
>> [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
>> [30804.890728] usb 1-2: Detected FT232RL
>> [30804.891105] usb 1-2: FTDI USB Serial Device converter now attached to 
>> ttyUSB0
>> ---8<---
>> 
>> Downloading from D4 with this cable on Android 7.1.1, the Subsurface crashes 
>> after about 4 dives. Do you think the OTG cable plays a part on this? I can 
>> try the app you mention if that would be beneficial.
>> 
>> miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Jef Driesen via subsurface]

On 9/03/2020 21:37, Christof Arnosti via subsurface wrote:
- Suunto D4 (uses SUUNTO_D9): App (or Download?) Crashes after about 4 
downloaded drives. There should be a mail with logs in the support mail address.


Do we have a download log for this case? That might give some more clues. I 
didn't find one in the mails. Without those logs we're flying blind, so it's 
always a good idea to provide them right away.


For better debugging I think Jef is right that it would be really nice to have 
timestamps in the libdc-logs. I attached a possible patch (porting of logfunc 
from libdivecomputer to libdivecomputer.c), but I'm currently away from my main 
computer. Maybe somebody could give it a try if it compiles and produces 
timestamps? With this we can check if the read-function still returns too early 
for whatever reason.


This patch won't compile because it tries to use functions and data structures 
from libdivecomputer that are not public.


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Christof Arnosti via subsurface]

Hi,

Thanks. The Info (idVendor / idProduct) is already in the log you sent,
so no need to download the app.

I want to get some (more or less) statistical data about which
usb-to-serial chipset behaves how. This is a big help! :)

If you have some experience in the android world, could you maybe try to
run "adb logcat" while downloading the dives? The logcat output might
help with pinpointing the application crash, and I think until now yours
is the only report of an actual application crash.

Best regards
Christof

Am 09.03.20 um 23:39 schrieb Miika Turkia:
> On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface
>  > wrote:
>
> Thanks for the more in-depth ;-) test.
>
> Having a look at the serial-interface chipset-list at
> http://libdivecomputer.org/drivers.html I noticed that suunto uses
> two different chipsets. Maybe this could be a lead to follow up?
>
> Can the people owning a suunto computer maybe post the Vendor ID /
> Product ID of their cable, and if it works or not? The App 
> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
> shows these values.
>
> This is what I get on dmesg when attaching the D4 cable:
> ---8<---
> [30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
> [30804.301648] usb 1-2: New USB device found, idVendor=0403,
> idProduct=6001
> [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [30804.301657] usb 1-2: Product: USB <-> Serial Cable
> [30804.301660] usb 1-2: Manufacturer: Smartinterface
> [30804.890118] usbcore: registered new interface driver ftdi_sio
> [30804.890187] usbserial: USB Serial support registered for FTDI USB
> Serial Device
> [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
> [30804.890728] usb 1-2: Detected FT232RL
> [30804.891105] usb 1-2: FTDI USB Serial Device converter now attached
> to ttyUSB0
> ---8<---
>
> Downloading from D4 with this cable on Android 7.1.1, the Subsurface
> crashes after about 4 dives. Do you think the OTG cable plays a part
> on this? I can try the app you mention if that would be beneficial.
>
> miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Miika Turkia via subsurface]

On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface <
subsurface@subsurface-divelog.org> wrote:

> Thanks for the more in-depth ;-) test.
>
> Having a look at the serial-interface chipset-list at
> http://libdivecomputer.org/drivers.html I noticed that suunto uses two
> different chipsets. Maybe this could be a lead to follow up?
>
> Can the people owning a suunto computer maybe post the Vendor ID / Product
> ID of their cable, and if it works or not? The App
> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
> shows these values.
>
This is what I get on dmesg when attaching the D4 cable:
---8<---
[30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
[30804.301648] usb 1-2: New USB device found, idVendor=0403, idProduct=6001
[30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[30804.301657] usb 1-2: Product: USB <-> Serial Cable
[30804.301660] usb 1-2: Manufacturer: Smartinterface
[30804.890118] usbcore: registered new interface driver ftdi_sio
[30804.890187] usbserial: USB Serial support registered for FTDI USB Serial
Device
[30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
[30804.890728] usb 1-2: Detected FT232RL
[30804.891105] usb 1-2: FTDI USB Serial Device converter now attached to
ttyUSB0
---8<---

Downloading from D4 with this cable on Android 7.1.1, the Subsurface
crashes after about 4 dives. Do you think the OTG cable plays a part on
this? I can try the app you mention if that would be beneficial.

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Christof Arnosti via subsurface]

Thanks for the more in-depth ;-) test.

Having a look at the serial-interface chipset-list at
http://libdivecomputer.org/drivers.html I noticed that suunto uses two
different chipsets. Maybe this could be a lead to follow up?

Can the people owning a suunto computer maybe post the Vendor ID /
Product ID of their cable, and if it works or not? The App 
https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
shows these values.

Best regards
Christof

Am 09.03.20 um 23:20 schrieb Matt Thompson via subsurface:
>
> On Mon, Mar 9, 2020 at 3:40 PM Christof Arnosti via subsurface
>  > wrote:
>
> Hi everybody,
>
> There seems to be some general problems with Suunto dive computer
> synchronisation.
>
> We got reports so far from the following Suunto computers which
> use some different libdivecomputer-classes (according to
> 
> https://github.com/Subsurface-divelog/subsurface/blob/master/descriptor3.tsv):
>
> - Suunto Zoop (uses SUUNTO_VYPER): Does not work. After
> Timeout-Fix: First read returns size=0
> - Suunto D4 (uses SUUNTO_D9): App (or Download?) Crashes after
> about 4 downloaded drives. There should be a mail with logs in the
> support mail address.
> - Suunto D4i (uses SUUNTO_D9): Report of working download
> - Suunto Vyper Air (uses SUUNTO_VYPER2): Gets stuck on
> "Connecting", might be because of unofficial cable.
>
> The "sleep and purge to surpress possible echo" thing seems to be
> exclusive to the suunto_vyper computers.
>
> What I find interesting is that the D4 and D4i (which are using
> the same driver suunto_d9) have different results.
>
> For my first round of testing with the D4i, I didn't have any new
> dives so I was tecnically only reporting that the communication was
> successful. I did a force download of all dives on my D4i and was able
> to successfully download ~150 dives.  I didn't check profiles but the
> dates and times looked reasonable.
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Matt Thompson via subsurface]

On Mon, Mar 9, 2020 at 3:40 PM Christof Arnosti via subsurface <
subsurface@subsurface-divelog.org> wrote:

> Hi everybody,
>
> There seems to be some general problems with Suunto dive computer
> synchronisation.
>
> We got reports so far from the following Suunto computers which use some
> different libdivecomputer-classes (according to
> https://github.com/Subsurface-divelog/subsurface/blob/master/descriptor3.tsv
> ):
>
> - Suunto Zoop (uses SUUNTO_VYPER): Does not work. After Timeout-Fix: First
> read returns size=0
> - Suunto D4 (uses SUUNTO_D9): App (or Download?) Crashes after about 4
> downloaded drives. There should be a mail with logs in the support mail
> address.
> - Suunto D4i (uses SUUNTO_D9): Report of working download
> - Suunto Vyper Air (uses SUUNTO_VYPER2): Gets stuck on "Connecting", might
> be because of unofficial cable.
>
> The "sleep and purge to surpress possible echo" thing seems to be
> exclusive to the suunto_vyper computers.
>
> What I find interesting is that the D4 and D4i (which are using the same
> driver suunto_d9) have different results.
>
> For my first round of testing with the D4i, I didn't have any new dives so
I was tecnically only reporting that the communication was successful. I
did a force download of all dives on my D4i and was able to successfully
download ~150 dives.  I didn't check profiles but the dates and times
looked reasonable.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Christof Arnosti via subsurface]

Hi everybody,

There seems to be some general problems with Suunto dive computer
synchronisation.

We got reports so far from the following Suunto computers which use some
different libdivecomputer-classes (according to
https://github.com/Subsurface-divelog/subsurface/blob/master/descriptor3.tsv):

- Suunto Zoop (uses SUUNTO_VYPER): Does not work. After Timeout-Fix:
First read returns size=0
- Suunto D4 (uses SUUNTO_D9): App (or Download?) Crashes after about 4
downloaded drives. There should be a mail with logs in the support mail
address.
- Suunto D4i (uses SUUNTO_D9): Report of working download
- Suunto Vyper Air (uses SUUNTO_VYPER2): Gets stuck on "Connecting",
might be because of unofficial cable.

The "sleep and purge to surpress possible echo" thing seems to be
exclusive to the suunto_vyper computers.

What I find interesting is that the D4 and D4i (which are using the same
driver suunto_d9) have different results.

For better debugging I think Jef is right that it would be really nice
to have timestamps in the libdc-logs. I attached a possible patch
(porting of logfunc from libdivecomputer to libdivecomputer.c), but I'm
currently away from my main computer. Maybe somebody could give it a try
if it compiles and produces timestamps? With this we can check if the
read-function still returns too early for whatever reason.

Best regards
Christof


Am 09.03.20 um 11:19 schrieb Stephen Goodall:
> Hi christof,
> I'm still getting "failed to receive answer" for the Suunto, Cressi is
> still working so the timeout change is good for that one and hasn't
> broken it or anything. Is the version below the correct one?
>
> Suunto:
>
> Subsurface: v4.9.3-1050-g38ca3f684202, built with libdivecomputer
> v0.7.0-devel-Subsurface-NG (0714e327b70bb08f5289c9781c09dc10884881c9)
> INFO: Open: transport=1
> INFO: Configure: baudrate=2400, databits=8, parity=1, stopbits=0,
> flowcontrol=0
> INFO: Timeout: value=1000
> INFO: DTR: value=1
> INFO: Sleep: value=100
> INFO: Purge: direction=3
> INFO: Sleep: value=500
> INFO: RTS: value=1
> INFO: Write: size=5, data=0500161407
> INFO: Sleep: value=200
> INFO: Purge: direction=1
> INFO: RTS: value=0
> INFO: Read: size=0, data=
> ERROR: Failed to receive the answer. [in
> /__w/subsurface/subsurface/libdivecomputer/src/suunto_vyper.c:212
> (suunto_vyper_transfer)]
>
>
> Is there any way to get more verbose libdivecomputer logs or something?
>
> Cheers
>
>
>
> On Mon, 9 Mar 2020, 2:26 am Christof Arnosti,  > wrote:
>
> Hi Stephen,
>
> The build with the improved timeout handling is finished, the
> result is at
> 
> https://github.com/Subsurface-divelog/subsurface/suites/506855270/artifacts/2655791
> . Can you test again with your computers?
>
> Thanks
> Christof
>
> On 08.03.20 15:38, Christof Arnosti wrote:
>>
>> So I just opened a pull request
>> (https://github.com/Subsurface-divelog/subsurface/pull/2656).
>> With this the CI will build the updated version and we can test
>> again with our computers. The Mares Puck Pro still works as expected.
>>
>> Best regards
>> Christof
>>
>> On 08.03.20 14:39, Christof Arnosti wrote:
>>>
>>> Hi Jef,
>>>
>>> Thanks for your comments.
>>>
>>> On 08.03.20 09:27, Jef Driesen wrote:
 On 8/03/2020 06:31, Dirk Hohndel wrote:
>> On Mar 7, 2020, at 9:17 PM, Stephen Goodall
>> > 
>> 
>> > wrote:
>> Subsurface: v4.9.3-1049-g4529add7053f, built with
>> libdivecomputer v0.7.0-devel-Subsurface-NG
>> (0714e327b70bb08f5289c9781c09dc10884881c9)
>> INFO: Open: transport=1
>> INFO: Configure: baudrate=2400, databits=8, parity=1,
>> stopbits=0, flowcontrol=0
>> INFO: Timeout: value=1000
>> INFO: DTR: value=1
>> INFO: Sleep: value=100
>> INFO: Purge: direction=3
>> INFO: Sleep: value=500
>> INFO: RTS: value=1
>> INFO: Write: size=5, data=0500161407
>> INFO: Sleep: value=200
>> INFO: Purge: direction=1
>> INFO: RTS: value=0
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: