Re: cochran_emc.h: packed structs

On 28-10-14 17:32, Dirk Hohndel wrote: The reason so many people reverse engineering want packed structures is that it makes it so much easier to write readable code. A typical 8 byte sample might look like this: struct sample { unsigned char temp; // in F unsigned int16_t

Re: Petrel data problems [was Re: Crash when opening log file]

On 23-11-14 16:25, Dirk Hohndel wrote: On Sun, Nov 23, 2014 at 11:39:55AM +0100, Henrik Brautaset Aronsen wrote: I did a new fresh import from my Petrel on the latest master and saved it. This time the saved petrel2.xml [1] does not contain the empty cylinder / statements. But id does

Re: building with my private libdivecomputer branch

On 01-12-14 20:33, Dirk Hohndel wrote: Jef, I think I have lost your other branches (the release branches) in the migration. Before I restore them from incorrect versions, would you just push them, please? Everything should be there again. Jef ___

Re: Problem with Atomic Cobalt 2

On 18-12-14 20:26, Dirk Hohndel wrote: On Thu, Dec 18, 2014 at 07:13:51PM +0100, Familie Rave wrote: I made an update to 4.3. but the problem is the same. Here is the logfile: Event: vendor=3239313430353431E20002000200 Event: model=2 (0x0002), firmware=14811138 (0x00e20002), serial=29140541

Re: RFC: Suunto Vyper Air configuration

On 2015-02-06 14:49, Guillaume Gardet wrote: Currently, we are able to configure Suunto Vyper family with sample rates of 10, 20, 30 or 60 per seconds. The problem is that the Suunto Vyper Air is also able to set the sample rate to 1 per second. The Vyper and Vyper Air belong to two different

Re: CCR mode and our implementation of the setpoint

On 07-02-15 17:10, Dirk Hohndel wrote: The other question, of course, is what to do in the future. As you correctly point out in another email, CCR/OC is /not/ a property of a dive. Freedive / Scuba is. I don't know how PSCR fits into this whole discussion as I don't have the slightest idea what

Re: Cross compiling for android

On 15-01-15 20:34, Anton Lundin wrote: On 15 January, 2015 - Thiago Macieira wrote: Your problem is that the configure script for libxml2 picks up your lzma from your host os. I don't know any good way to get it to not do that, so my tip is to remove your liblzma-dev-package from your host. Do

Re: Petrel progress bar problem [was: Re: testing of download from divecomputer needed]

On 2015-01-14 22:47, Henrik Brautaset Aronsen wrote: Henrik Brautaset Aronsen wrote: An individual 0-100% progress for each dive is OK. Ignoring the fact that it currently never reaches 100%, a progress for each individual dive is not as good as a global progress for the entire operation.

Re: Petrel progress bar problem [was: Re: testing of download from divecomputer needed]

On 14-01-15 19:43, Henrik Brautaset Aronsen wrote: Jef Driesen wrote: This is a (known) bug in libdivecomputer. Instead of a global progress for the entire download, the petrel backend reports progress for each individual dive. So the progress bar will go from 0 to 100% for every dive. Due

Re: Any qmake experts out there?

On 2015-01-29 14:38, Thiago Macieira wrote: On Thursday 29 January 2015 15:30:43 Lubomir I. Ivanov wrote: this is what i would do: - all: main.exe .PHONY: persist version.h: persist cat $@ 2 /dev/null || git rev-parse HEAD $@ git rev-parse HEAD $@.tmp git diff

Re: Import problems with Cobalt 2 on Fedora 21

On 2015-02-02 05:33, Linus Torvalds wrote: On Sun, Feb 1, 2015 at 7:36 PM, Matt Thompson math...@gmail.com wrote: I recently switched to Fedora 21 from Sabayon. I added my user to the dialout group as that is the group for /dev/ttyS*. All of the /dev/ttyS* devices have permissions 660. The

Re: issue with data trasfer from zoop

On 06-01-15 16:22, Anton Lundin wrote: On 06 January, 2015 - Andrea Bevilacqua wrote: I've just installed Subsurface and tried to download the diving data from my Suunto Zoop diving computer. Apparently everything is well configured, and no communication error is raised as the download command

Re: testing of download from divecomputer needed

On 2015-01-13 09:11, Dirk Hohndel wrote: On Tue, Jan 13, 2015 at 09:00:50AM +0100, Henrik Brautaset Aronsen wrote: The only thing I reacted to was that the progress bar only worked during the first couple of minutes. After that it was at 0%. That's strange. Looking at the

Re: Dive site tags [was: IMPORTANT information about current master: dive site management]

On 2015-02-15 15:43, Dirk Hohndel wrote: On Sun, Feb 15, 2015 at 11:19:50AM +0100, Davide DB wrote: country country/place country/state/place This is the problem with taxonomies. Now we are starting to create structure. I know at least on diver who always tracks the body of water. I know

Re: Qt Bluetooth in 5.5

On 2015-03-19 14:23, Lubomir I. Ivanov wrote: On 18 March 2015 at 05:48, Dirk Hohndel d...@hohndel.org wrote: Thiago, would Subsurface benefit from using Qt Bluetooth for our intended Bluetooth integration? This would cause some interesting architectural challenges with libdivecomputer (as

Re: GSoC Project: Native Bluetooth support for Linux and/or Windows

On 2015-03-09 14:05, Tommi Saviranta wrote: On Mon, Mar 09, 2015 at 15:33:24 +0300, Purity Musyoki wrote: In the ideas page, it is noted that there is some sample code of what has been done so far regarding the [native] bluetooth idea. I have gone through the source code for the Subsurface

Re: GSoC Project: Native Bluetooth support for Linux and/or Windows

On 2015-03-09 14:12, Lubomir I. Ivanov wrote: i'm not very familiar with this GSoC idea and bluetooth in general. Subsurface and the underlying libdivecomputer today use the rfcomm emulation to communicate with Bluetooth enabled dive computers. We should use native Bluetooth instead

Re: OSTCTools import support

On 2015-04-02 18:29, Dirk Hohndel wrote: On Sun, Mar 29, 2015 at 08:46:29PM +0200, Salvador Cuñat wrote: + +/* + * Parse data buffers instead of dc devices downloaded data. + * Intended to be used to parse profile data from binary files during import tasks. + * Actually included Uwatec

Re: qt5 problems with cmake

On 2015-04-17 08:25, Willem Ferguson wrote: When I run subsurface/scripts/build.sh from home/src, I get: -- Up-to-date: /home/willem/src/install-root/include/marble/RoutingProfile.h CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake:26 (find_package): Could not find a

Re: Galileo Sol dive log decoding for sidemount dives.

On 2015-04-15 11:23, Willem Ferguson wrote: Attached is my modification of Simon's code for decoding Uwatec dive logs. For your convenience I also attach a dive log. If you look around line 388, there is decoding of bookmarks. If you look at lines 390-440 there is decoding of cylinder changes.

Re: Eon Steel only downloading 16 out of 19 dives

On 19-05-15 22:10, Robert Helling wrote: On 19 May 2015, at 20:15, Linus Torvalds torva...@linux-foundation.org wrote: Hmm. In fact, I guess you can already get it. There's left-over debugging code in there, and you just have to enable logging (ENABLE_LOGGING during the build) and make sure to

Re: Petrel 2 Download

On 19-05-15 17:57, Anton Lundin wrote: Just another wild guess is to test another rfcomm channel? You can take a look at what the device says with sdptool browse. This is an interesting question. The bluetooth rfcomm channel is very similar to a tcip/ip port. If I remember correct, the

Re: Some initial work for the new Suunto EON Steel firmware update

On 2015-06-09 01:25, Linus Torvalds wrote: On Mon, Jun 8, 2015 at 10:09 AM, Linus Torvalds torva...@linux-foundation.org wrote: I'll get to the actual sample data later today, I hope. .. and here's that third patch that converts the sample parsing to dynamically using the actual sample type

Re: [GSoC] Week 3 (Native Bluetooth support)

On 2015-06-15 13:46, Anton Lundin wrote: On 15 June, 2015 - Claudiu Olteanu wrote: Ok. In the beginning I will try to implement the downloading entirely in Subsurface and re-implement the dive computer protocol for HW OSTC family. I think this is a bad path. I would rather suggest

Re: [GSoC] Week 3 (Native Bluetooth support)

On 14-06-15 21:56, Dirk Hohndel wrote: On Jun 14, 2015, at 12:00 PM, Claudiu Olteanu Do you have any suggestions how to do that? Do you believe that this is a bad idea? Should I give up with the Qt Bluetooth API and move further? I think you should consider just using the parser from

Re: [GSoC] Week 3 (Native Bluetooth support)

On 2015-06-15 20:26, Thiago Macieira wrote: On Monday 15 June 2015 06:13:54 Dirk Hohndel wrote: On Mon, Jun 15, 2015 at 03:01:44PM +0200, Jef Driesen wrote: I did already think about this :-) See [1] for some more background info. In a nutshell, the serial layer will be changed from

Re: Current subsurface issues..

On 2015-06-15 06:58, Linus Torvalds wrote: On Sun, Jun 14, 2015 at 3:24 PM, Linus Torvalds torva...@linux-foundation.org wrote: Our handling of air time remaining events is pretty nasty. This is not new, but I noticed just because I added support for it to the EON steel backend now that the

Re: [GSoC] Week 3 (Native Bluetooth support)

On 2015-06-14 23:43, Claudiu Olteanu wrote: Thanks for your suggestions, Jef! I can definitely do that but I was looking for a solution which doesn't imply changes on *libdivecomputer* project. An ideal solution which is implemented on *Subsurface* project and doesn't need to re-implement the

Re: Pressure line missing on dive profile

On 2015-07-01 15:51, Dirk Hohndel wrote: I'm not familiar with the Cobra. But from looking at pictures it should be hose based and air integrated? Then the pressure in the cylinder entry comes from the pressure delivered in the samples. So the question is... if you look at the samples, are

Re: [PATCH] libdivecomputer - custom implementation for serial communication

On 2015-06-26 01:33, Claudiu Olteanu wrote: I attached some patches which can be used to make the *libdivecomputer * project to accept callbacks to custom functions used for serial communication. As I mentioned in my weekly report, I am not sure if I made the best decisions on the

Re: Pressure line missing on dive profile

On 02-07-15 20:34, Dirk Hohndel wrote: On Thu, Jul 02, 2015 at 10:47:58AM -0700, Steve Butler wrote: Will need to be home tonight to grab the DC to download again. (Someone said we could use the dump file to simulate the DC. How is that done? I do have the dump file I attached to an earlier

Re: Subsurface interface with libdivecomputer

On 2015-05-19 20:57, Salvador Cuñat wrote: 2015-05-19 10:50 GMT+02:00 Willem Ferguson willemfergu...@zoology.up.ac.za Dirk you are absolutely correct. I ran universal after your last mail, above, and the events are not shown in the xml, even though I see them clearly in the binary dump. So the

Re: Subsurface interface with libdivecomputer

On 2015-05-21 15:11, Dirk Hohndel wrote: On May 21, 2015, at 2:49 AM, Jef Driesen j...@libdivecomputer.org wrote: That's another thing. Internally Uwatec stores the id of the gasmix, but currently the libdivecomputer api delivers only the o2/he percentages, so you can distinguish between two

Re: [PATCH] libdivecomputer - custom implementation for serial communication

On 2015-06-29 23:11, Claudiu Olteanu wrote: Hello Jef, Thanks for making time to let us know what you have in mind for the next release. More or less it is similar with the changes I made, except that I tried to avoid to modify the native serial implementation. I will make you a short resume

Re: [GSoC] Week 3 (Native Bluetooth support)

Dirk, Sorry for the slow response. Been busy with real life. On 2015-06-17 16:45, Dirk Hohndel wrote: I don't know which other apps use libdivecomputer, but the ones that I know about... Subsurface: happy to implement a Bluetooth backend, happy to use the existing libdivecomputer

Re: Linking error with recent libdc

On 2015-07-08 07:13, Gaetan Bisson wrote: [2015-07-07 21:45:49 -0700] Dirk Hohndel: On Tue, Jul 07, 2015 at 05:59:00PM -1000, Gaetan Bisson wrote: Linking CXX executable subsurface libsubsurface_corelib.a(libdivecomputer.c.o): In function `do_libdivecomputer_import':

Re: Failed OSTC3 fw update

On 2015-09-17 08:43, Paul-Erik Törrönen wrote: As a result I get 'Error: Firmware update failed!' on the bottom of the Configure dive computer-dialog. In the terminal, from which I started Subsurface: [78.817027] ERROR: Unexpected character (0x50). [in hw_ostc3.c:966

Re: [PATCH 2/2] qtserialbluetooth: use QIODevice::Unbuffered io

On 2015-09-29 23:54, Anton Lundin wrote: On 29 September, 2015 - Thiago Macieira wrote: On Tuesday 29 September 2015 21:59:31 Anton Lundin wrote: > - rc = device->socket->write((char *) data + nbytes, size - > nbytes); > + rc = device->socket->write((char *) data +

Re: ostc BT download failure

On 2015-09-29 20:06, Miika Turkia wrote: I am testing out OSTC sport and BT download. However, this fails miserably: ---8<--- INFO: Sleep: value=300 Event: model=18 (0x0012), firmware=2578 (0x0a12), serial=10321 (0x2851) You have an OSTC Sport with firmware v10.18. ERROR:

Re: freedive mode

(moved the discussion to the developer mailinglist) On 2015-10-03 13:14, Dirk Hohndel wrote: On Sat, Oct 03, 2015 at 12:20:35AM -0700, Giorgio Marzano wrote: It could be another (and IMO better) way to handle freedive sessions. Libdivecomputer could return a list of single dives instead of

Re: issues with Sherwood Wisdom - some fields missing

On 19-06-16 00:00, Hartley Horwitz wrote: One issue I’m seeing is downloading info from my Sherwood Wisdom computer (the first version, i.e. Wisdom 1, not Wisdom2 or 3). The basics of my dive are downloading properly, and the profile, but the oxygen setting when diving Nitrox is not downloading

Re: Tusa Zen IQ900 download

On 2017-02-08 08:56, Willem Ferguson wrote: I have a Tusa IQ900 dive computer which, as far as I am aware, is actually a repackaged Oceanic Atom 2. Attached are the log and bin files. After downloading dives to Subsurface, there is an error message referring to unrealistic gas mixtures for

Re: OzTek 2017

On 22-01-17 17:10, Dirk Hohndel wrote: On Jan 22, 2017, at 2:32 AM, Anton Lundin wrote: Shearwater we have great relationships with (ok, they still owe me a response on more details of the new BTLE communication, but hey, they already sent me a Perdix AI). We used to have a

Re: OzTek 2017

On 22-01-17 02:28, Rick Walsh wrote: Hi, I'll be going to OzTek (dive conference and exhibition) in Sydney March. Firstly, is there anyone else involved in Subsurface who's going and would like to meet up. Secondly, there'll be representatives from various manufacturers, agencies and DAN with

Re: Tusa Zen IQ900 download

On 08-02-17 15:05, Willem Ferguson wrote: On 08/02/2017 13:57, Jef Driesen wrote: Normally the Oceanic based applications have some kind of export to txt function. Attached a comma-delimited archive of the dives. It was all done on Win, so I apologise for a rather primitive archival mechanism

Re: bug when importing from Oceanic VT4.1 with multiple sources

It's on my todo list to look into this. But at the moment I'm a bit overwhelmed with bug reports, so it's going to take a bit longer. Most likely the problem is that a tank switch sample also includes a pressure value. That's where we get that initial pressure from. I suspect there might be

Re: [PATCH 4/3] Document quirks with Ostc 4 versions

On 29-12-16 15:40, Anton Lundin wrote: On 29 December, 2016 - Jef Driesen wrote: On 28-12-16 21:06, Anton Lundin wrote: - // for now libdivecomputer gives us the firmware on device undecoded as integer + // libdivecomputer gives us the firmware on device as an integer

Re: [PATCH 4/3] Document quirks with Ostc 4 versions

On 28-12-16 21:06, Anton Lundin wrote: - // for now libdivecomputer gives us the firmware on device undecoded as integer + // libdivecomputer gives us the firmware on device as an integer // for the OSTC that means highbyte.lowbyte is the version number + // For OSTC

Re: Fwd: direct import form dive computer

On 2017-03-14 22:08, Alessandro Volpi wrote: after having downloaded the linux version of dctool and having added tho the execute permission to the y fdownloaded file I tried to obtain a new copy of the SmartTec's memory dump The program did not succeed in opening the device. The terminal

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

On 2017-04-09 14:00, Anton Lundin wrote: On 09 April, 2017 - Joakim Bygdell wrote: Jef, how is on the backed side, how many sensors does libdivecomputer supports for the Petrel series? I sort if figured out now to extract po2 valeues for all sensors from Shearwater comptuers, but due to it

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

For the Shearwater Petrel CCR divers reading this: Can you supply us with some more data to test against? The Petrel protocol doesn't support memory dumps, so you'll need to dump the individual dives. You can do that with libdivecomputer' dctool:

[PATCH 1/2] Fix building against upstream libdivecomputer

The custom_serial.h header doesn't exist in upstream libdivecomputer. Signed-off-by: Jef Driesen <j...@libdivecomputer.org> --- core/libdivecomputer.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/core/libdivecomputer.h b/core/libdivecomputer.h index aba972d..b8f6928 100644 ---

[PATCH 2/2] Cleanup some unnecessary include statements

Some of these header files are no longer necessary, and will be removed from libdivecomputer in the near future. Signed-off-by: Jef Driesen <j...@libdivecomputer.org> --- core/configuredivecomputer.cpp| 1 - core/configuredivecomputerthreads.cpp | 3 ++- core/libdivecomp

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

On 2017-04-13 17:04, Jef Driesen wrote: I don't entirely agree with that. If you check the available memory dumps, 5 of them contain CCR dives. I analyzed all of them, and this is what I found: * petrel.marklee.bin The three mV values in the samples are always zero. But since all three O2

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

On 2017-04-12 10:47, Anton Lundin wrote: On 12 April, 2017 - Davide DB wrote: On 11 April 2017 at 23:44, Jef Driesen <j...@libdivecomputer.org> wrote: > I'll need to look again at the old discussion, but if I remember > correctly, your patch produced bogus results for some o

Re: testing smtk2ssrf_4.6.2-33-g14971e912875_x86_64-20170224.AppImage

On 2017-03-08 23:58, Salvador Cuñat wrote: On Tue, Mar 07, 2017 at 03:30:14PM +0100, Jef Driesen wrote: At first sight, it looks like the profile is truncated. (I can't really confirm that, because I don't know how long the dive should be.) The last sample isn't complete. The size check

Re: direct import form dive computer

On 11-03-17 23:41, Alessandro Volpi wrote: I have downloaded the full memory content of my Galileo Trimix computer. The resulting files can be found in my Dropbox folder, subdirectory galileo_trimix_import : https://www.dropbox.com/sh/dsg43qcbo013i1k/AAC_vCS3cZeZar5i3HngCNq3a?dl=0 I don't

Re: direct import form dive computer

On 2017-03-12 18:52, Alessandro Volpi wrote: I apologize for not having actually loaded the subdirectory galileo_trimix_import on my Dropbox folder. The Galileo data download was executed on a laptop computer. The Ubuntu trusty system is not set up so that it automatically starts the Dropbox

Re: testing smtk2ssrf_4.6.2-33-g14971e912875_x86_64-20170224.AppImage

On 2017-03-10 11:05, Alessandro Volpi wrote: I still do not understand for which type of DC does Jef want to get a the "memory dump". I should be able to provide the memory dump of SmartTec and/or Galileo Trimix. To check whether smarttrak has truncated the profile data, I would like to

Re: Fwd: direct import form dive computer

On 2017-03-14 00:43, Alessandro Volpi wrote: I have tried once again to obtain the SmartTec memory dump with dctool.exe, on the WXP VM . VirtualBox was running on my Ubuntu trusty laptop. The command was THE RIGHT ONE, as suggested by Jef : "dctool.exe -v -l smart.log -f smart dump -o

Re: testing smtk2ssrf_4.6.2-33-g14971e912875_x86_64-20170224.AppImage

On 2017-03-03 14:08, Salvador Cuñat wrote: On Fri, Mar 03, 2017 at 10:50:23AM +0100, Salvador Cuñat wrote: El 03/03/2017 09:53, "Anton Lundin" escribió: > > I guess its easiest just to modify the libdivecomputer call to dump the > profile data to a file. That way smtk2ssrf

Re: testing smtk2ssrf_4.6.2-33-g14971e912875_x86_64-20170224.AppImage

On 2017-03-02 21:57, Salvador Cuñat wrote: 2017-03-01 0:20 GMT+01:00 Alessandro Volpi : After my latest test run I am able to send you this message with my remarks about the observed behavior of smtk2ssrf : Some "data format errors" are detected in a number of dives

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

On 14-04-17 22:04, Anton Lundin wrote: On 14 April, 2017 - Jef Driesen wrote: On 2017-04-13 17:04, Jef Driesen wrote: I tried a different approach yesterday. Instead of adding 1024 to the calibration value, I simply used the stored value as is, and calculated the average ppO2 over all three

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

On 14-04-17 21:57, Anton Lundin wrote: On 13 April, 2017 - Jef Driesen wrote: On 2017-04-12 10:47, Anton Lundin wrote: The issue with current libdivecomputer DC_SAMPLE_PPO2 is that you cant distinguish between ha "real" "voted" pO2 and the raw sensor value. I would

Re: RATIO iX3M DEEP computers compatibility and connection/configuration problem

On 2017-08-16 11:46, Anton Lundin wrote: Step one would be some documentation. How to read and write settings to the computer. Whats the protocol? Which settings are there and how to interpret the data. The information doesn't need to be "public", but the code we write based on it will be. As

Re: Atmospheric pressure for Ratio iX3M

On 2017-07-13 10:11, Robert Helling wrote: we have a user report on the forum that gets incredibly low SAC rates for dives downloaded from a newly acquired Ratio iX3M. Looking at the xml I see there surface pressure values of above 9bar. Does anybody have an idea how those come about? Maybe

Re: [RFD] divecomputer time/date synchronization while downloading dives

On 19-07-17 22:08, Linus Torvalds wrote: Anyway, what this all builds up to is that I'd actually like to just set the time automatically when I connect the dive computer to my laptop (or my cellphone, for that matter - usually those end up being synchronized to the local time quite nicely). And

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

On 2017-04-17 22:34, Anton Lundin wrote: On 17 April, 2017 - Jef Driesen wrote: On 14-04-17 21:57, Anton Lundin wrote: >On 13 April, 2017 - Jef Driesen wrote: > >>On 2017-04-12 10:47, Anton Lundin wrote: >>> >>>The issue with current libdivecomputer D

Re: [RFD] divecomputer time/date synchronization while downloading dives

On 2017-07-20 10:08, Jef Driesen wrote: On 19-07-17 22:08, Linus Torvalds wrote: Anyway, what this all builds up to is that I'd actually like to just set the time automatically when I connect the dive computer to my laptop (or my cellphone, for that matter - usually those end up being

Re: RATIO iX3M DEEP computers compatibility and connection/configuration problem

On 2017-08-22 05:29, Gregory Sin wrote: Please find testing result and files/log/screens below. DC: iX3M DEEP (Os 4.0.26/013). Clean DC, no dives logged. Mac:10.12.4 SUBSURF:4.6.4.737 BT: Only DC and Mouse are paired, but only

Re: Atmospheric pressure for Ratio iX3M

On 2017-08-21 23:30, Steve wrote: On 2017-07-13 10:11, Robert Helling wrote: we have a user report on the forum that gets incredibly low SAC rates for dives downloaded from a newly acquired Ratio iX3M. Looking at the xml I see there surface pressure values of above 9bar. Does anybody have an

Re: RATIO iX3M DEEP computers compatibility and connection/configuration problem

On 2017-08-21 16:51, Dirk Hohndel wrote: BTW: I have added some annotation in the Subsurface-branch to help us decide which dive computers to offer as choices on mobile devices (this is in src/descriptor.c): [...] This basically just adds a comment at the end of every line that follows a

Re: Ratio iX3M connection fails

On 2017-05-15 05:13, Miika Turkia wrote: On Sun, May 7, 2017 at 10:22 AM, Jef Driesen <j...@libdivecomputer.org> wrote: On 07-05-17 07:07, Miika Turkia wrote: We have a bug report that iX3M download does not work after latest firmware update. Do you Jef (or anyone else) have idea

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

On 2017-04-17 21:49, Jef Driesen wrote: On 14-04-17 22:04, Anton Lundin wrote: On 14 April, 2017 - Jef Driesen wrote: On 2017-04-13 17:04, Jef Driesen wrote: I tried a different approach yesterday. Instead of adding 1024 to the calibration value, I simply used the stored value

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

On 2017-05-11 14:20, Davide DB wrote: Ok so I made a mistake. I thought 21 was most recent. I even look carefully at the log trying to see if there was some reference. You can use dctool to parse those raw dive files: ./dctool -f petrel parse -o dive.X.xml dive.X.bin And then you can easily

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

On 2017-05-10 22:16, Davide DB wrote: I downloaded dives from my SF2 Petrel controller via dctool. I attached some of them here. Dives: 17, 18, 19, 20, 21 are mCCR with a setpoint of 0,7 Dive 15 is eCCR with setpoints of 0,7 and 1,3. It was a training dive so you will find OC parts (bailout

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

On 11-05-17 14:37, Anton Lundin wrote: On 11 May, 2017 - Jef Driesen wrote: I replaced your patch with your latest version, and updated the rest of the series. Please have a look. If you are okay with the changes, I'll merge them to master. LGTM. You can add my Reviewed-by: Anton Lundin <

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

allback && (data[86] & 0x04)) callback (DC_SAMPLE_PPO2, sample, userdata); +#endif // Setpoint if (parser->petrel) { -- 2.11.0 From 8e71ed3c7b9d7cee961c0f1f2ea85e993397f8f7 Mon Sep 17 00:00:00 2001 From: Jef Driesen <jefdrie...@users.sourceforge.net> Date: Thu, 13 Apr 2017 21:26

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

On 2017-05-10 11:33, Anton Lundin wrote: On 10 May, 2017 - Jef Driesen wrote: I've implemented the scaling factor now. See attached set of patches. It took me a bit longer than expected because there were a few cases where the ppO2 still ended up being zero. And that turned out to be for dives

Re: Scubapro Galileo 2 (G2)

On 2017-06-14 23:19, Linus Torvalds wrote: On Wed, Jun 14, 2017 at 8:14 PM, Jef Driesen <j...@libdivecomputer.org> wrote: On 2017-06-09 07:28, Linus Torvalds wrote: diff --git a/examples/common.c b/examples/common.c index 3c4561b..5ebdd77 100644 --- a/examples/common.c +++ b/examples/co

Re: Scubapro Galileo 2 (G2)

On 2017-06-22 02:49, Linus Torvalds wrote: On Tue, Jun 20, 2017 at 11:59 PM, Jef Driesen <j...@libdivecomputer.org> wrote: You are right that the USB HID packets are vendor specific, and we can't incorporate that in the usbhid code. But that's not really what the I/O refactoring is

Re: Scubapro Galileo 2 (G2)

On 2017-06-09 07:28, Linus Torvalds wrote: diff --git a/examples/common.c b/examples/common.c index 3c4561b..5ebdd77 100644 --- a/examples/common.c +++ b/examples/common.c @@ -54,6 +54,7 @@ static const backend_table_t g_backends[] = { {"smart", DC_FAMILY_UWATEC_SMART,

Re: Ratio iX3M connection fails

On 07-05-17 07:07, Miika Turkia wrote: We have a bug report that iX3M download does not work after latest firmware update. Do you Jef (or anyone else) have ideas what is going on? https://github.com/Subsurface-divelog/subsurface/issues/387 The ix3m protocol doesn't support memory dumps. It

Re: interpolating depth values

On 25-09-17 19:33, Linus Torvalds wrote: I still think that the most likely reason (by an absolutely _enormous_ margin) is simply calibration issues with the pressure sensor. All the dive computers I've ever seen basically consider a 1m depth to be "surface", probably partly because you might

Re: RATIO iX3M DEEP computers compatibility and connection/configuration problem

On 2017-08-23 06:43, Dirk Hohndel wrote: On Aug 22, 2017, at 7:55 AM, Jef Driesen <j...@libdivecomputer.org> wrote: I don't understand what you gain with those comments. I mean it's just comments. Don't you need this kind of info at runtime instead? Yup - I simply have a tool that

Re: RATIO iX3M DEEP computers compatibility and connection/configuration problem

Greg, I suspect the correct port should be /dev/tty.usbserial-DN02DP66. The others are certainly not the correct for usb-serial adapters on Mac. In one of the screenshots, you have selected a model from the iDive series. That won't work with a model from the iX3M series. This is one of the

Re: RATIO iX3M DEEP computers compatibility and connection/configuration problem

On 19-08-17 12:00, Benjamin wrote: So, after a few trials, I'm getting the following in the subsurface.log file: INFO: Open: name=00:13:43:0C:56:29 ERROR: Failed to open the serial port. [in ../../src/shearwater_common.c:46 (shearwater_common_open)] This shows exactly what the problem is! A

Re: Scubapro Aladin Square

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

Re: Scubapro Aladin Square

17 00:00:00 2001 From: Jef Driesen <jefdrie...@users.sourceforge.net> 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 --

Re: Scubapro Aladin Square

On 14-11-17 21:04, Linus Torvalds wrote: On Tue, Nov 14, 2017 at 11:57 AM, Jef Driesen <j...@libdivecomputer.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 succ

Re: Scubapro Aladin Square

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

Re: Scubapro Aladin Square

On 14-11-17 21:33, Linus Torvalds wrote: On Tue, Nov 14, 2017 at 12:15 PM, Jef Driesen <j...@libdivecomputer.org> 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

Re: Scubapro Aladin Square

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 <j...@libdivecomputer.org> wrote: I suspect this is not caused by a difference in the libusb version, but a difference in the subsurface branch of libdiveco

Re: O2 sensor values on CCR dives

On 2017-11-27 17:27, Anton Lundin wrote: On 27 November, 2017 - Davide DB wrote: On 17 November 2017 at 21:59, Davide DB wrote: Dctool is a lucky process. 99% of the times I get errors like this: [73.192176] ERROR: Failed to receive the response packet. [in

Re: O2 sensor values on CCR dives

On 01-12-17 17:43, Davide DB wrote: On 1 December 2017 at 16:54, Jef Driesen <j...@libdivecomputer.org> wrote: On 2017-12-01 15:57, Davide DB wrote: That's already good to know. So that means that either the calibration constant, our calibration formula, or even the decoding of the mil

Re: Scubapro Aladin Square

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,

Re: Anybody with a Suunto EON Core?

On 2017-11-20 02:45, Linus Torvalds wrote: I just pushed out support for the new Suunto EON Core to the subsurface branch of libdivecomputer, but I don't actually have access to the hardware, so it's purely based on reporting from Nick Shore. It almost certainly "just works" (just different USB

Re: Import data from Scubapro Aladin Sport Matrix

On 31-10-17 23:35, Berthold Stoeger wrote: On Dienstag, 31. Oktober 2017 11:29:00 CET Jef Driesen wrote: I believe you have the model number wrong. I think it should be 0x17, and your test seems to confirm that: Well, I put a printf directly after "rc = scubapro_g2_transfer (d

Re: O2 sensor values on CCR dives

On 2017-12-01 15:57, Davide DB wrote: Yes, what do you need exactly? I this thread I shared the dctool raw data file and some screenshots of Shearwater desktop and Subsurface of the same dive. I can share the Subsurface xml file and maybe an export from shearwater desktop if exist. Eventually I

Re: O2 sensor values on CCR dives

On 2017-12-02 22:39, Anton Lundin wrote: On 02 December, 2017 - Anton Lundin wrote: I saw something odd looking at that data. There's another calibration value in the data, which we never figured out the meaning of. In all other sample data its bin zero or low values like 2. In your data its

  1   2   >