help : is it possible to recover an old base on the cloud

[vavincavent via subsurface]

iIve written on my cloud with a new base and i've destroyed the old one.

Is it possible to recover the oldest?

Thanks a lot if someone can...

Vavincavent

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

Aladin square with Subsurface-mobile

[vavincavent]

Hi all,

I've try to connect my Aladin square divecomputer to Subsurface-mobile, 
but ... problem.

Divecomputer : Aladin square
Smartphone : Nexus 5X (OTG ok)
Subsurface-mobile : version 2.0.3 (4.7.7.52)

Can someone help me?

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

Re: lots of activity

[vavincavent]

ok Dirk,

Now i see the aladin square, but not functional.
perhaps problem with usb and my phone.
Divemate start automatiquely whent i connect the square.

Vincent

Le lundi 27 novembre 2017 à 10:28 -0800, Dirk Hohndel a écrit :
> > On Nov 27, 2017, at 8:30 AM, Dirk Hohndel <d...@hohndel.org> wrote:
> > > On Nov 27, 2017, at 2:48 AM, Vincent Cresson <vavincavent@gmail.c
> > > om> wrote:
> > > 
> > > Aladin Square not yet in beta 2.0.1(4.7.4.133)
> > 
> > I am puzzled by this. I have done some local experiments and the
> > build contains
> > all the right pieces and components, but it still doesn't show the
> > newly added dive
> > computers.
> > 
> > I need to dig a little deeper to understand why this isn't working
> > the way it is designed
> > to work, TBH.
> 
> :facepalm:
> 
> Yes, I can see why that didn’t work… I built a new libdivecomputer -
> but the build script
> picked up the old one instead.
> 
> Fixed. And Subsurface-mobile now also reports the versions of key
> libraries in its log
> to make it easier to spot things like this.
> 
> A new beta has been uploaded. It identifies as 4.7.4.135 - that one
> does support
> the Aladin Square and the other new dive computers. I verified this
> here (I can’t test
> it, though, as I of course don’t have an Aladin Square).
> 
> Sorry for the false starts.
> 
> /D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: problem with testing version of subsurface installation

[vavincavent]

It seems to be working just with exucuting build.sh with sudo...!!
vincent@ASUS-R558UV:~/src$ sudo ./subsurface/scripts/build.sh
I've joined new log file.
Vincent.

Le samedi 18 novembre 2017 à 08:13 -0800, Dirk Hohndel a écrit :
> Hi Vincent
> 
> > On Nov 18, 2017, at 4:45 AM, vavincavent <vavincav...@gmail.com>
> > wrote:
> > 
> > hi all, i've a problem with installation of subsurface.
> > I've made a fresh directory:
> > ~/src/
> > I've cloned subsurface :
> > vincent@ASUS-R558UV:~/src$ git clone https://github.com/Subsurface-
> > dive
> > log/subsurface.git
> > 
> > and used the installation script :
> > vincent@ASUS-R558UV:~/src$ ./subsurface/scripts/build.sh
> > the build.log is attached.
> 
> Which is full of French messages. As far as I've read this I think I
> can parse
> this, but yeah... that makes it harder :-)
> 
> I notice a few oddities in there already... for example it can't find
> ldconfig
> 
> Which OS are you on?
> 
> > When i do :
> > vincent@ASUS-R558UV:~/src/subsurface/build$ ./subsurface
> > I obtain an error message :
> > vincent@ASUS-R558UV:~/src/subsurface/build$ ./subsurface
> > MapWidget.qml: cannot find a plugin named: googlemaps
> > qrc:/MapWidget.qml:21: Error: Cannot assign [undefined] to
> > QDeclarativeGeoMapType*
> 
> Yes, there's a test in there that fails in line 439.
> Strangely, on many systems / bash versions this seems to work,
> but clearly for you it doesn't. I'll modify it to make it less likely
> to
> fail, but that's the reason why the googlemaps plugin isn't built
> for you.
> 
> I now want to know even more which OS you are building on.
> 
> /Dbuilding Subsurface in subsurface/build
Building in /home/vincent/src, installing in /home/vincent/src/install-root
La branche courante Subsurface-branch est à jour.
Déjà sur 'Subsurface-branch'
Votre branche est à jour avec 'origin/Subsurface-branch'.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
check

Re: problem with testing version of subsurface installation

[vavincavent]

Hi Dirk,

My OS is Debian :

vincent@ASUS-R558UV:~/src$ uname -a
Linux ASUS-R558UV 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28)
x86_64 GNU/Linux


Vincent.

Le samedi 18 novembre 2017 à 08:13 -0800, Dirk Hohndel a écrit :
> Hi Vincent
> 
> > On Nov 18, 2017, at 4:45 AM, vavincavent <vavincav...@gmail.com>
> > wrote:
> > 
> > hi all, i've a problem with installation of subsurface.
> > I've made a fresh directory:
> > ~/src/
> > I've cloned subsurface :
> > vincent@ASUS-R558UV:~/src$ git clone https://github.com/Subsurface-
> > dive
> > log/subsurface.git
> > 
> > and used the installation script :
> > vincent@ASUS-R558UV:~/src$ ./subsurface/scripts/build.sh
> > the build.log is attached.
> 
> Which is full of French messages. As far as I've read this I think I
> can parse
> this, but yeah... that makes it harder :-)
> 
> I notice a few oddities in there already... for example it can't find
> ldconfig
> 
> Which OS are you on?
> 
> > When i do :
> > vincent@ASUS-R558UV:~/src/subsurface/build$ ./subsurface
> > I obtain an error message :
> > vincent@ASUS-R558UV:~/src/subsurface/build$ ./subsurface
> > MapWidget.qml: cannot find a plugin named: googlemaps
> > qrc:/MapWidget.qml:21: Error: Cannot assign [undefined] to
> > QDeclarativeGeoMapType*
> 
> Yes, there's a test in there that fails in line 439.
> Strangely, on many systems / bash versions this seems to work,
> but clearly for you it doesn't. I'll modify it to make it less likely
> to
> fail, but that's the reason why the googlemaps plugin isn't built
> for you.
> 
> I now want to know even more which OS you are building on.
> 
> /D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

Jef, Linus,

In libdivecomputer library, we have 2 branches (libdivecomputer and
libdc). One is with uwatec_g2.c and the other with scubapro_g2.c.
Can you explain me the difference and wich one is the better for me?

Vincent.

Le mardi 14 novembre 2017 à 23:12 +0100, Jef Driesen a écrit :
> On 14-11-17 23:04, Linus Torvalds wrote:
> > On Tue, Nov 14, 2017 at 2:00 PM, vavincavent <vavincav...@gmail.com
> > > wrote:
> > > 
> > > Now i think it's the analysis of the datas???
> > 
> > Oh, I thought it already worked?
> > 
> > When  you ask subsurface to generate a dump file, it will not
> > actually
> > import the dives at all.
> > 
> > But now that the communication is working, uncheck that, and see if
> > the download just works and the dives get imported..
> 
> The parsing needs some changes too for the new model number. The
> attached patch 
> is what I have so far.
> 
> Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

Sorry, but i'm not a programmer, how to use this patch?
Do i need to download from git?

Vincent.

Le mardi 14 novembre 2017 à 23:12 +0100, Jef Driesen a écrit :
> On 14-11-17 23:04, Linus Torvalds wrote:
> > On Tue, Nov 14, 2017 at 2:00 PM, vavincavent <vavincav...@gmail.com
> > > wrote:
> > > 
> > > Now i think it's the analysis of the datas???
> > 
> > Oh, I thought it already worked?
> > 
> > When  you ask subsurface to generate a dump file, it will not
> > actually
> > import the dives at all.
> > 
> > But now that the communication is working, uncheck that, and see if
> > the download just works and the dives get imported..
> 
> The parsing needs some changes too for the new model number. The
> attached patch 
> is what I have so far.
> 
> Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

The download works, but the dives are not imported.

Vincent.

Le mardi 14 novembre 2017 à 14:04 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 2:00 PM, vavincavent <vavincav...@gmail.com>
> wrote:
> > 
> > Now i think it's the analysis of the datas???
> 
> Oh, I thought it already worked?
> 
> When  you ask subsurface to generate a dump file, it will not
> actually
> import the dives at all.
> 
> But now that the communication is working, uncheck that, and see if
> the download just works and the dives get imported..
> 
>  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

Download ok, but after i have an error message.
"impossible de créer un analyseur pour Scubapro
G2"

Serial number of the& dive computer is ok, but after...


Vincent.

Le mardi 14 novembre 2017 à 14:04 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 2:00 PM, vavincavent <vavincav...@gmail.com>
> wrote:
> > 
> > Now i think it's the analysis of the datas???
> 
> Oh, I thought it already worked?
> 
> When  you ask subsurface to generate a dump file, it will not
> actually
> import the dives at all.
> 
> But now that the communication is working, uncheck that, and see if
> the download just works and the dives get imported..
> 
>  Linus___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

Thanks a lot Linus for your help to pass the step, thanks to Jef too!

Now i think it's the analysis of the datas???

Berthold?

Vincent.

Le mardi 14 novembre 2017 à 13:50 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 1:44 PM, vavincavent <vavincav...@gmail.com>
> wrote:
> > YES!!
> > a step passed!
> 
> Ok. So it really was that "I want 32-byte only packets".
> 
> Will do it in upstream libdivecomputer, I've got some other things
> pending too. I'm just _also_ in the middle of the kernel merge
> window.
> 
> We'll have to figure out how to sanely do that USB ID thing sanely. I
> haven't looked at that yet. I think I saw Berthold comment on it, but
> as I mentioned, I've been busy..
> 
> Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

Sorry, where and what do i change?

Vincent.


Le mardi 14 novembre 2017 à 13:13 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 1:08 PM, vavincavent <vavincav...@gmail.com>
> wrote:
> > Linus,
> > 
> > i change back
> > if (1) {
> > to
> > if (io->packet_size <64) {
> > 
> > here is the usb.pcap
> 
> Ok, good, everything looks as expected and matches my G2 behavior.
> Except for the lack of reply.
> 
> Try making the buffer size be "TX_PACKET_SIZE + 1" instead of
> TX_PACKET_SIZE. Maybe it really is that URB data length of 31 vs 32
> that matters.
> 
> The G2 clearly doesn't care, but maybe the Aladin Square _really_
> wants just 32-byte packets to even recognize them.
> 
>  Linus.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

Jef, the result with windows and your files.

Vincent

Le mardi 14 novembre 2017 à 21:28 +0100, Jef Driesen a écrit :
> On 14-11-17 21:15, Jef Driesen wrote:
> > On 14-11-17 21:04, Linus Torvalds wrote:
> > > On Tue, Nov 14, 2017 at 11:57 AM, Jef Driesen  > > r.org> wrote:
> > > > 
> > > > I suspect this is not caused by a difference in the libusb
> > > > version, but a
> > > > difference in the subsurface branch of libdivecomputer. If you
> > > > look at the
> > > > g2.log of the successful download on Windows, then you can
> > > > clearly see
> > > > libdivecomputer is sending out 33 byte packets (1 byte report
> > > > id and 32
> > > > bytes payload).
> > > 
> > > .. but that's _exactly_ the usb library difference. On Windows,
> > > it's
> > > using hidapi instead. Just a library difference.
> > 
> > Ah ok, you are referring to libusb vs hidapi. I thought you were
> > talking about a
> > difference in the libusb version.
> > 
> > Give me a couple of minutes to build a libusb based windows
> > version.
> 
> It's available here:
> 
> http://libdivecomputer.org/builds/experimental/windows/libdivecompute
> r-0.dll.libusb
> 
> (remove the .libusb suffix after downloading)
> 
> You'll need the following files as well:
> 
> http://libdivecomputer.org/builds/experimental/windows/g2.cmd
> http://libdivecomputer.org/builds/divinglog/dctool.exe
> http://libdivecomputer.org/builds/divinglog/libusb-1.0.dll
> 
> @Vincent: Can you give this build a try?
> 
> Jef[0.19] DATETIME 2017-11-14T20:42:27Z (1510692147)
[0.000201] VERSION 0.6.0-devel (5bf260ce7be4acb769e6e318dc3c2a8ca2a7f5ca)
[0.000326] Opening the device (Scubapro Aladin Sport Matrix, null).
[0.000431] INFO: Open: vid=c251, pid=2006
[0.039911] INFO: Open: interface=0, endpoints=81,02
[0.127004] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.127383] INFO: Write: size=33, data=00011B
[0.326018] INFO: Read: size=64, data=0101
[0.326933] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.327210] INFO: Write: size=33, data=00051C1027
[0.422014] INFO: Read: size=64, data=0101
[0.422368] Registering the event handler.
[0.422520] Registering the cancellation handler.
[0.422670] Downloading the memory dump.
[0.422816] Event: progress 0.00% (0/4294967295)
[0.431010] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.432424] INFO: Write: size=33, data=000110
[0.454015] INFO: Read: size=64, data=0122
[0.462926] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.463249] INFO: Write: size=33, data=000114
[0.517942] INFO: Read: size=64, data=04A6E31C0400
[0.518912] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.519182] INFO: Write: size=33, data=00011A
[0.541953] INFO: Read: size=64, data=04CE243C4300
[0.542846] Event: progress 0.00% (9/4294967295)
[0.543559] Event: systime=1510692148, devtime=1128015054
[0.544394] Event: model=34 (0x0022), firmware=0 (0x), serial=69002150 (0x041ce3a6)
[0.550925] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.551216] INFO: Write: size=33, data=0009C61027
[0.853943] INFO: Read: size=64, data=046C5900
[0.854241] Event: progress 0.06% (13/22909)
[0.862922] WARNING: Number of bytes exceeds the buffer size (34 > 33)! [in usbhid.c:521 (dc_usbhid_write)]
[0.863196] INFO: Write: size=33, data=0009C41027
[1.213972] INFO: Read: size=64, data=04705900
[1.214259] Event: progress 0.07% (17/22909)
[1.317980] INFO: Read: size=64, 

Re: Scubapro Aladin Square

[vavincavent]

new usb.pcap file following 

 if (length < 31)
  length = 31;

Vincent

Le mardi 14 novembre 2017 à 11:29 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 11:17 AM, Linus Torvalds
> <torva...@linux-foundation.org> wrote:
> > On Tue, Nov 14, 2017 at 10:52 AM, vavincavent <vavincav...@gmail.co
> > m> wrote:
> > > and ... i join usb.pcap file!
> > 
> > Ok, that's a good dump. I see
> > 
> >  - device 1: root hub (1d6b:0002)
> >  - device 2: logitech LX710 (046d:c517)
> >  - device 3: RealTek RTS5129 card reader (0bda:0129)
> >  - device 4: Realtek something (0bda:57de) Wifi?
> >  - device 59: Lite-On bluetooth donge (04ca:3018)
> >  - device 60: c251:2006
> > 
> > I assume that matches what you'd expect on that bus?
> > 
> > So it's that device 60.
> > 
> > And the only traffic I see there is (apart from the two empty
> > reads)
> > is that one URB_INTERRUPT write packet with data 0110.
> > 
> > Very odd.
> > 
> > Also, for some reason wireshark is not showing it as a USB HID
> > protocol thing. That's odd. I was pretty sure wireshark should do
> > that.
> 
> Oh, it only does that for the setup packets that aren't there.
> 
> And I do notice a big difference to what I get when I do a similar
> dump.
> 
> Your dump shows:
> 
>   Frame 1573: 66 bytes on wire (528 bits), 66 bytes captured (528
> bits) on interface 0
>   USB URB
>   [Source: host]
>   [Destination: 1.60.2]
>   URB id: 0x97a01200de40
>   URB type: URB_SUBMIT ('S')
>   URB transfer type: URB_INTERRUPT (0x01)
>   Endpoint: 0x02, Direction: OUT
>   Device: 60
>   URB bus id: 1
>   Device setup request: not relevant ('-')
>   Data: present (0)
>   URB sec: 1510685037
>   URB usec: 39850
>   URB status: Operation now in progress (-EINPROGRESS) (-115)
>   URB length [bytes]: 2
>   Data length [bytes]: 2
>   [Response in: 1574]
>   [bInterfaceClass: Unknown (0x)]
>   Unused Setup Header
>   Interval: 8
>   Start frame: 0
>   Copy of Transfer Flags: 0x
>   Number of ISO descriptors: 0
>   Leftover Capture Data: 0110
> 
> for that 0110 command packet.
> 
> When I do it, I get:
> 
>   Frame 579: 95 bytes on wire (760 bits), 95 bytes captured (760
> bits)
> on interface 0
>   USB URB
>   [Source: host]
>   [Destination: 3.6.1]
>   URB id: 0x914c372596c0
>   URB type: URB_SUBMIT ('S')
>   URB transfer type: URB_INTERRUPT (0x01)
>   Endpoint: 0x01, Direction: OUT
>   Device: 6
>   URB bus id: 3
>   Device setup request: not relevant ('-')
>   Data: present (0)
>   URB sec: 1510686848
>   URB usec: 546665
>   URB status: Operation now in progress (-EINPROGRESS) (-115)
>   URB length [bytes]: 31
>   Data length [bytes]: 31
>   [Response in: 580]
>   [bInterfaceClass: HID (0x03)]
>   Unused Setup Header
>   Interval: 4
>   Start frame: 0
>   Copy of Transfer Flags: 0x
>   Number of ISO descriptors: 0
>   Leftover Capture Data:
> 011b...
> 
> Notice the different in Data length and padding.
> 
> So I think what's going on here is that different versions of libusb
> end up padding things differently, and your dive computer doesn't
> like
> the short packets that your version of libusb creates.
> 
> I dunno. Maybe it's some other thing that results in this difference.
> 
> Anyway, let's just hack around it and test, See that
> "libusb_interrupt_transfer()" call in the function dc_usbhid_write()
> in src/usbhit.c?
> 
> Add something like
> 
>  if (length < 31)
>   length = 31;
> 
> to just before it. It will send garbage padding, but the dive
> computer
> sends _us_ garbage padding, so that's probably ok.
> 
> It's a horrible hack, but it's just for testing.
> 
> Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

vincent@ASUS-R558UV:~/src/subsurface/build$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 04ca:3018 Lite-On Technology Corp. 
Bus 001 Device 004: ID 0bda:57de Realtek Semiconductor Corp. 
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129
Card Reader Controller
Bus 001 Device 002: ID 046d:c517 Logitech, Inc. LX710 Cordless Desktop
Laser
Bus 001 Device 054: ID c251:2006 Keil Software, Inc. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So, Bus 1...

I plug the square, put in download mode...

vincent@ASUS-R558UV:~/src/subsurface/build$ sudo tshark -i usbmon1 -s
256 -w usb.pcap
Running as user "root" and group "root". This could be dangerous.
Capturing on 'usbmon1'
tshark: The file to which the capture would be saved ("usb.pcap") could
not be opened: Permission denied.

vincent@ASUS-R558UV:~/src/subsurface/build$ 

tshark don't stay open...

Vincent



Le lundi 13 novembre 2017 à 13:36 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 1:28 PM, vavincavent <vavincav...@gmail.com>
> wrote:
> > vincent@ASUS-R558UV:~/src/subsurface/build$ sudo tshark -D
> > Running as user "root" and group "root". This could be dangerous.
> > 1. enp2s0
> > 2. wlp3s0
> > 3. any
> > 4. lo (Loopback)
> > 5. bluetooth0
> > 6. usbmon0
> > 7. nflog
> > 8. nfqueue
> > 9. usbmon1
> > 10. usbmon2
> > 11. cisco (Cisco remote capture)
> > 12. randpkt (Random packet generator)
> > 13. ssh (SSH remote capture)
> 
> Ok, so what does lsusb say when the device is connected? For my
> scubapro, it looks like this:
> 
>   Bus 003 Device 005: ID 2e6c:3201
> 
> so it's on bus 3.
> 
> Depending on the bus, pick the right "usbmonX" device, and then:
> 
>  - plug the device in, and put it in download mode
> 
>  - do "sudo tshark -i usbmonX -s 256 -w usb.pcap" in one terminal
> 
>  - and finally, start subsurface and try to download
> 
> after the download failed, just kill tshark, and send me the pcap
> file.
> 
> (You can look at it with 'wireshark' of course)
> 
>   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

vincent@ASUS-R558UV:~/src/subsurface/build$ sudo tshark -D
Running as user "root" and group "root". This could be dangerous.
1. enp2s0
2. wlp3s0
3. any
4. lo (Loopback)
5. bluetooth0
6. usbmon0
7. nflog
8. nfqueue
9. usbmon1
10. usbmon2
11. cisco (Cisco remote capture)
12. randpkt (Random packet generator)
13. ssh (SSH remote capture)

Vincent


Le lundi 13 novembre 2017 à 13:00 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 12:10 PM, vavincavent <vavincav...@gmail.com>
> wrote:
> > I'm so sorry, nothing append..
> > 
> > i've made : tshark -i any -w out.pcap
> > but nothing seems to be from usb.
> > 
> > what is the problem??
> 
> What does
> 
> sudo tshark -D
> 
> print?
> 
> It should say something like
> 
>   1. enp5s0
>   2. any
>   3. lo (Loopback)
>   4. virbr0
>   5. bluetooth0
>   6. bluetooth-monitor
>   7. usbmon0
>   8. nflog
>   9. nfqueue
>   10. usbmon1
>   11. usbmon2
>   12. usbmon3
>   13. usbmon4
> 
> and if those usbmon entries don't show up, do
> 
> sudo modprobe usbmon
> 
> to make sure the usbmon module is loaded.
> 
>  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

I'm so sorry, nothing append..

i've made : tshark -i any -w out.pcap
but nothing seems to be from usb.

what is the problem??

Vincent

Le lundi 13 novembre 2017 à 11:38 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 11:33 AM, vavincavent <vavincav...@gmail.com>
> wrote:
> > tshark problem :
> > 
> > vincent@ASUS-R558UV:~/src/subsurface/build$ tshark -i /dev/ttyUSB0
> > -w
> > out.pcap
> 
> It's not /dev/ttyUSB0.
> 
> It's "usbmonX" (where X is the USB bus number that the device is on).
> 
> You do need to have the "usbmon" kernel module inserted - I think it
> should happen automatically, but you may have to do a "modprobe
> usbmon" if debian requires manual intervention.
> 
>    Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

tshark problem :

vincent@ASUS-R558UV:~/src/subsurface/build$ tshark -i /dev/ttyUSB0 -w
out.pcap
Capturing on '/dev/ttyUSB0'
tshark: The capture session could not be initiated on interface
'/dev/ttyUSB0' (No such device exists).
Please check to make sure you have sufficient permissions, and that you
have the proper interface or pipe specified.

Vincent


Le lundi 13 novembre 2017 à 11:18 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 10:47 AM, vavincavent <vavincav...@gmail.com>
> wrote:
> > A little better?? (/etc/udev/rules.d):
> 
> So now you can actually do the IO:
> 
> > The log file :
> > Subsurface: v4.7.4-1-g4d04f74312dc, built with libdivecomputer
> > v0.6.0-
> > devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
> > INFO: Open: vid=c251, pid=2006
> > INFO: Open: interface=0, endpoints=81,02
> > INFO: Timeout: value=10
> > ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT).
> > [in ../../src/usbhid.c:518 (dc_usbhid_read)]
> > INFO: Read: size=0, data=
> 
> This first one is normal - it comes from the open trying to flush any
> possible previous data, and it normally fails (note the short timeout
> too).
> 
> > INFO: Timeout: value=5000
> > DEBUG: cmd: size=1, data=10
> > INFO: Write: size=2, data=0110
> 
> Here we wrote the one-byte command.
> 
> And then:
> 
> > ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT).
> > [in ../../src/usbhid.c:518 (dc_usbhid_read)]
> > INFO: Read: size=0, data=
> > ERROR: read interrupt transfer failed [in
> > ../../src/scubapro_g2.c:78 (receive_data)]
> > ERROR: Failed to receive the answer. [in
> > ../../src/scubapro_g2.c:145 (scubapro_g2_transfer)]
> 
> But the aboive is where we fail to get the expected reply.
> 
> I think I'd really like to see the actual packet trace from this
> failure.
> 
>   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

A little better?? (/etc/udev/rules.d):

The log file :
Subsurface: v4.7.4-1-g4d04f74312dc, built with libdivecomputer v0.6.0-
devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
INFO: Open: vid=c251, pid=2006
INFO: Open: interface=0, endpoints=81,02
INFO: Timeout: value=10
ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT). [in
../../src/usbhid.c:518 (dc_usbhid_read)]
INFO: Read: size=0, data=
INFO: Timeout: value=5000
DEBUG: cmd: size=1, data=10
INFO: Write: size=2, data=0110
ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT). [in
../../src/usbhid.c:518 (dc_usbhid_read)]
INFO: Read: size=0, data=
ERROR: read interrupt transfer failed [in ../../src/scubapro_g2.c:78
(receive_data)]
ERROR: Failed to receive the answer. [in ../../src/scubapro_g2.c:145
(scubapro_g2_transfer)]

Vincent

Le lundi 13 novembre 2017 à 10:28 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 9:51 AM, vavincavent <vavincav...@gmail.com>
> wrote:
> > I have used scubapro_g2.c joined and this is the log :
> 
> This is the same udev rule problem:
> 
> > Subsurface: v4.7.4-1-g4d04f74312dc, built with libdivecomputer
> > v0.6.0-
> > devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
> > INFO: Open: vid=c251, pid=2006
> > INFO: Open: interface=0, endpoints=81,02
> > ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
> > ../../src/usbhid.c:392 (dc_usbhid_open)]
> 
> You simply don't have permissions to access that device.
> 
> So I have this for my G2 to make it world readable and writable:
> 
>   [torvalds@i7 ~]$ cat /usr/lib/udev/rules.d/91-scubapro-g2.rules
> 
>   SUBSYSTEM=="usb",ATTR{idVendor}=="2e6c",ATTR{idProduct}=="3201",
> MODE="0666"
> 
> (NOTE! That udev rule is _one_ line, maybe this email breaks it up).
> 
> You'll obviously have to update the ID to match the Aladin Square,
> and
> you may have to make sure udev rules are reloaded and then plug in
> the
> device again.
> 
>    udevadm control --reload-rules
> 
> Also, I'm not sure where Debian stretch puts the udev rules. I'm
> running Fedora 26, so that /ust/lib/udev/rules.d/ directory is what I
> use. But I think Debian may be using /lib/udev/rules.d, so you need
> to
> check that.
> 
> Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

I have used scubapro_g2.c joined and this is the log :

Subsurface: v4.7.4-1-g4d04f74312dc, built with libdivecomputer v0.6.0-
devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
INFO: Open: vid=c251, pid=2006
INFO: Open: interface=0, endpoints=81,02
ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
../../src/usbhid.c:392 (dc_usbhid_open)]
ERROR: Failed to open Scubapro G2 device [in
../../src/scubapro_g2.c:224 (scubapro_g2_device_open)]

Vincent

Le lundi 13 novembre 2017 à 09:34 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 9:29 AM, vavincavent <vavincav...@gmail.com>
> wrote:
> > I have little problem with tshark or wireshark. But I try to test
> > this
> > !
> > The result with windows give me hope for the same with DEBIAN!
> 
> Well, you can also just test out the "maybe it's the extra zero byte
> for hidusb" directly, without capturing any packet trace.
> 
> In scubapro_g2_transfer(), see how it does that:
> 
> // BLE GATT protocol?
> if (io->packet_size < 64) {
> // No report type byte
> status = io->packet_write(io, buf+1, csize+1,
> );
> } else {
> status = io->packet_write(io, buf, sizeof(buf),
> );
> }
> 
> and the difference is exactly that the BLE GATT stuff does _not_ want
> that silly report type byte.
> 
> libusb doesn't really either - it was added just for hidapi.
> 
> So try just changing that
> 
> if (io->packet_size < 64) {
> 
> to a
> 
> if (1) {
> 
> and see if your Debian case magically works.
> 
> (Of course, this is in _addition_ to all the USB ID hackery to make
> it
> use the right device ID)
> 
> Linus/*
 * libdivecomputer
 *
 * Copyright (C) 2008 Jef Driesen
 *   (C) 2017 Linus Torvalds
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
 * MA 02110-1301 USA
 */

#include  // malloc, free
#include 	// strncmp, strstr

#include "scubapro_g2.h"
#include "context-private.h"
#include "device-private.h"
#include "usbhid.h"
#include "array.h"
#include "platform.h"

#define ISINSTANCE(device) dc_device_isinstance((device), _g2_device_vtable)

#define RX_PACKET_SIZE 64
#define TX_PACKET_SIZE 32

#define ALADINSPORTMATRIX 0x17

typedef struct scubapro_g2_device_t {
	dc_device_t base;
	unsigned int timestamp;
	unsigned int devtime;
	dc_ticks_t systime;
} scubapro_g2_device_t;

static dc_status_t scubapro_g2_device_set_fingerprint (dc_device_t *device, const unsigned char data[], unsigned int size);
static dc_status_t scubapro_g2_device_dump (dc_device_t *abstract, dc_buffer_t *buffer);
static dc_status_t scubapro_g2_device_foreach (dc_device_t *abstract, dc_dive_callback_t callback, void *userdata);
static dc_status_t scubapro_g2_device_close (dc_device_t *abstract);

static const dc_device_vtable_t scubapro_g2_device_vtable = {
	sizeof(scubapro_g2_device_t),
	DC_FAMILY_UWATEC_G2,
	scubapro_g2_device_set_fingerprint, /* set_fingerprint */
	NULL, /* read */
	NULL, /* write */
	scubapro_g2_device_dump, /* dump */
	scubapro_g2_device_foreach, /* foreach */
	NULL, /* timesync */
	scubapro_g2_device_close /* close */
};

static dc_status_t
scubapro_g2_extract_dives (dc_device_t *device, const unsigned char data[], unsigned int size, dc_dive_callback_t callback, void *userdata);

static int receive_data(scubapro_g2_device_t *g2, unsigned char *buffer, int size, dc_event_progress_t *progress)
{
	dc_custom_io_t *io = _dc_context_custom_io(g2->base.context);
	while (size) {
		unsigned char buf[RX_PACKET_SIZE] = { 0 };
		size_t transferred = 0;
		dc_status_t rc;
		int len;

		rc = io->packet_read(io, buf, sizeof(buf), );
		if (rc != DC_STATUS_SUCCESS) {
			ERROR(g2->base.context, "read interrupt transfer failed");
			return -1;
		}
		if (transferred < 1) {
			ERROR(g2->base.context, "incomplete read interrupt transfer (got empty packet)");
			return -1;
		}
		len = buf[0];
		if (transferred < len + 1) {
			ERROR(g2->base.context, "small packet read (got %zu, expected at least %d)", transferred, 

Re: Scubapro Aladin Square

[vavincavent]

I have little problem with tshark or wireshark. But I try to test this
!
The result with windows give me hope for the same with DEBIAN!

Vincent.


Le lundi 13 novembre 2017 à 09:17 -0800, Linus Torvalds a écrit :
> On Mon, Nov 13, 2017 at 9:11 AM, vavincavent <vavincav...@gmail.com>
> wrote:
> > 
> > With your method, download works.
> > You'll find attached files g2.bin and g2.log.
> 
> So this was on Windows using usbhid?
> 
> I really am starting to believe that it's the extra zero with libusb,
> and your Debian machine actually considers that an _extra_ zero.
> 
> So I'd like to see the USB capture on your Debian machine of the
> failing case.
> 
> Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

Can we begin to make a new entry for this computer in libdivecomputer
library? (scubapro_square.c and scubapro_square.h but i think it's not
just this...)

I can't program this, but i can do the test with my divecomputer and
Debian. I have android smartphone too with OTG.

Actually i use divemate for downloading my data and after export to
subsurface. It's not the best way for my mind!

Regards,
Vincent

Le vendredi 10 novembre 2017 à 18:53 -0800, Linus Torvalds a écrit :
> On Fri, Nov 10, 2017 at 4:33 PM, vavincavent <vavincav...@gmail.com>
> wrote:
> > Linus, Jef,
> > 
> > I've made dump file report with USBlyser.
> > I've attach the file in this message.
> 
> From a quick look, i tdoes look like the standard Uwatec thing
> (without a handshake):
> 
> LogTrak sends: 01 10 to query the model.
> 
> Dive computer responds:
> 
>   01 22 7F 7F BF C1 C4 B1 C1 FB 0E 03 00 00 00
> 00  ."..
> 0010  FE FE FE 01 00 00 00 00 C1 7D 7E 7C 04 7F 7C
> BF  .}~|..|.
> 0020  C1 BF C1 12 7E 7F B1 0F 62 C1 03 B1 7E 0B 75
> 04  ~...b...~.u.
> 0030  7D BF 7E B1 09 7D 7D BF 7D B1 C1 7E 01 01 BF
> 02  }.~..}}.}..~
> 
> where only that "01 22" is actually valid (the rest is just garbage
> from the dive computer memory - it seems to be quite common that the
> USB HID stack uses a static buffer and sends garbage padding).
> 
> So the model is 0x22.
> 
> Then LogTrak does that 0x1b thing (that we use as a handshake, but it
> clearly means something): 01 1B
> 
> And the dive computer responds with
> 
>   01 01 7F 7F BF C1 C4 B1 C1 FB 0E 03 00 00 00
> 00  
> 0010  FE FE FE 01 00 00 00 00 C1 7D 7E 7C 04 7F 7C
> BF  .}~|..|.
> 0020  C1 BF C1 12 7E 7F B1 0F 62 C1 03 B1 7E 0B 75
> 04  ~...b...~.u.
> 0030  7D BF 7E B1 09 7D 7D BF 7D B1 C1 7E 01 01 BF
> 02  }.~..}}.}..~
> 
> which is just "01 01" and the same garbage padding.
> 
> Then it does that "05 1C 10 27 00 00" thing that we do as part of the
> handshake, and we get 01 01 back (with garbage padding).
> 
> And then LogTrak asks for devtime, and gets "04 D6 FD 31 43" (and
> garbage padding) back.
> 
> So everything looks very much like the G2 should work.
> 
> So I don't know why it subsurface gets that
> 
>   ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT).
> [in ../../src/usbhid.c:518 (dc_usbhid_read)]
> 
> error.  Maybe the Aladin Square has a fairly stupid firmware, and
> really needs the commands to be in one particular order, and wants
> that "model query" first.
> 
> Does anybody else see anything odd?
> 
> Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

After udev rules with Jef recommandation, the subsurface.log :

Subsurface: v4.7.2-54-g97712559192c, built with libdivecomputer v0.6.0-
devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
INFO: Open: vid=c251, pid=2006
INFO: Open: interface=0, endpoints=81,02
INFO: Timeout: value=10
ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT). [in
../../src/usbhid.c:518 (dc_usbhid_read)]
INFO: Read: size=0, data=
INFO: Timeout: value=5000
DEBUG: cmd: size=1, data=1B
INFO: Write: size=32,
data=00011B00
ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT). [in
../../src/usbhid.c:518 (dc_usbhid_read)]
INFO: Read: size=0, data=
ERROR: read interrupt transfer failed [in scubapro_g2.c:78
(receive_data)]
ERROR: Failed to receive the answer. [in scubapro_g2.c:145
(scubapro_g2_transfer)]
ERROR: Failed to handshake with the device. [in scubapro_g2.c:231
(scubapro_g2_device_open)]

When i try with Logtrak, i've try to sniff USB. So i have some results,
but i can't understand this...

Please, help me ... 

Vincent

Le vendredi 10 novembre 2017 à 09:58 -0800, Linus Torvalds a écrit :
> On Thu, Nov 9, 2017 at 2:39 PM, vavincavent <vavincav...@gmail.com>
> wrote:
> > 
> > ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
> > ../../src/usbhid.c:392 (dc_usbhid_open)]
> 
> As Jef says, this is a USB permission issue. The regular udev rules
> do
> not grant normal users access to random USB devices that it doesn't
> know about, which is good for security, but it's inconvenient for
> dive
> computers.
> 
>   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

It was the libdivecomputer log file, from subsurface :

Subsurface: v4.7.2-54-g97712559192c, built with libdivecomputer v0.6.0-
devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
INFO: Open: vid=c251, pid=2006
INFO: Open: interface=0, endpoints=81,02
ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
../../src/usbhid.c:392 (dc_usbhid_open)]
ERROR: Failed to open Scubapro G2 device [in scubapro_g2.c:224
(scubapro_g2_device_open)]

vid=c251, pid=2006 is the informations of the square after i've made
changes like Linus tell me.

Vincent


Le vendredi 10 novembre 2017 à 06:52 +0200, Miika Turkia a écrit :
> Can you enable libdivecomputer log file on download dialog when you
> re-try download. This log should produce a lot more information about
> the download process and might tell us what is going wrong. And if
> the
> communication with divecomputer works some way, then also
> libdivecomputer dumpfile might be of use to us.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

Linus,

i think i have successs in compiling with new pid (not easy for me
...), but no success for connecting aladin square :

subsurface.log :

Subsurface: v4.7.2-54-g97712559192c, built with libdivecomputer v0.6.0-
devel-Subsurface-branch (7de3a549ee588fef4702ee9d894e390aca43950d)
INFO: Open: vid=c251, pid=2006
INFO: Open: interface=0, endpoints=81,02
ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
../../src/usbhid.c:392 (dc_usbhid_open)]
ERROR: Failed to open Scubapro G2 device [in scubapro_g2.c:224
(scubapro_g2_device_open)]

Vincent


Le mercredi 08 novembre 2017 à 13:16 -0800, Linus Torvalds a écrit :
> On Wed, Nov 8, 2017 at 1:02 PM, vavincavent <vavincav...@gmail.com>
> wrote:
> > 
> > : USB HID v1.00 Device [Uwatec AG Square] on usb-:00:14.0-
> > 1/input0
> 
> Ok, so this is one of the "native USB" devices, not one of the
> "serial
> device, using a USB-to-serial cable" devices.
> 
> That means that you need to use the actual native USB access.
> 
> We don't have any way to set the USB device ID's, but it is
> *possible*
> that it works the same way the Scubapro G2 does (which also shows up
> as a USB HID device).
> 
> If you can build your own subsurface, you could try this:
> 
> -   status = dc_usbhid_custom_io(context, 0x2e6c,
> 0x3201);
> +   status = dc_usbhid_custom_io(context, 0xc251,
> 0x2006);
> 
> in libdifvecomputer's src/scubapro_g2.c and then say "download from
> Scubapro G2".
> 
> It would be good to have some way to let people test USB ID's like
> this without having to build things specifically for it, but I can't
> think of a sane way.
> 
>    Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Aladin Square

[vavincavent]

I'mwith debian stretch.

With dmesg :

[51221.241299] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[51221.245073] ata1.00: configured for UDMA/100
[51221.580422] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[51221.595293] r8169 :02:00.0 enp2s0: link down
[51221.595334] r8169 :02:00.0 enp2s0: link down
[51221.595424] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[51221.598295] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[51221.614434] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[51221.634939] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[51221.709568] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[51222.728450] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[51222.774768] wlp3s0: authenticate with 30:7e:cb:e5:ea:2c
[51222.786691] wlp3s0: send auth to 30:7e:cb:e5:ea:2c (try 1/3)
[51222.788699] wlp3s0: authenticated
[51222.789135] wlp3s0: associate with 30:7e:cb:e5:ea:2c (try 1/3)
[51222.792878] wlp3s0: RX AssocResp from 30:7e:cb:e5:ea:2c (capab=0x411
status=0 aid=5)
[51222.792975] wlp3s0: associated
[51222.793020] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes
ready
[51223.177978] r8169 :02:00.0 enp2s0: link up
[51223.177985] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes
ready
[51226.238052] usb 1-8: New USB device found, idVendor=04ca,
idProduct=3018
[51226.238054] usb 1-8: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[51228.710451] wlp3s0: authenticate with 30:7e:cb:e5:ea:2c
[51228.723752] wlp3s0: send auth to 30:7e:cb:e5:ea:2c (try 1/3)
[51228.729079] wlp3s0: authenticated
[51228.733108] wlp3s0: associate with 30:7e:cb:e5:ea:2c (try 1/3)
[51228.737851] wlp3s0: RX AssocResp from 30:7e:cb:e5:ea:2c (capab=0x411
status=0 aid=5)
[51228.737955] wlp3s0: associated
[69166.461691] usb 1-1: new full-speed USB device number 10 using
xhci_hcd
[69166.603936] usb 1-1: New USB device found, idVendor=c251,
idProduct=2006
[69166.603938] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[69166.603939] usb 1-1: Product: Square
[69166.603941] usb 1-1: Manufacturer: Uwatec AG
[69166.603942] usb 1-1: SerialNumber: r120A
[69176.778073] hid-generic 0003:C251:2006.0004: usb_submit_urb(ctrl)
failed: -1
[69176.778109] hid-generic 0003:C251:2006.0004: timeout initializing
reports
[69176.778850] hid-generic 0003:C251:2006.0004: hiddev0,hidraw3: USB
HID v1.00 Device [Uwatec AG Square] on usb-:00:14.0-1/input0
[69263.297351] usb 1-1: USB disconnect, device number 10
[69307.726333] usb 1-1: new full-speed USB device number 11 using
xhci_hcd
[69307.870369] usb 1-1: New USB device found, idVendor=c251,
idProduct=2006
[69307.870379] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[69307.870385] usb 1-1: Product: Square
[69307.870390] usb 1-1: Manufacturer: Uwatec AG
[69307.870394] usb 1-1: SerialNumber: r120A

And i can't connect with USB like Aladin pro for example.

Vincent.

Le mercredi 08 novembre 2017 à 21:38 +0200, Willem Ferguson a écrit :
> On 08/11/2017 20:29, vavincavent wrote:
> > hi,
> > 
> > I dive with the scubapro Aladin square dive computer.
> > Unfortunatly not supported for download by subsurface.
> > Is it planned? How can i help?
> > 
> > Vincent.
> > ___
> > subsurface mailing list
> > subsurface@subsurface-divelog.org
> > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsur
> > face
> 
> I see the Square has a USB interface, just like the Aladin Sport.
> What 
> happens if you specify any of the Uwatec or Scubapro dive computers
> that 
> also use USB?
> 
> Kind regards,
> 
> willem
> 
> 
> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Scubapro Aladin Square

[vavincavent]

hi,

I dive with the scubapro Aladin square dive computer.
Unfortunatly not supported for download by subsurface.
Is it planned? How can i help?

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