On Thu, Nov 16, 2017 at 3:05 PM, Linus Torvalds
wrote:
>
> Very good. I will try to come up with a better model for the whole USB
> ID selection (because I suspect we'll have a few more models show up
> eventually), but that should be trivial. I'll probably just make it an
> array of "model, vendo
On Thu, Nov 16, 2017 at 2:44 PM, vavincavent wrote:
>
> In my local files it's ok for downloading and analysing of the dives!
>
> You'll find attached the files i've change.
Very good. I will try to come up with a better model for the whole USB
ID selection (because I suspect we'll have a few mor
On Wed, Nov 15, 2017 at 10:20 PM, vavincavent wrote:
>
> 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?
The only one that works with subs
On Thu, Nov 16, 2017 at 07:20:40AM +0100, vavincavent wrote:
>
> 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?
libdivecomputer at http:/
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-1
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 > > wrote:
> > >
> > > Now i think it's the
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
> wrote:
> >
> > Now i think it's the analysis of the datas???
>
> Oh, I thought it already worked?
>
> When you ask s
rom: Jef Driesen
Date: Mon, 13 Nov 2017 09:30:41 +0100
Subject: [PATCH] Add support for the Scubapro Aladin Square
---
src/descriptor.c | 1 +
src/device.c | 2 +-
src/uwatec_g2.c | 14 --
src/uwatec_g2.h | 2 +-
src/uwatec_smart_parser.c | 8 +++
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
> wrote:
> >
>
On Tue, Nov 14, 2017 at 2:00 PM, vavincavent 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
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
> wrote:
> > YES!!
> > a step passed!
>
> Ok.
On Tue, Nov 14, 2017 at 1:44 PM, vavincavent 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 ou
On Tue, Nov 14, 2017 at 1:21 PM, vavincavent wrote:
> Sorry, where and what do i change?
This:
--- a/src/scubapro_g2.c
+++ b/src/scubapro_g2.c
@@ -113,7 +113,7 @@ static dc_status_t
scubapro_g2_transfer(scubapro_g2_device_t *g2, const unsigned char
command[], unsigned int csize, unsigne
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
> wrote:
> > Linus,
> >
> > i change back
> > if (1) {
> > to
> > if (io->packet_size <64) {
> >
> > here is the usb.pca
On Tue, Nov 14, 2017 at 1:08 PM, vavincavent 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_
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 suspec
On 14-11-17 21:33, Linus Torvalds wrote:
On Tue, Nov 14, 2017 at 12:15 PM, Jef Driesen wrote:
Ah that explains the difference. In upstream libdivecomputer the buffer is
one byte larger:
unsigned char buf[TX_PACKET_SIZE + 1];
And that may actually end up being relevant.
It makes no sense tha
On Tue, Nov 14, 2017 at 12:15 PM, Jef Driesen wrote:
>
> In of you previous emails, you asked Vincent to patch the
>
> if (io->packet_size < 64) {
>
> to a
>
> if (1) {
Oh, my bad.
That was actually an earlier "let's try to avoid the report byte", and
I'd forgotten entirely about
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 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 th
On 14-11-17 21:04, Linus Torvalds wrote:
On Tue, Nov 14, 2017 at 11:57 AM, Jef Driesen 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
On Tue, Nov 14, 2017 at 12:02 PM, vavincavent wrote:
> I do : vincent@ASUS-R558UV:~/src/subsurface/build$ sudo tshark -i
> usbmon1 -s 256 -w /tmp/usb.pcap
> Running as user "root" and group "root". This could be dangerous.
> Capturing on 'usbmon1'
> 3794 ^C
>
> then connecting the square
> then te
On Tue, Nov 14, 2017 at 11:57 AM, Jef Driesen 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
On 14-11-17 20:29, Linus Torvalds wrote:
On Tue, Nov 14, 2017 at 11:17 AM, Linus Torvalds
wrote:
On Tue, Nov 14, 2017 at 10:52 AM, vavincavent 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)
-
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
> wrote:
> > On Tue, Nov 14, 2017 at 10:52 AM, vavincavent > m> wrote:
> > > and ... i join usb
On Tue, Nov 14, 2017 at 11:29 AM, Linus Torvalds
wrote:
>
> Oh, it only does that for the setup packets that aren't there.
Btw, can I get a log with the whole "plug device in" sequence too, so
that I can see that part. I didn't think I'd want it, but it turns out
that I do. Your endpoint numberin
vincent@ASUS-R558UV:~/src/subsurface/build$ ldd subsurface | grep -i
usb
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0
(0x7fcc8d8e2000)
Vincent
Le mardi 14 novembre 2017 à 11:17 -0800, Linus Torvalds a écrit :
> On Tue, Nov 14, 2017 at 10:52 AM, vavincavent
> wrote:
> > a
On Tue, Nov 14, 2017 at 11:17 AM, Linus Torvalds
wrote:
> On Tue, Nov 14, 2017 at 10:52 AM, vavincavent 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 rea
On Tue, Nov 14, 2017 at 10:52 AM, vavincavent 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?
- de
On 13 November, 2017 - Linus Torvalds wrote:
> On Mon, Nov 13, 2017 at 1:45 PM, vavincavent wrote:
> >
> > sudo tshark -i usbmon1 -s 256 -w usb.pcap
> > tshark: The file to which the capture would be saved ("usb.pcap") could
> > not be opened: Permission denied.
>
> WTF? You're running as root,
On Mon, Nov 13, 2017 at 1:45 PM, vavincavent wrote:
>
> sudo tshark -i usbmon1 -s 256 -w usb.pcap
> tshark: The file to which the capture would be saved ("usb.pcap") could
> not be opened: Permission denied.
WTF? You're running as root, and it can't create that file due to
permission issues?
I h
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. RTS5
On Mon, Nov 13, 2017 at 1:28 PM, vavincavent 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
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 ge
On Mon, Nov 13, 2017 at 12:10 PM, vavincavent 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
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
> wrote:
> > tshark problem :
> >
> > vincent@
On Mon, Nov 13, 2017 at 11:33 AM, vavincavent 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 modul
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 yo
On Mon, Nov 13, 2017 at 10:47 AM, vavincavent 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:
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
On Mon, Nov 13, 2017 at 9:51 AM, vavincavent 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: O
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 dev
On Mon, Nov 13, 2017 at 9:29 AM, vavincavent 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 capt
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
> wrote:
> >
> > With your method, d
On Mon, Nov 13, 2017 at 9:11 AM, vavincavent 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
Jef,
With your method, download works.
You'll find attached files g2.bin and g2.log.
I hope it will be usefull.
Vincent.
Le lundi 13 novembre 2017 à 08:43 +0100, Jef Driesen a écrit :
> On 12-11-17 19:09, Linus Torvalds wrote:
> > On Sun, Nov 12, 2017 at 5:16 AM, vavincavent > > wrote:
> > >
On 12-11-17 19:09, Linus Torvalds wrote:
On Sun, Nov 12, 2017 at 5:16 AM, vavincavent wrote:
I try with joined file scubapro_g2.c to download from scubapro square.
Hmm. Can I see what the packets on the wire are, just in case we have
some odd libusb issue or something? We added an initial ze
On Sun, Nov 12, 2017 at 5:16 AM, vavincavent wrote:
>
> I try with joined file scubapro_g2.c to download from scubapro square.
Hmm. Can I see what the packets on the wire are, just in case we have
some odd libusb issue or something? We added an initial zero byte for
the report type to make hidapi
Hi Vincent,
On Samstag, 11. November 2017 09:26:55 CET vavincavent wrote:
> 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...)
Actually it's much simpler. You'd add an entry to the descript
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 f
On Fri, Nov 10, 2017 at 4:33 PM, vavincavent 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 re
On Freitag, 10. November 2017 22:32:14 CET Linus Torvalds wrote:
> On Fri, Nov 10, 2017 at 1:21 PM, vavincavent wrote:
> > After udev rules with Jef recommandation, the subsurface.log :
> Ok, so it doesn't work like the G2.
>
> That 011B thing is the hanshake (01 = one byte command, 1b is the
> h
On Fri, Nov 10, 2017 at 1:21 PM, vavincavent wrote:
> After udev rules with Jef recommandation, the subsurface.log :
Ok, so it doesn't work like the G2.
That 011B thing is the hanshake (01 = one byte command, 1b is the
handshake byte) and you don't get any answer.
Now, the Aladin Sport Matrix d
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
On Thu, Nov 9, 2017 at 2:39 PM, vavincavent 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 does
On 2017-11-10 14:52, vavincavent wrote:
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, endpoi
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 de
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 b
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: vi
On Wed, Nov 8, 2017 at 1:02 PM, vavincavent 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
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.
> > _
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
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
62 matches
Mail list logo
