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
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
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
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
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,
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
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 <
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
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
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
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
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
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
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
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
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
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
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
---
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
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 +
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:
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
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
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':
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
___
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
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
101 - 178 of 178 matches
Mail list logo