Re: [PATCH] Added support for parsing temperature in the dive, header
Hi all, I have 2 dive computers. * Aladin pro, with it, temperature is not supported yet by libdivecomputer (just one data in the header). * Aladin square, it's not supported by libdivecomputer yet. Before discuss about calculus, age of captain, etc... Is it not more important that libdivecomputer just transfer basics data and support the more divecomputer as possible? Vavincavent
On 05-09-14 22:57, vavincavent wrote:
I have 2 dive computers. * Aladin pro, with it, temperature is not supported yet by libdivecomputer (just one data in the header). * Aladin square, it's not supported by libdivecomputer yet.
Before discuss about calculus, age of captain, etc... Is it not more important that libdivecomputer just transfer basics data and support the more divecomputer as possible?
Yes and no. Adding support for new devices is very important too. But reverse engineering and implementing a new protocol, especially if it's using a completely new technology (USB HID) takes time. Keep in mind that I'm basically the only person doing most of the work, and my resources (e.g. time) are limited. So I have to prioritize things. (Just to give you a bit of context, there are already two other new backends waiting to be implemented, for which I have much more concrete information than the Square.) We have been talking about redesigning the libdivecomputer api for several years now, but it always got postponed because I have been prioritizing device support. But if I keep doing that, we'll never get there. So after the next release I'm planning and work on the new api, rather than new devices. This may not be the answer you were looking for, but I just can't do everything. So support for the Square is not going to happen very soon, unless someone else jumps on it. Jef
On September 6, 2014 10:05:36 AM Jef Driesen <jef@libdivecomputer.org> wrote:
Adding support for new devices is very important too. But reverse engineering and implementing a new protocol, especially if it's using a completely new technology (USB HID) takes time. Keep in mind that I'm basically the only person doing most of the work, and my resources (e.g. time) are limited. So I have to prioritize things. (Just to give you a bit of context, there are already two other new backends waiting to be implemented, for which I have much more concrete information than the Square.)
I think we really need to try to get more people to contribute... I'm sure we can find some people who will help if they can get access to the necessary data. I certainly will work on the two new dive computers i have ordered...
We have been talking about redesigning the libdivecomputer api for several years now, but it always got postponed because I have been prioritizing device support. But if I keep doing that, we'll never get there. So after the next release I'm planning and work on the new api, rather than new devices.
This may not be the answer you were looking for, but I just can't do everything. So support for the Square is not going to happen very soon, unless someone else jumps on it.
What's missing? What do we have? /D
On 06-09-14 20:03, Dirk Hohndel wrote:
On September 6, 2014 10:05:36 AM Jef Driesen <jef@libdivecomputer.org> wrote:
Adding support for new devices is very important too. But reverse engineering and implementing a new protocol, especially if it's using a completely new technology (USB HID) takes time. Keep in mind that I'm basically the only person doing most of the work, and my resources (e.g. time) are limited. So I have to prioritize things. (Just to give you a bit of context, there are already two other new backends waiting to be implemented, for which I have much more concrete information than the Square.)
I think we really need to try to get more people to contribute... I'm sure we can find some people who will help if they can get access to the necessary data.
Usually, people that request support for a new devices are not software developers. And those that are, either have a device that is already supported, or are not interested in working on a device they don't own. At least that's my impression from the past years.
I certainly will work on the two new dive computers i have ordered...
That's much appreciated!
We have been talking about redesigning the libdivecomputer api for several years now, but it always got postponed because I have been prioritizing device support. But if I keep doing that, we'll never get there. So after the next release I'm planning and work on the new api, rather than new devices.
This may not be the answer you were looking for, but I just can't do everything. So support for the Square is not going to happen very soon, unless someone else jumps on it.
What's missing? What do we have?
According to the usb device descriptors it's a USB HID device. That's basically everything I know. Once I discovered libusb doesn't seem to support USB HID very well, I didn't investigate much further due to a lack of time. I wouldn't be surprised if the high level communication protocol is still the same as the other Uwatec devices. For the Meridian Scubapro/Uwatec also switched only the low-level layer from IrDA to usb-serial, and kept everything else the same. But of course that's just an educated guess, and I could be complete wrong. Jef
On Tue, Sep 09, 2014 at 12:50:19PM +0200, Jef Driesen wrote:
I think we really need to try to get more people to contribute... I'm sure we can find some people who will help if they can get access to the necessary data.
Usually, people that request support for a new devices are not software developers. And those that are, either have a device that is already supported, or are not interested in working on a device they don't own. At least that's my impression from the past years.
So Subsurface has about half a dozen contributors who don't even dive. And there are several diver/programmers out there who have shown tremendous energy and patience to help with topics that don't affect themselves directly. I certainly am more than happy to dig into adding support for dive computers that I don't own. I believe I added to the Atomics Cobalt - which I don't own :-)
I certainly will work on the two new dive computers i have ordered...
That's much appreciated!
But it doesn't scale. Is there a public list of which dive computers are missing but we have data? And a quick "how to get started"?
What's missing? What do we have?
According to the usb device descriptors it's a USB HID device. That's basically everything I know. Once I discovered libusb doesn't seem to support USB HID very well, I didn't investigate much further due to a lack of time.
OK, I think there are a few more "real" USB devices coming in the near future. So let's figure out what it takes to support that family of devices. So this is the "what do we have" part. What's the "what's missing" part - i.e., where is the starting point to add support? Or is this entirely new to libdivecomputer and needs to be designed from scratch?
I wouldn't be surprised if the high level communication protocol is still the same as the other Uwatec devices. For the Meridian Scubapro/Uwatec also switched only the low-level layer from IrDA to usb-serial, and kept everything else the same. But of course that's just an educated guess, and I could be complete wrong.
So I assume you have contact to a few people who have such computers? /D
On 2014-09-09 21:24, Dirk Hohndel wrote:
On Tue, Sep 09, 2014 at 12:50:19PM +0200, Jef Driesen wrote:
I think we really need to try to get more people to contribute... I'm sure we can find some people who will help if they can get access to the necessary data.
Usually, people that request support for a new devices are not software developers. And those that are, either have a device that is already supported, or are not interested in working on a device they don't own. At least that's my impression from the past years.
So Subsurface has about half a dozen contributors who don't even dive. And there are several diver/programmers out there who have shown tremendous energy and patience to help with topics that don't affect themselves directly.
I could be wrong, but I think that one of the reasons is that libdivecomputer as a low-level library has much less visibility than the applications using it. It get for example plenty of support emails from end users who think I wrote divinglog, macdive or subsurface. They just don't know the difference, and you can't really blame them for that.
I certainly am more than happy to dig into adding support for dive computers that I don't own. I believe I added to the Atomics Cobalt - which I don't own :-)
I do get some occasional patches, but nobody has ever contributed a completely new backend from scratch. That obviously takes a lot more effort. Especially if you don't own a test device yourself, because then you also heavily depend on the availability of the test person. Timezone differences can be really annoying here. Fixing parsing bugs is a lot easier, because once you have the data, you can easily reproduce everything locally.
Is there a public list of which dive computers are missing but we have data?
At the moment, I have data for these two devices: * Divesystem Orca 2: I have some good capture files. Based on my initial investigation, the protocol appears to be a fairly standard request/response type of protocol. I suspect Divesystem uses the same protocol for their newer iDive range of dive computers too. * Citizen Hyperaqualand: I don't have a capture file yet, but there is some reverse engineered documentation [1], and an open source implementation [2] too. [1] http://sourceforge.net/p/aquapalm/feature-requests/_discuss/thread/a5ec1ccf/... [2] http://gdivelog.cvs.sourceforge.net/viewvc/gdivelog/gdivelog/plugins/hyperaq...
And a quick "how to get started"?
I don't have any documentation at all. I have couple of scripts to post-process the portmon capture files, to reduce them to the bare minimum (e.g. only the data packets) and remove all other distracting info. From there on, trying to figure out how the protocol works is mostly manual work. Experience from reverse engineering previous protocols certainly helps. Very often (but not always) the communication protocols have roughly the same structure (e.g. command, parameters, length, payload, checksum).
What's missing? What do we have?
According to the usb device descriptors it's a USB HID device. That's basically everything I know. Once I discovered libusb doesn't seem to support USB HID very well, I didn't investigate much further due to a lack of time.
OK, I think there are a few more "real" USB devices coming in the near future. So let's figure out what it takes to support that family of devices.
So this is the "what do we have" part. What's the "what's missing" part - i.e., where is the starting point to add support? Or is this entirely new to libdivecomputer and needs to be designed from scratch?
The cobalt is currently the only device which uses "real" usb communication. As you probably know, we're using libusb for that. But according to the libusb documentation [3], it's not suitable for HID. There is an open source hidapi library [4], but I don't have any experience with it. I also don't have much experience capturing usb communication in general (there wasn't really any need so far). USB is a lot more verbose and complex than serial communication. So yes, HID is pretty much starting from scratch. [3] http://www.libusb.org/wiki/APIs [4] http://www.signal11.us/oss/hidapi/
I wouldn't be surprised if the high level communication protocol is still the same as the other Uwatec devices. For the Meridian Scubapro/Uwatec also switched only the low-level layer from IrDA to usb-serial, and kept everything else the same. But of course that's just an educated guess, and I could be complete wrong.
So I assume you have contact to a few people who have such computers?
So far, Vincent is the only one who requested support for the Uwatec Square. Jef
On Sep 10, 2014, at 6:31 AM, Jef Driesen <jef@libdivecomputer.org> wrote:
On 2014-09-09 21:24, Dirk Hohndel wrote:
On Tue, Sep 09, 2014 at 12:50:19PM +0200, Jef Driesen wrote:
I think we really need to try to get more people to contribute... I'm sure we can find some people who will help if they can get access to the necessary data. Usually, people that request support for a new devices are not software developers. And those that are, either have a device that is already supported, or are not interested in working on a device they don't own. At least that's my impression from the past years. So Subsurface has about half a dozen contributors who don't even dive. And there are several diver/programmers out there who have shown tremendous energy and patience to help with topics that don't affect themselves directly.
I could be wrong, but I think that one of the reasons is that libdivecomputer as a low-level library has much less visibility than the applications using it. It get for example plenty of support emails from end users who think I wrote divinglog, macdive or subsurface. They just don't know the difference, and you can't really blame them for that.
You are a prolific author :-) And yes, I understand the difference. I just think that we could help get more people involved.
I certainly am more than happy to dig into adding support for dive computers that I don't own. I believe I added to the Atomics Cobalt - which I don't own :-)
I do get some occasional patches, but nobody has ever contributed a completely new backend from scratch. That obviously takes a lot more effort. Especially if you don't own a test device yourself, because then you also heavily depend on the availability of the test person. Timezone differences can be really annoying here.
Fixing parsing bugs is a lot easier, because once you have the data, you can easily reproduce everything locally.
True.
Is there a public list of which dive computers are missing but we have data?
At the moment, I have data for these two devices:
* Divesystem Orca 2: I have some good capture files. Based on my initial investigation, the protocol appears to be a fairly standard request/response type of protocol. I suspect Divesystem uses the same protocol for their newer iDive range of dive computers too.
* Citizen Hyperaqualand: I don't have a capture file yet, but there is some reverse engineered documentation [1], and an open source implementation [2] too.
[1] http://sourceforge.net/p/aquapalm/feature-requests/_discuss/thread/a5ec1ccf/... [2] http://gdivelog.cvs.sourceforge.net/viewvc/gdivelog/gdivelog/plugins/hyperaq...
And a quick "how to get started"?
I don't have any documentation at all. I have couple of scripts to post-process the portmon capture files, to reduce them to the bare minimum (e.g. only the data packets) and remove all other distracting info.
From there on, trying to figure out how the protocol works is mostly manual work. Experience from reverse engineering previous protocols certainly helps. Very often (but not always) the communication protocols have roughly the same structure (e.g. command, parameters, length, payload, checksum).
Yeah, I’ve been through that with the Uemis :-)
What's missing? What do we have? According to the usb device descriptors it's a USB HID device. That's basically everything I know. Once I discovered libusb doesn't seem to support USB HID very well, I didn't investigate much further due to a lack of time. OK, I think there are a few more "real" USB devices coming in the near future. So let's figure out what it takes to support that family of devices. So this is the "what do we have" part. What's the "what's missing" part - i.e., where is the starting point to add support? Or is this entirely new to libdivecomputer and needs to be designed from scratch?
The cobalt is currently the only device which uses "real" usb communication. As you probably know, we're using libusb for that. But according to the libusb documentation [3], it's not suitable for HID. There is an open source hidapi library [4], but I don't have any experience with it. I also don't have much experience capturing usb communication in general (there wasn't really any need so far). USB is a lot more verbose and complex than serial communication. So yes, HID is pretty much starting from scratch.
[3] http://www.libusb.org/wiki/APIs [4] http://www.signal11.us/oss/hidapi/
Fun.
I wouldn't be surprised if the high level communication protocol is still the same as the other Uwatec devices. For the Meridian Scubapro/Uwatec also switched only the low-level layer from IrDA to usb-serial, and kept everything else the same. But of course that's just an educated guess, and I could be complete wrong. So I assume you have contact to a few people who have such computers?
So far, Vincent is the only one who requested support for the Uwatec Square.
That’s also good to know. Nick, Sven, do you have more users with that device? /D
I wouldn't be surprised if the high level communication protocol is still the same as the other Uwatec devices. For the Meridian Scubapro/Uwatec also switched only the low-level layer from IrDA to usb-serial, and kept everything else the same. But of course that's just an educated guess, and I could be complete wrong. So I assume you have contact to a few people who have such computers?
So far, Vincent is the only one who requested support for the Uwatec Square.
That's also good to know. Nick, Sven, do you have more users with that device?
No, I found just one user in my email archive. There was also a recall last month: http://www.scubaboard.com/forums/computers-gauges-watches-analyzers/489197-j ohnson-outdoors-diving-recalls-dive-computers-due-injury-hazard.html
From looking at the Square, I think the only similarity with the good old Aladins is the name, nothing more.
Sven _______________________________________________ devel mailing list devel@libdivecomputer.org http://libdivecomputer.org/cgi-bin/mailman/listinfo/devel
I've had a couple of people email about it, but I don't think anyone had one. Just expressions of interest, and I've no idea if they ordered one or something else. Nothing concrete from looking back over email. -nick On 11/09/2014, at 4:59, Sven Knoch <info@divinglog.de> wrote:
I wouldn't be surprised if the high level communication protocol is still the same as the other Uwatec devices. For the Meridian Scubapro/Uwatec also switched only the low-level layer from IrDA to usb-serial, and kept everything else the same. But of course that's just an educated guess, and I could be complete wrong. So I assume you have contact to a few people who have such computers?
So far, Vincent is the only one who requested support for the Uwatec Square.
That's also good to know. Nick, Sven, do you have more users with that device?
No, I found just one user in my email archive. There was also a recall last month:
http://www.scubaboard.com/forums/computers-gauges-watches-analyzers/489197-j ohnson-outdoors-diving-recalls-dive-computers-due-injury-hazard.html
From looking at the Square, I think the only similarity with the good old Aladins is the name, nothing more.
Sven
_______________________________________________ devel mailing list devel@libdivecomputer.org http://libdivecomputer.org/cgi-bin/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@libdivecomputer.org http://libdivecomputer.org/cgi-bin/mailman/listinfo/devel
participants (5)
-
Dirk Hohndel -
Jef Driesen -
Nick Shore -
Sven Knoch -
vavincavent