Re: Error downloading Ratio IX3M2

[Jef Driesen via subsurface]

On 2/06/2024 09:52, Mark Stiebel via subsurface wrote:
I've recently upgraded my iX3M2 Pro, replacing it with an iX3M2 GPS Deep. The 
first two dives downloaded just fine via USB cable a couple of weeks ago, and 
today went for a third dive, but I haven't managed to download. I've tried a few 
things:


1. Download using Ratio Toolbox - worked.
2. Download via USB cable - didn't work
3. Download via USB cable using an empty logbook - didn't work
4. Download via USB cable on a different computer - didn't work
5. Download via BT on a laptop - didn't work
6. Download via BT on androis - didn't work

In all cases, where it didn't work, it started downloading - read the serial 
number, gave me an error message:

     "Dive 1: Error parsing the header", and then repeated for Dive 2 and Dive 
3.

Then proceeds to tell me there were no new dives to download. I've tried a 
number of the different iX3M and iX3M2 models to see if that changes anything, 
but appears not. Also no different if I check "force download of all dives" or not.


Which version of subsurface you are using? I suspect you have a version without 
this fix:


https://github.com/libdivecomputer/libdivecomputer/commit/e1762fc8bddf9d742387617f87b990729c0e482f

The format changed in a non-backwards compatible way in the latest firmware, and 
this fix is needed to parse dives using this new format.


Before sending through the entire libdivecomputer log, maybe someone can help me 
by pointing me in the right direction from what appear to to be the relevant 
snippets. I notice that the error messages refer to src/divesystem_idive.c


I'll need the full libdivecomputer log to confirm whether this is indeed the 
problem or something different.


BTW, those NAK errors you see in the log are harmless and can be ignored. That's 
simply the dive computer saying it's still busy, and we need to wait a while and 
retry, which we do.


Jef
___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org

Re: Data download error

[Jef Driesen via subsurface]

On 28/04/2024 19:03, Kevin Metcalf wrote:

Just checking in to see if you learned anything from the files.  I am wondering 
if my computer will work going forward as I haven't had this issue in the past.


As suspected, this was indeed a problem with the memory layout. Your Geo has an 
older firmware version (1D), and those appear to use a larger end address 
(0xFFF0 vs 0xFE00). I suspect this was a firmware bug that was fixed in the 
newer version.


I already fixed the problem in libdivecomputer master:

https://github.com/libdivecomputer/libdivecomputer/commit/4914f6bff3d749984c201cb1b1eea87126755d7b

Since the affected memory area is very small, your next dives will fall again 
inside the area that is considered valid, and you should have no problem to 
download those dives with the current subsurface version. But to download those 
two affected dives you'll have to wait until the above fix makes it into a new 
subsurface build.


Jef
___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org

Re: O2 sensors on Divesoft Liberty

[Jef Driesen via subsurface]

On 11/01/2024 21:27, Robert Helling wrote:

I have a question re the Divesoft Liberty CCR. From their website I understand 
it has a total of four (2x2) O2 sensors rather than the three other rebreathers 
have. We now had a user reporting Subsurface to crash when handling a dive from 
that computer and looking at the subsurface source there is indeed an assert 
that makes sure there are no more than three sensors. Obviously that is not 
correct (but leave aside for a moment the question how a voting logic actually 
is supposed to work with four sensors).

Looking at libdivecomputer/src/divesoft_freedom_parser.c it seems, that 
correctly reports the number of sensors to be 4 but when actually reporting 
data from the sensors it reports the data from all sensors as if it were only 
one. Or am I misreading the code? Does the computer actually report which 
sensors are voted out? Is there a way for subsurface to assign the values to 
the individual sensors?


Libdivecomputer reports the sensor number, or DC_SENSOR_NONE if the data is not 
from a sensor (for example the voted/average ppO2):


https://github.com/libdivecomputer/libdivecomputer/blob/master/src/divesoft_freedom_parser.c#L911
https://github.com/libdivecomputer/libdivecomputer/blob/master/src/divesoft_freedom_parser.c#L1023

You can use this info to distinguish between the different sensors.

Libdivecomputer does not support reporting whether a sensor was voted out. The 
freedom dive computers do record this info, so this is something that could be 
added (although no other dive computers supports this). Currently we only use 
the sensor state bits to exclude sensors that are not available or not calibrated.


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

Re: "rolling" release artifacts on GitHub

[Jef Driesen via subsurface]

On 7/12/2023 20:21, Dirk Hohndel via subsurface wrote:
There is an oddity about the way this works. GitHub only does releases for tags. 
So there are basically two options:
(a) do a "latest" tag and post all the binaries under that (which is what I've 
done so far)

(b) create a tag for every merge / push to the master branch

Both have drawbacks:
(a) creates a real mess with quickly having many, many artifacts in that same 
'latest' release and the user having to figure out which ones to download.
(b) creates a real mess as the git repo gets flooded with new tags - but then 
the releases themselves look much more sane


I'm curious what people think would be the better strategy - or if there's a 
third option that I've missed.


I guess the problem with (a) is that you re-use the existing release and keep 
pushing new artifacts to it? Can't you re-create the release from scratch such 
that the previous artifacts are dropped? When I looked into this stuff for 
setting up the libdivecomputer release action I decided to use the github cli 
instead of the action. The cli supports deleting releases and removing 
artifacts, so maybe that's something you could use for this purpose?


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

Re: Divesoft integration testing

[Jef Driesen via subsurface]

On 8/12/2023 20:56, Philippe Massart via subsurface wrote:
Since several years now, I import .DLF files from my Divesoft Freedom computer 
without any problem.


I saw that Divesoft Freedom and Liberty where integrated into libdivecomputer, 
and that a next release of Subsurface could include direct download from the 
dive computer, instead of manually import .DLF files.


For now (test version from November 21th), Divesoft computers are well in this 
list of supporter computers but no import is available, perhaps because no mount 
point is available: the mount point showed is the one from my other computer 
(Garmin), and no change or manual selection is possible (see attachment).


My Divesoft computer mount point on Mac is /Volumes/FREEDOM, and 
/run/media/username/FREEDOM under Linux


If there is something to test about that, don’t hesitate to tell me.


The libdivecomputer integration is for downloading dives over bluetooth (BLE). 
That's why the mount point control is disabled, because it's not used for 
bluetooth communication. This feature is only available in the newer versions of 
the Freedom and Liberty. For the older models, which are using USB mass storage, 
you can import the DLF files as before. The download over bluetooth will simply 
download the same content as the DLF files, so there is no difference in the 
data that gets downloaded.


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

Re: Shearwater imports - phantom cylinders when additional gas mixes are configured

[Jef Driesen via subsurface]

On 13/11/2023 01:44, micha via subsurface wrote:

Option 4 :  Figure out why Subsurface is importing a "gaschange" event
to a third cylinder instead of assigning it to one of the cylinders with
transmitter values attached.


That's easy to answer. You have 4 configured gas mixes:


 1. (off) 99/00
 2. (off) 51/00
 3. (ON) 32/00
 4. (off) 21/00
 5. (off) 0/0  (never configured a fifth mix, so this is still the
original default)


And you also have two transmitters T1 and T2.

Now, because there is no information present to be able to link a transmitter to 
the corresponding gas mix, subsurface simply links them one to one (e.g. gas 1 
with transmitter 1, and so on), and you end up with 4 tanks:



1. EAN99 (with T1 data attached)
2. EAN51 (with T2 data attached)
3. EAN32 (attached to an initial invisible-in-the-UI "gaschange" event
which is in the Subsurface computer dive log at time 0:10, the same time
as the first log event from the dive computer).


But the dive computer does report the dive starts with EAN32, and thus there is 
also a gaschange to this gas mix present. That's why subsurface considers this 
cylinder in use. The other two cylinders are not considered in use, because 
there were no gas changes to EAN99 or EAN51. But there is of course pressure 
still data for them.


The extra 4th tank will get Air as mix. Depending on your subsurface settings, 
this one might remain hidden in the UI because it's not used in any way (no gas 
change and no pressure data).



Of course, if I've done something wrong with configuring Subsurface or
my Dive Computer, I'd be more than happy to fix the errors of my ways,
but long previous discussions have led me to believe it's an issue with
the way Subsurface and libdivecomputer import dives and assign gas mixes
to tanks, in combination with the Shearwater protocol not supplying
information as to which gas mixes are active and which are inactive.


There is nothing wrong on your side. The main problem is indeed the fact there 
is no direct link between gas mixes and tanks in the Shearwater data format. 
That means subsurface has to guess, and in some cases that goes wrong.


But what makes this situation even worse here, is that I assumed the on/off 
status of the gas mixes isn't present in the data. The result is that always all 
5 gas mixes are reported (unless their He/02 content is reset to 0/0). Of 
course, the more gas mixes are present, the higher the chance the linking goes 
wrong, especially when those excess gas mixes are first in the list.


Looking again at the documentation, it seems the on/off info is actually 
present. I just never noticed its presence. Probably a feature that was added in 
a later firmware version? So that means we can hide those EAN99 and EAN51 mixes! 
That won't solve every case, because subsurface still won't know what gas mix is 
in your second tank (*), but it should already be a nice improvement.


(*) In libdivecomputer master there is already a sidemount flag that could help 
subsurface to figure this out too.


@Micha: Can you do a full download of your dives with both the "Force download 
of all dives" and "Save libdivecomputer logfile" checkboxes enabled, and send me 
the log? I would like to have a look at your dives to implement this fix. After 
the download you can simply cancel without re-importing any dives into your logbook.


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

Re: GitHub two-factor authentication

[Jef Driesen via subsurface]

On 18/05/2023 09:49, Berthold Stoeger via subsurface wrote:

Currently I am locked out of GitHub, because it changed to two-factor
authentication. This is somewhat annoying as currently I have a number of more
"interesting" problems.

It seems that I have to install an application such as 1password. But that
doesn't solve any problem for me. It makes my situation worse, because it
requires another app and another account, of which I have way too many
already. And no, I don't want to store my passwords on a foreign server,
encrypted or not.

So my question is: what is the most convenient way to circumvent this 2FA
thing on Linux (Kubuntu in particular)?


I can recommend Aegis (Android) and KeePassXC (cross-platform) for 2FA.

https://getaegis.app/
https://keepassxc.org/

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

Re: Unable to download logs from Petrel3 w/ android app

[Jef Driesen via subsurface]

On 18/12/2022 20:22, Attilla de Groot wrote:

Shearwater has solved this issue in their latest update (v93). It now looks 
nicely in their own app as well and I’m able to download the logs directly into 
subsurface.


Fixed as in new dives are now recorded correctly? Or is the data also fixed for 
your previously recorded dives? I assume only for the new dives?



One question on my specific CCR logs. The XCCR has integrated pressure sensors 
for O2 and DIL. These are available on the Petrel3 (not my Nerd2 btw) and also 
displayed in Shearwater cloud after importing the dive:

Unfortunately I don’t see these in Subsurface. Not sure if it would be useful, 
but I would like to have the data. The data itself doesn’t seem to be exported 
in Shearwaters own export format or UDDF (see attached). Is this a setting I 
would need to change to get it in Subsurface or is this simply not supported?


There are indeed a few differences for XCCR, which I didn't investigate further 
because I didn't have such data. I'll need to have a look at the raw data for 
that. Can you enable the "Save libdivecomputer logfile", do a full download 
(with "Force download of all dives" enabled) and send me the log file?


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

Re: Unable to download logs from Petrel3 w/ android app

[Jef Driesen via subsurface]

On 5/09/2022 17:25, Attilla de Groot wrote:

I looked at the dive profile and the xml, but I don’t see anything that would
explain this. I was just diving with 100% o2 and AIR as diluent. I did have a
transmitter to my bailout stage that also had AIR. Could this be related?

I have downloaded the log through the shearwater (android) app and exported
it to Subsurface. A bit of a long way around, but in the end it worked. I
have attached those outputs, perhaps that helps in any way?


That shearwater xml file is interesting because it also contains a large amount 
of gas mixes, and many of those contain invalid values (e.g. 02 percentages 
larger than 100%).


For example the first sample contains:

1.29
0

That's a mix containing 129% 02, which of course doesn't make any sense. When 
importing the dive into shearwater cloud desktop, I also get those many gas 
switches and the invalid values. See the attached screenshot.


Except for those fractionO2 values, the rest of the data looks normal. So at 
first sight the problem appears to be in the raw data, and not the parsing. 
Maybe a bug in the Petrel firmware? I'll report the problem to shearwater.


The UDDF export doesn't seem to contain any gas mix info at all, and when 
importing the shearwater xml into subsurface, the gas mix info seems to be 
ignored too. So that's probably why your workaround is working.


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

Re: Unable to download logs from Petrel3 w/ android app

[Jef Driesen via subsurface]

On 5/09/2022 12:46, Attilla de Groot wrote:
On 5 Sep 2022, at 12:19, Jef Driesen <mailto:j...@libdivecomputer.org>> wrote:

According to the logs, there were two dives downloaded:

 2022-07-29 21:14:40
 2017-01-01 01:31:37

That's clearly not a dive done "this morning", but both dives were CCR dives 
according to the dive mode. Is the clock of your dive computer set correctly?


I don't see any other dives present in the manifest (all zeros).


Those two were downloaded from the Nerd2 that indeed had the date/time 
incorrectly set. Downloading from the Nerd2 worked without problems, the first 
was the factory test and the second the  actual dive from 2022-09-04, but with 
the wrong date.


Okay, that log had nothing to do with the problem you are reporting. That's just 
confusing.


Before that, I tried at least 5 times to download the dives from the Petrel3. 
Dirk reached out directly and suggested I try the QT6 build on my laptop with 
the Petrel3. That made BT work, but gave the same problem as the Android app 
(“No new dives downloaded from dive computer”). Despite starting it in verbose 
mode, the only thing in the red bar says: “Dive 1: Error parsing the 
header”.Tried multiple times in various ways (with/without force, removing the 
imported dive etc.), but that didn’t change the result.


Try again with the "Save libdivecomputer logfile" checkbox enabled, and email me 
the log file.


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

Re: Unable to download logs from Petrel3 w/ android app

[Jef Driesen via subsurface]

On 4/09/2022 13:34, Attilla de Groot via subsurface wrote:
This morning I made my first ccr dive (of course it was horrible, I need to 
learn to dive again...) .


I have a Petrel3 with it, but I'm unable to download the dive log to the android 
app (I'll try later with my laptop). It connects, the computer says it's 
sending, but subsurface claims there are now new logs. The shearwater app itself 
is able to download them though.


I've put the logs here: 
https://gist.github.com/packetninja/3ac8d18b9feb56edbde4e7414815a7b9 


I know it's a new model so if there's anything else I can do, let me know.


According to the logs, there were two dives downloaded:

  2022-07-29 21:14:40
  2017-01-01 01:31:37

That's clearly not a dive done "this morning", but both dives were CCR dives 
according to the dive mode. Is the clock of your dive computer set correctly?


I don't see any other dives present in the manifest (all zeros).

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

Re: Cylinder list mismatch

[Jef Driesen via subsurface]

On 13/06/2022 05:04, Dirk Hohndel via subsurface wrote:
A couple of dive computers will import all gases that are configured, even if 
you never switched to them. And if you have a default cylinder configured in 
Subsurface, then this turns into these ghost cylinders.


One reason libdivecomputer usually returns all configured gas mixes is because 
(as Steve mentioned) some users want to see those unused mixes. But it not 
always consistent, and depends on the backend implementation (*). Maybe it would 
a good idea to include an enabled/disabled flag to give a bit more information 
to the application?


Whether a gas mix is used or unused is something the application can already 
detect by looking at the gas switches in the samples. But the enabled/disabled 
state (if present) is not something that is exposed now.


(*) For example the iconhd backend discards disabled gas mixes, but the ostc and 
ostc3 backends does report them.


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

Re: investigating BT problem MacBook Pro <-> Aqualung i770R

[Jef Driesen via subsurface]

On 29/05/2022 13:50, Daniel Azuelos via subsurface wrote:

[ Rédigé dans le sens de lecture normal.
   Written in the usual reading direction. ]

Le (on) 29/05/2022, Jef Driesen  a écrit (wrote):

[...]
| This is a problem at the bluetooth (or driver) layer. Subsurface is unable
| to connect, so we don't even get a chance to communicate with the dive
| computer.

Thank you Jef, clear.

Which tool would you recommand as a kind of ping or nmap on the Bluetooth
field? Which method could help me diagnose if this is coming from
MacOS ( not sending ) or the i770R ( not answering )?


I'm afraid I can't help you with that part. I don't know any Mac tools.

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

Re: investigating BT problem MacBook Pro <-> Aqualung i770R

[Jef Driesen via subsurface]

On 27/05/2022 18:23, Daniel Azuelos via subsurface wrote:

Since Subsurface 5.0.8 was crashing sometimes during repeated tests,
I went back to 4.9.7 which seemed to be crash proof in the exact
same radio environment.

Distance from my Mac to the i770R:  30 cm.
i770R   RSSI:   -62 dB
Nb of other env. BT equipments: 9
best RSSI:  -54 dB

Here are my results on 30 attempts to just download from the i770R
and then exit without saving:

success failure

22  8


Strange behaviour: the time to get an answer either success or failure
seems to vary from 2 s to 30 s. Is this coming from the underlying
BT driver?
Here are included 2 subsurface log I got with the -vv arg.


Based on the information in the failure log file:


qt_ble_open( {c7d52420-5e99-4800-a1bc-e5b07b2d0770} )
trying to connect
timeout while trying to connect to the controller  
{c7d52420-5e99-4800-a1bc-e5b07b2d0770}
Finishing download thread: "Unable to open LE:{c7d52420-5e99-4800-a1bc-e5b07b2d0770} 
Aqualung (i770R)"


This is a problem at the bluetooth (or driver) layer. Subsurface is unable to 
connect, so we don't even get a chance to communicate with the dive computer.


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

Re: restarting our FAQ

[Jef Driesen via subsurface]

On 8/02/2022 21:54, Dirk Hohndel via subsurface wrote:
I haven't spent any time at all on the GitHub wiki setup to know how easily we 
could curate this and more importantly how easily one can create useful deep 
links to specific answers that could be posted into email / the forum. I 
understand very well how to manage submissions to the GitHub.io 
 page through PRs.
I need to spend time to understand how that would work with the wiki. Because 
the very last thing I need on earth is another time sucking task.


I'd still likely be leaning towards just a set of markdown pages on the 
GitHub.io  site instead of a wiki - but that's mainly because 
I haven't done the work to investigate how that would really work.


That's exactly what github wikis are: a collection of markdown files managed in 
a git repository. If you login to your account, you should see a link to clone 
the wiki locally. Should be something like:


https://github.com/subsurface/subsurface.wiki.git

I'm using this for libdivecomputer, and so far it works well for me.

As far as I know, there is no interface for PRs, but you can always publish it 
as a normal repo in the project, and then manually push to the wiki repo to 
publish changes. It might even be possible to automate that last part with a 
github action?


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

Re: handling fingerprints

[Jef Driesen via subsurface]

On 25/10/2021 19:25, Linus Torvalds wrote:

On Mon, Oct 25, 2021 at 10:13 AM Jef Driesen  wrote:


What's the reason for ignoring the fingerprint if you don't have the
corresponding dive anymore?


Simple: you successfully downloaded all the dives, but had some
problems, and never saved them.

Maybe just a "oops, screwed up editing" and exit without saving. Or
maybe a crash, whatever.

So then you restart subsurface, and need to re-download.  If you don't
actually _have_ the dive the fingerprint points to, then you should
re-download it, and not ignore it "becasue I already downloaded it".


That makes sense, but it's also a case that would disappear if the fingerprint 
is saved together with the dives.


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

Re: handling fingerprints

[Jef Driesen via subsurface]

On 24/10/2021 02:12, Dirk Hohndel via subsurface wrote:

(3) close the cloud storage, open a local .xml file; download again
-> fingerprint file is found, but the matching dive is not in the dive 
list, so fingerprint gets ignored (but why are we even looking at it???)
-> dives are downloaded, fingerprint is written again


What's the reason for ignoring the fingerprint if you don't have the 
corresponding dive anymore?


Assume you download your dives, and for some reason you don't want to keep the 
most recent dive in your logbook. Now, according to the above logic, the next 
time you download, you ignore the fingerprint because the dive isn't in the 
logbook and thus you'll re-download those old dives again, including the 
unwanted dive. For the dives that were already in your logbook, that's just 
inefficient, but they won't get added twice (I believe subsurface has some logic 
to prevent that). But that unwanted dive will re-appear, and you'll have to 
manually remove it again.


As a user, I would expect that the download resumes at the point where it 
stopped last time, regardless of whether I kept the previously downloaded dives 
or not. If I really want to re-download previously download dives, I can use the 
"Force download all dives" option, which disables the fingerprint logic.


Some example scenarios where you don't want to keep every dive recorded by your 
dive computer: If you have a watch style dive computer that you also uses as a 
watch, the watch may record activity in the pool as dives. Or someone doing both 
scuba and freedives may want to keep two separate logs.



I am back to thinking that we should consider the fingerprint a property of a
specific dive log. So both an XML file and the git storage should remember
the last fingerprint for each dive computer from which we did a direct
download. And we should index that exactly like we name these files in the
filesystem right now - model.devinfo-serial - and then have the fingerprint
data be a hex encoded byte stream of fingerprint-deviceid-diveid.

Sadly, this still causes pointless re-download orgies when a firmware change
or some other change messes with the devinfo-serial number which we have to
use as lookup parameter - but it seems like it would get more cases right
than what we have today.

Of course, this all is triggered by the plight of specifically G2 users. And
the annoying fact that even if they do the full download on a PC via cable,
they still have to get a full download to work on their phone via BLE...

I'd much rather come up with a way to not rely on the devinfo-serial number,
but at least on the G2 that one looks like it should be stable (there's no
way to get the firmware version on the G2, it seems).


Why would a change in the firmware version cause a re-download? The serial 
number in the devinfo event is completely independent from the firmware version. 
Unless the device suddenly starts to report a different number, the serial 
number will not change after a firmware update. So it's as stable as it can be.


The devinfo serial number may indeed not match exactly with the serial number as 
printed on the device (due to some additional formatting which can't be 
represented by a simple 32bit number). But that's another story. The primary 
purpose of the serial number in the devinfo event (and the devinfo event itself) 
is to support the fingerprint feature: provide a unique ID to identify an 
individual device. For that purpose, it doesn't matter it doesn't exactly match 
the human readable serial number. It that sense it's like more an opaque ID, 
just like the fingerprint itself.


Of course, where possible we try to decode the serial number correctly. The 
reason why it's a 32bit number is historic. At the time this feature was added 
(more than 10 years ago), representing serial numbers as a 32bit integer was an 
obvious choice, because that's how dive computers stored it. Since then, there 
are many new dive computers that do things a bit different...



I wonder if I am missing something in my model here... is there a scenario
where storing the fingerprint with the dive log file creates incorrect
behavior? At least for the important case (dive computer that supports both
wired and BLE transfer - do the fast wired transfer on the PC and have the
correct fingerprint for the next BLE transfer both locally AND and on the
phone) this seems like it would be an improvement...


One scenario where you have to be careful is when the download failed. Because 
dives are downloaded in reverse order, you get the fingerprint of the most 
recent dives immediately with the first dive. But if you do update the 
fingerprint when some of the older dives failed to download, then you won't be 
able to retry and download those older dives without disabling the fingerprint 
again. So you should only update the fingerprint after a successful download, 
and deal with the duplicates after retrying.


Jef

Re: BT doesn´t work

[Jef Driesen via subsurface]

On 8/07/2021 08:40, duefer--- via subsurface wrote:

my BT connection to my Ratio iX3M dosen´t work.
Which iX3M model do you have? The screenshot shows a Bluetooth Low Energy (BLE) 
connection to an iX3M 2021 GPS Tech+. That is the latest model which indeed 
supports BLE, but the older model (without the "2021" in the name) supports 
Bluetooth Classic only. So it's important to pick the correct model.


As always, include the libdivecomputer logfile by enabling the corresponding 
checkbox ("libdivecomputer-Protokolldatei speichern" in the screenshot). 
Otherwise we have no idea what went wrong.


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

Re: Can't Import dives from Mares Quad Air

[Jef Driesen via subsurface]

On 11/01/2021 20:49, Linus Torvalds via subsurface wrote:

On Mon, Jan 11, 2021 at 11:37 AM Markus Hinkelmann via subsurface
 wrote:


I tried to import my dives from my Mares Quad Air using the Interface „Mares 
BLUELINK Pro“ to subsurface.


I'm afraid that the Mares BlueLink Pro has been the most problematic
piece of BLE hardware we have ever seen.

It has been known to work - often very very slowly - but it has always
been extremely flaky. I've never figured out why.


The Bluelinkpro is indeed trouble.

There is the outstanding issue of sending the commands "all at once" versus "in 
two pieces". In some cases the former seems to work better, while in other cases 
it's the other way around. So far I haven't been able to find any pattern. It 
could depend on the dive computer model, the operating system, the bluetooth 
stack, etc.



The computer was able to connect to the interface using the mode „BT-classic“ 
but the import fails.


I didn't even know that it supported BT-classic at all. I've only ever
seen it do BLE.

I was going to say that BT-classic cannot possibly work, but:


Both log files have transport=32, so that means BLE was used. Maybe subsurface 
automatically falls back to BLE if rfcomm isn't available?



A dump file was not created, but I was able to create a libdivecomputer log 
file (see attachment).


Strangely, it actually partially does seem to have worked. There are a
few valid reply packets with the valid '0xAA' packet reply byte, and
the communication actually starts. Color me I'm surprised.

So that log shows us sending several commands to it, and starting to
do a data transfer.  Yeah, we get a few NAK packets (0xEA) back
instead of 0xAA, and a couple of "no reply at all" cases, but even
then the re-try ends up working a few times.

But then at some point, even when retrying, it just returns an
all-ones (0xff) answer, and after five failres for that command we
just give up.

Honestly, this _might_ be one of those cases where "if you try again,
eventually it might work".


I suspect the single byte 0xEA response, indicates the device received the 
command packet, but can't answer for some reason. Maybe the received command was 
corrupted, and couldn't be interpreted as a valid command, or the dive computer 
wasn't ready yet to process the next command? But it's still responding somewhat 
normal, and retrying usually works just fine.


Then we have a few cases where we have no response at all. Difficult to tell 
what is going on behind the scenes. Retrying often seems to work at first, but I 
have the impression it all starts to go downhill from here. After a while we 
start to receive garbage data, and we aren't able to recover anymore. We're 
probably out of sync with the dive computer somehow. And that garbage data is 
probably some data send by the dive computer in response to one of the earlier 
commands that happens to arrive too late?


One thing that could contribute to the problem is that the iconhd protocol 
doesn't use any form of checksums. So it's nearly impossible to detect corrupt 
packets. Only the commands have a small protection in the sense that the type 
byte is repeated (with the second byte xor'ed with 0xA5). That could explain why 
it's difficult to recover once things start to go wrong. Of course that doesn't 
explain why things start to go wrong in the first place.



But equally honestly, I've pretty much given up on the Mares BlueLink
adapter. I don't know why it's so flaky. The Mares mobile app seems to
be able to talk to it, but when I did a packet trace, I didn't see it
do anything special, so I don't know what is going on. It might be
some very subtle timing issue that the Mares app is aware of.


If I remember correctly, we haven't seen any errors at all in the traces from 
the Mares application. I also have no idea why it seems to just work there, but 
not for us. It looks like they just don't seem to hit this problem. Strange.


The Mares applications sends the command in two parts:

W: CMD CMD ^ 0xA5
R: ACK(0xAA)
W: CMD_DATA
R: RSP_DATA
R: EOF(0xEA)

I've always assumed this is done because the dive computer first acks the 
command byte to indicate it's ready to receive the command payload. At this 
point it knows how many bytes to expect, and is ready with whatever it needed to do.


The only thing that could screw up is some extra latency (due to a slow BLE 
link) that exceeds some internal timeout. In that case the dive computer will 
see the CMD bytes without the payload. Of course we did still send those bytes, 
and the dive computer will get those later. And then it will probably start to 
interpret those as the next command.


If we send the whole command at once, without first waiting for the ack, we 
avoid the extra roundtrip latency. But depending how this is implemented in the 
firmware and the amount of buffering, the command payload could be arriving too 
fast, before the firmware is ready to receive those byte, and they could 

Re: subsurface Digest, Vol 107, Issue 22

[Jef Driesen via subsurface]

On 31/10/2020 17:56, Dirk Hohndel via subsurface wrote:

On Oct 31, 2020, at 3:35 AM, Matthias Heinrichs via subsurface 
 wrote:
BT LE however fails repeatedly with this error:

Subsurface: v4.9.7-223-gbd0d7bd0faa1, built with libdivecomputer 
v0.7.0-devel-Subsurface-NG (3a300a6a8ff81665463e0172e3fc5e0bcc92ec65)
[52.768160] INFO: Discover: address=947BE7B0D9F8, name=OSTC4 26
[52.768192] INFO: Discover: address=008025E056BD, name=OSTCs 1
[52.768212] INFO: Open: address=008025E056BD, port=0
[57.897396] ERROR: Ein Verbindungsversuch ist fehlgeschlagen, da die 
Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder 
die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht 
reagiert hat (10060) [in /__w/subsurface/libdivecomputer/src/socket.c:149 
(dc_socket_connect)]


BLE on Windows is always a pain.
I assume you went through the 'delete from the OS, reboot, pair again, try 
again' cycle that is sadly always the first suggestion to fix that?
I don't have a working BLE based OSTC anymore, so I cannot test with the same 
hardware, but I will double check one of my Shearwater or Suunto BLE dive 
computers, again, using the Win64 build.
I thought I tested that, but there have been so many iterations, I'm no longer 
100% sure and this is of course a very important feature...


The above log is from an BT classic (rfcomm) download, and not BLE. Of course 
that doesn't change the fact that it failed, but it's not BLE related. The 
windows error code 10060 is WSAETIMEDOUT.


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

Re: USB communication changes

[Jef Driesen via subsurface]

On 11/08/2020 19:22, Jef Driesen wrote:

Native USB communication (used only by the Atomic Aquatics Cobalt backend) was
not yet ported to the I/O stream interface. This has now changed because I just
pushed a new USB based I/O transport implementation the libdivecomputer master
branch. This means the application is now responsible for setting up the USB I/O
stream, just like all others transports. The Atomic Aquatics Cobalt backend does
no longer open the USB device internally. Passing a NULL pointer for the
iostream will no longer work!

The advantage is that an application can now also use a custom implementation on
platforms where libusb isn't available (iOS) or doesn't work very well due to
permission problems (Android).


Attached is a patch with the necessary changes for subsurface.

Jef
>From 942dd79a26dab21ea980552ef32d9a8e55c26fdd Mon Sep 17 00:00:00 2001
From: Jef Driesen 
Date: Mon, 10 Aug 2020 20:05:47 +0200
Subject: [PATCH] Setup the USB transport manually

The dive computer backend does no longer setup the USB transport
internally.

Signed-off-by: Jef Driesen 
---
 core/libdivecomputer.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/core/libdivecomputer.c b/core/libdivecomputer.c
index a99d15ae8..4c35a3593 100644
--- a/core/libdivecomputer.c
+++ b/core/libdivecomputer.c
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1323,10 +1324,24 @@ dc_status_t divecomputer_device_open(device_data_t *data)
 		}
 	}
 
-	/* The dive computer backend does this all internally */
 	if (transports & DC_TRANSPORT_USB) {
-		dev_info(data, "Opening native USB device");
-		return DC_STATUS_SUCCESS;
+		// Discover the usb device.
+		dc_iterator_t *iterator = NULL;
+		dc_usb_device_t *device = NULL;
+		dc_usb_iterator_new (, context, descriptor);
+		while (dc_iterator_next (iterator, ) == DC_STATUS_SUCCESS)
+			break;
+		dc_iterator_free (iterator);
+
+		if (device) {
+			dev_info(data, "Opening USB device for %04x:%04x",
+dc_usb_device_get_vid(device),
+dc_usb_device_get_pid(device));
+			rc = dc_usb_open(>iostream, context, device);
+			dc_usb_device_free(device);
+			if (rc == DC_STATUS_SUCCESS)
+return rc;
+		}
 	}
 
 	if (transports & DC_TRANSPORT_SERIAL) {
-- 
2.25.1

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

Re: Subsurface-mobile support request

[Jef Driesen via subsurface]

Dirk,

I don't see a description of the problem in the email thread, so I'm probably 
missing some context here. Anyway, from a quick inspection of the 
libdivecomputer logfile, the contents of the compact headers looks suspicious.


The first 4 entries all look good:

i=0, offset=0, current=1, data=C4160014011C101C1F1A1F0025010024
i=1, offset=16, current=2, data=9C14001405130A2368051C003A020024
i=2, offset=32, current=3, data=8417001405130D071C0621002F030024
i=3, offset=48, current=4, data=0F130014051310005A051A0015040024

The rest of the entries are all 0xFF, which is normal too. Except for the 228th 
entry:


i=228, offset=3648, current=16386, data=0240812005408E400220608120024020

Because this one has the highest dive number (16386), it will be selected as the 
most recent dive. But that number looks very suspicious to me. I suspect it 
might be some corrupted data instead of an actual dive. So if we try to retrieve 
that dive, I wouldn't be surprised if things go wrong. I can't really tell what 
happened, because the log appears to be truncated at this point.


@Till: Any chance you can download a full memory dump of your OSTC? You probably 
need to use the desktop version of subsurface for that. Or the libdivecomputer 
dctool command-line application. I'll likely also need the full log from a 
normal download.


If this indeed turns out to be a corrupted logbook entry, then we can probably 
fix it by erasing the problematic logbook entry.


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

Re: Re-syncing with Jef's upstream..

[Jef Driesen via subsurface]

On 8/05/2020 00:57, Linus Torvalds wrote:

Ok, so I've just spent several hours re-synchronizing our subsurface
branch with Jef's upstream.

...


I'll have a look, allthough that might take a while. Been a bit busy with real 
life during the corona crisis (day job, kids and family), so a bit less time 
left for libdivecomputer right now :-(



Jef - that "Suunto Eon Steel: sort the dive list properly" commit is
very much a bug-fix. You should take it, regardless of any subsurface
interface issues.


A wasn't aware of any issues there. I will look into it.


So is the BlueLink Pro thing, for that matter.


The bluelink pro fix is a bit problematic. There are indeed cases where 
splitting the command makes things work (mainly for subsurface users it seems). 
But I have also reports where it actually causes the communication to fail, 
while the plain libdivecomputer version works fine. So the result is that 
whatever approach we take, it's going to break for some users. That's why I 
didn't apply that change.


So far I haven't been able to figure out what the pattern is. Is this something 
related to the dive computer model, the operating system, or the BLE framework 
(Qt, .NET, Android)? I want to collect some information on that, to see if we 
can implement something that works for everyone. I'll need some more data from 
users.


Another thing that crossed my mind is to implement some kind of autodetection. 
Start with one approach, and if that fails switch to the other one.



The rest is mostly either new backends (ie the Garmin Descent and the
Deeplu Cosmiq), or the extended string interface support.

Anyway, exactly *because* the new tree is bit-for-bit identical
between the NG and DS9 branches, there's no difference on a code level
between the two, and the only real difference is that DS9 makes it
much easier to see what the changes are from Jef's point.


I usually do a diff once in a while to check the changes, but this is certainly 
easier!


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

Re: Suunto Zoop log for Christof's android changes

[Jef Driesen via subsurface]

On 2020-03-10 01:22, Matt Thompson via subsurface wrote:

Device Path: /dev/bus/usb/001/002
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID:  0403
Vendor Name (reported):  Suunto
Vendor Name (from DB):  Future Technology Devices International, Ltd
Product ID:  f680
Product Name (reported):  Suunto Sports Instrument
Product Name (from DB):  not found


This the official interface from Suunto (FTDI 0403:f680).

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

Re: Suunto Zoop log for Christof's android changes

[Jef Driesen via subsurface]

On 2020-03-09 22:39, Miika Turkia via subsurface wrote:

This is what I get on dmesg when attaching the D4 cable:
---8<---
[30804.146977] usb 1-2: new full-speed USB device number 12 using 
xhci_hcd
[30804.301648] usb 1-2: New USB device found, idVendor=0403, 
idProduct=6001

[30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[30804.301657] usb 1-2: Product: USB <-> Serial Cable
[30804.301660] usb 1-2: Manufacturer: Smartinterface
[30804.890118] usbcore: registered new interface driver ftdi_sio
[30804.890187] usbserial: USB Serial support registered for FTDI USB 
Serial

Device
[30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter 
detected

[30804.890728] usb 1-2: Detected FT232RL
[30804.891105] usb 1-2: FTDI USB Serial Device converter now attached 
to

ttyUSB0


This is a third-party interface from Smartinterface (FTDI 0403:6001).


Downloading from D4 with this cable on Android 7.1.1, the Subsurface
crashes after about 4 dives. Do you think the OTG cable plays a part on
this? I can try the app you mention if that would be beneficial.


Can you send me the libdivecomputer log file from the download?

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

Re: Suunto Zoop log for Christof's android changes

[Jef Driesen via subsurface]

On 9/03/2020 21:37, Christof Arnosti via subsurface wrote:
- Suunto D4 (uses SUUNTO_D9): App (or Download?) Crashes after about 4 
downloaded drives. There should be a mail with logs in the support mail address.


Do we have a download log for this case? That might give some more clues. I 
didn't find one in the mails. Without those logs we're flying blind, so it's 
always a good idea to provide them right away.


For better debugging I think Jef is right that it would be really nice to have 
timestamps in the libdc-logs. I attached a possible patch (porting of logfunc 
from libdivecomputer to libdivecomputer.c), but I'm currently away from my main 
computer. Maybe somebody could give it a try if it compiles and produces 
timestamps? With this we can check if the read-function still returns too early 
for whatever reason.


This patch won't compile because it tries to use functions and data structures 
from libdivecomputer that are not public.


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

Re: mailing list changes

[Jef Driesen via subsurface]

On 7/03/2020 13:50, Christof Arnosti via subsurface wrote:

Can you explain this a bit more?

I think that DKIM / DMARC does exactly what it should: preventing modification 
of mails with "MailFrom" from my domain on-the-fly.


I also have SPF configured, which should in theory also lead to a reject when my 
domain is used as MailFrom.


With DMARC, if I understand correctly, the mail should only be threated as 
boguous when both of these mechanisms fail at once. This is the case when the 
subsurface-divelog.org list server modifies my mail (breaks DKIM) and sends it 
from it own server (breaks SPF) with MailFrom ~= *@charno.ch.


I understand that this leads to problems with mailing lists, but on the other 
hand I would think that replacing the sender address by the mailing list 
software (like done now on subsurface-divelog.org) should be the right way to 
deal with this problem. Honestly, I'm more curious about why your mail client 
only displays the sender mail-address (but not always? The mail you directly 
received from Benjamin seems fine?) instead of the name in the MailFrom-Header.


I think that DMARC / DKIM / SPF are a quite important tool in the fight against 
mail spoofing, so I would hate to weaken or disable it.


Can you give me some recommendation on how I should configure DMARC / DKIM / SPF 
without breaking spoof-save mailing, but still working with mailinglists 
configured like subsurface was before?
There is an import difference between the "From" email header (which is 
displayed by the mail client), and the sender/recipient address ("mail from" and 
"rcpt to") used during the smtp communication. For SPF only the latter is 
relevant. So it would be perfectly possible to leave the From header intact:


   From: Christof Arnosti <...@charno.ch>

and send the mail from the subsurface domain:

   MAIL FROM: 
   RCPT TO: 

For SPF everything should be fine because the mail originates from the 
subsurface mail server, and the mail client will show the correct name. Or am I 
missing something? I'm certainly not an expert on mail server configuration, but 
I do run one too.


For DKIM/DMARC I don't really know.

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

Re: Import dives from Cressi Cartesio

[Jef Driesen]

On 2020-02-13 12:49, Martin de Weger wrote:

Where can I download the build for the Mac so I can test it?

I know there have been some issues with the daily build on the site.


At the moment there is no build with the fix yet.

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

Re: Import dives from Cressi Cartesio

[Jef Driesen]

On 2020-02-11 09:01, Martin de Weger wrote:

It is correct. This was the first trip I’ve used this computer (as a
backup computer), and I thought I did set up the gas mixture
correctly.


I have pushed a fix for the incorrect depth, and implemented the gas 
switches too.


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

Re: Import dives from Cressi Cartesio

[Jef Driesen]

On 2020-02-08 10:46, Martin de Weger wrote:

Yep, here it is.


It looks like there are gas switches in the dives that fail to parse. Is 
that correct? Two of those dives are a bit unusual, so I want to double 
check with you.


For example the dive on 2020-01-27 14:51:00 starts with Air. After 35 
seconds there is a switch to EAN32, which lasts for the rest of the 
dive.


The dive before (2020-01-26 16:14:00) shows the same with a switch from 
Air to EAN32 after 90 seconds.


The dive on 2020-01-26 13:11:00 looks a bit more normal, with a switch 
from air to EAN32 after 29:15.


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

Re: Import dives from Cressi Cartesio

[Jef Driesen]

On 5/02/2020 21:33, Martin de Weger wrote:
Here is the logfile and the print from the Cressi App. I also added screenshots 
from the nRF Connect app, hop this is what you wnt. The weird thing is, They 
iPhone is able to connect using BT, not the macbook (with the Cressi app)..


Can you export the data from the Cressi application? I see there is a 
backup/restore button in the screenshot. That might do the job.


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

Re: Import dives from Cressi Cartesio

[Jef Driesen]

On 2020-02-05 13:35, Martin de Weger wrote:

I’ll have a look. When using the dum-file option (in the Beta version
of subsurface) an error is thrown (something went wrong). I wanted to
install the stable version from the website, but that link is broken
(https://subsurface-divelog.org/download/Subsurface-4.9.3.dmg
). As
soon as I have the stable version up and running, I’ll give it another
try.


The Cressi Cartesio protocol doesn't support downloading memory dumps. 
As you already noticed, it will fail immediately with a 
DC_STATUS_UNSUPPORTED error. Instead of downloading a memory dump, do a 
normal download with the "Save libdivecomputer logfile" checkbox 
enabled, and send the log file.


I recommend to first create a new empty logbook file. This will force a 
full download, without messing up your real logbook. Afterwards you can 
discard the temporary logbook file again.


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

Re: Perdix AI import error

[Jef Driesen]

On 2/11/19 07:41, tormento wrote:
I am getting errors while importing dives from Perdix AI with its BT dongle (I 
don't hava any other to try) while it's own software can import dives correctly.


I select choose Bluetooth mode, find the Perdix and save.

When I try to import, I get:

Connecting to BLE device
Connecting

Then a error windows pops up with "Dive data import error".

image.png

The log tells:

Subsurface: v4.9.3-242-g9c8fbe494db2, built with libdivecomputer 
v0.7.0-devel-Subsurface-NG (426a39fc7378cac3f5b1d3983be38d56ab526e78)

INFO: Open: transport=32
INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=0, 
flowcontrol=0
INFO: Timeout: value=3000
INFO: Sleep: value=300
INFO: Purge: direction=3
INFO: Write: size=11, data=0100FF0105002E902000C0

No .bin is generated.


Uncheck the "Save libdivecomputer dumpfile" checkbox. The Shearwater Perdix AI 
communication protocol doesn't support memory dumps. Trying to download a memory 
dump will always fail with DC_STATUS_UNSUPPORTED.


For the diagnostics purposes, the log file is sufficient for these models.

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

Re: 4.9.3 preparations

[Jef Driesen]

On 7/09/19 20:16, Linus Torvalds wrote:

Now, there are other changes that Jef did to the Mares code, but the
BLE-specific change I see is his changes to do the BLE packet cache,
so it really looks like that might be it.


I doubt that change will fix Fabio's problem. That patch is needed to discard a 
corrupt packet. It won't help if there is no response or an empty packet.


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

Re: Data Analyse

[Jef Driesen]

On 2019-07-01 23:26, Patrick Briscadieu wrote:

Hello I ve got a Mares Quad,
And since the dive number 48 I can’t imports dives from my computer.
Can you analyses the files attached in this mail please


This is most likely because you have a newer generation Mares Quad with 
more flash memory. This is already fixed in latest libdivecomputer, but 
your version of subsurface is using an older version.


Just to confirm this is indeed the problem, download the dctool 
command-line application (I'm guessing you're on Mac OS X):


https://libdivecomputer.org/builds/stable/macosx/dctool

Start a terminal and execute with these options:

chmod +x dctool
./dctool -vv -l iconhd.log -f iconhd dump -o iconhd.bin 
/dev/tty.SLAB_USBtoUART


Send back the iconhd.log and iconhd.bin files.

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

Re: G2 HUD support?

[Jef Driesen]

On 2019-04-22 19:02, Linus Torvalds wrote:

I think Jef is also on the subsurface list, but I'm just adding him
here as an explicit participant in case he only tracks it
occasionally.


I'm indeed subscribed to the list. I try to follow up on the 
development, especially the libdivecomputer related questions. But 
sometimes I might miss some of the topics.



You already have the log and dump files, so hopefully Jef can tell
what the silly change to the Uwatec format is _this_ time that makes
libdivecomputer not recognize the dives as dives.


It's just the new model number that needs to be added. And of course the 
USB VID/PID. I have the necessary fixes ready to push. The G2 HUD 
appears to support BLE as well. Do we know the bluetooth device name? 
Then I can add that as well.


@William: Can you try to download a memory dump over BLE as well and 
send the logs? The bluetooth device name should be in the subsurface 
log.


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

Re: Mares genius

[Jef Driesen]

On 4/02/19 21:59, Gaetan Bisson wrote:

[2019-02-04 11:59:34 +0100] didier duriez:

j'utilise comme ordinateur, un Mares Genius, je ne le trouve pas dans votre 
liste d'ordinateur,


Notre logiciel communique avec les ordinateurs de plongée par le biais
de cette bibliothèque :

https://libdivecomputer.org/

Même s'il n'est pas explicitement mentionné dans la documentation, le
Genius est peut-être supporté car c'est le successeur direct du Icon HD
qui lui est supporté. Si vos tests confirment que c'est le cas, la liste
pourra être mise à jour.


I already had a quick look at the Genius, and at first sight it seems the data 
format has changed. So unfortunately this one is going to be a bit more work 
than just updating the list.


The download protocol is still the same, so downloading a memory dump works. 
Sending me the libdivecomputer logfile and a memory dump will certainly help me 
to get the Genius supported.


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

Re: IRDA via OTG

[Jef Driesen]

On 6/12/18 19:48, Dirk Hohndel wrote:

On Thu, Dec 06, 2018 at 06:10:25PM +0100, Robert Helling wrote:

a user ask on Facebook about accessing his Galileo Luna computer from
Android. That dive computer has an irda interface and he has an OTG
usb-irda cable. Is there a chance to get this to work or not? What am I
supposed to answer?


I have no idea, no access to such a setup, and no faith whatsoever that this
would work ever (or consistently between different phones / Android versions
/ dongle versions / dive computers. This simply isn't something that we ever
looked at.


To make this work, the phone would need an irda stack and the kernel drivers for 
the usb dongle. I would be very surprised if there are phones with those 
features enabled. Most phones don't even have the more common usb-serial 
drivers. So the chance that this will work out of the box is probably near zero.


In theory you could implement a userspace stack (there is a java implementation, 
which is also being used by Scubapro's Logtrak application) in combination with 
a userspace usb driver.


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

Re: Problems with gases on Shearwater

[Jef Driesen]

On 2018-12-05 17:17, Long, Martin wrote:

I've noticed some problems with the import of gases on Shearwater
computers. There are possible 2 issues here, but these seem to be
related.

1) I just imported 4 dives from last weekend, all CCR. The first 3
were on 13/60 diluent and the last one on 15/57. However, it put all
of the divers in as 15/57, which seems to just be the last diluent
set. The Shearwater cloud software does identify the correct gas used
at the start of the dive.

2) I'm using two transmitters on a Perdix AI. Transmitter 1 is on my
diluent, and transmitter 2 on my oxygen. On import it seems to
correctly associate my transmitter one with the diluent (apart from
the error in 1 above). Now, providing I don't do any gas switches
(e.g. a bailout) then transmitter 2 I can simply set up as 100% O2.
However, if I do a gas switch, the software automatically assigns this
gas switch to cyl 2, and so it becomes associated with the transmitter
data.

I now have 2 choices... Either I can enter a new gas of 100% and
manually type the start and end pressure - however I cannot remote it
from cyl 2. Or, I can set cyl 2 as 100%, and add a new one for my
baiout gas. However this then means the cylinder swtich then points at
the wrong gas, and will say I switched to 100% on my bailout!

I don't have a solution to this. As the import process has no manual
intervention, it would be tricky to have a solution which works. My
suggestion would be to treat transmitters and gas swtiches as
completely separate cylinders, and then allow the user to "merge" them
later. The current assumption that transmitter 1 will be the first
gas, and transmitter 2 will be the next one is incorrect.

By the way, the ability to merge the 2 profiles from my Petrel
controller, and Perdix backup (with AI) is excellent! and works really
well.


Can you send us the subsurface and libdivecomputer logfiles of a (full) 
download? That will allow us to have a look at the raw data, and see 
where or what is going wrong.


PS: The shearwater protocol doesn't support memory dumps, but I can 
extract the raw dive data from the download log.


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

Re: Mares Smart Dive Computer + Bluelink pro

[Jef Driesen]

On 2018-09-27 02:37, Linus Torvalds wrote:
So it turns out that "BLE is slow" is actually the *reason* for the 
problem.


There's some really odd timing thing, where when we send the read
command as two different packets (first the two command bytes, then
the 8 bytes of offset/length), and wait for the AA ACK in between,
something times out on the Mares side.

But if I send the command byte as *one* 10-byte packet, it all just 
works.


Which is really strange, because the Mares app itself actually sends
it as two packets, but apparently sends them quickly enough together
that the Mares doesn't go "where's the rest?" and give up on us.

Anyway, the attached patch to libdivecomputer makes it work for me.
I'm really not all that happy with the patch, but hey, it actually
removes more lines than it adds, and it does make my loaner Mares Quad
Air happy, so it's clearly doing something good.

Jef - I assume your "send first two bytes separately" model is because
that's what the Mares app does on a serial line too, and you just
followed suite?


Unfortunately that's not the reason. Originally, I used to send 
everything in one go. But for some reason that didn't work for the Mares 
Matrix, and that's why I changed it to send the command in two parts. 
See commit 59bfb0f3189b14ae858650b851539d59e3fefe86 for the details. 
It's been a while, but I think that's indeed also how the Mares 
application does it.


So I'm afraid that applying this fix, and sending everything in one go 
again, will break the Mares Matrix (and maybe also some of the other 
models). For the Icon HD it should still work, but that model is a bit 
different from the others.


So yes, this will definitely require a lot more testing on several 
models in the iconhd family before changing this.


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

Re: Mares Smart Dive Computer + Bluelink pro

[Jef Driesen]

On 2018-09-26 19:40, Linus Torvalds wrote:

Jef, what are the semantics for

ret = dc_iostream_read(iostream, buf, sizeof(buf), NULL);

meant to be when there is only a partial read? Right now it returns
DC_STATUS_SUCCESS and garbage in the end of "buf". Which really does
seem wrong. The caller has no way to know that it got a just a partial
reply..


The semantics depends on the transport type, and not whether the actual 
parameter is NULL or not:


For a stream based transport (e.g. serial, irda and rfcomm), the 
implementation should *always* try to read the requested size. Thus if 
the operation is successful (DC_STATUS_SUCCESS), the value of the actual 
parameter is guaranteed to be equal to the requested size, and hence you 
don't really need it. But if the operation fails for some reason, for 
example due to a timeout or some other I/O error, then an error should 
be returned. However, a failure does not necessary mean nothing got 
transferred at all. Therefore, the actual value should contain the 
number of bytes that were transferred successfully. This allows the 
caller to resume the operation after a partially failed transfer. (Note 
that most dive computer backends treat all errors as fatal errors, and 
in that case passing NULL is fine.)


The main reason why the iostream code always passes a non NULL pointer 
to the underlying implementation is because it needs the size for the 
logging.


For a packet based transport (e.g. ble and usbhid), the implementation 
should return a packet and indicate the size of that packet in the 
actual parameter. Thus the actual parameter is mandatory, and passing in 
a NULL pointer is indeed a very bad idea here.


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

Re: OT: Aqua Lung I100 Cable

[Jef Driesen]

On 23-09-18 22:42, Linus Torvalds wrote:

On Sun, Sep 23, 2018, 13:23 Simon Eigeldinger 
wrote:


I just got me an Aqua Lung I100.
Thought it was coming with a cable, but no.
do i need the special interface cable or can i use some standard off the
shelf cable?


Sadly, I think it needs the special aqualung USB cable that retails for
something ridiculous like $85 USD.

Even more sadly, I don't think libdivecomputer actually supports the i100
at all. I assume that it is very similar to the i200 and i300 that *are*
supported, but it might take some debugging and some help from Jef Driesen
to get a download going correctly even with the cable..


I pushed the code for the i100 this morning.

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

Re: planning for 4.8.2

[Jef Driesen]

On 2018-09-08 01:48, Dirk Hohndel wrote:
On Sep 7, 2018, at 3:11 PM, Linus Torvalds 
 wrote:


So realistically I'm weeks away, and that's not some guarantee either.
I'm really happy with how quickly the Garmin parser came together, and
we have that going for us, but plan on it being USB-only for the
immediate future.


Thanks - that’s good to know for planning purposes.

In the meantime I have started working on the Shearwater Teric 
download, which

will also significantly change the download from most other Shearwater
dive computer
(anything but Predator and /possibly/ the very oldest Petrels). I have
all the docs I need,
I had dive computers to test with, all I need is the time to implement
this and I think I
might be able to get this into testable state this weekend.

I know that Jef has also been planning to look into this, but haven’t
seen anything from
him, so I hope I’m not duplicating work that already exists.


Sorry for the late response. I've had some problems with internet access 
lately, and the past few weeks I've also been fully occupied with some 
other things in life. So I'm running a bit behind at the moment and I'll 
have a lot to catch up with. But I probably won't have much time for 
doing libdivecomputer related work until next month.


But the answer your question, I had not started working on the Teric 
support yet.


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

Re: OSTC firmware upgrade partially broken

[Jef Driesen]

On 2018-08-14 16:47, Dirk Hohndel wrote:

On Aug 14, 2018, at 7:40 AM, Jan Mulder  wrote:

Since May 19, 2018 Heinrichs-Weikamp introduced something new with 
respect to firmware numbering. On that date a version was released 
called 2.97 SP1. As I found a simple bug related to CNS display 
yesterday, I was looking at the HW website and found out that I never 
had a message from Subsurface about this new version of the firmware.


Some observations:
1) libdivecomputer seems to report the same (integer) version number 
for 2.97 and 2.97-SP1. I just upgraded my OSTC3+, and the version 
stays 609. This seems something for Jef, but not sure this breaks 
anything at the Subsurface end


We have the version string in Subsurface. Does that change? It
certainly appears to deal with X.Y.Z plus a bit for 'beta'.
You can see it under extra data.


That's the decoding of the OSTC4 firmware version. For the OSTC3 it's 
just X.Y


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

Re: libdc, libzip, Mac and Android updates

[Jef Driesen]

On 2018-08-06 01:01, Dirk Hohndel wrote:

a) tiny change to libdivecomputer (Linus, this was so trivial that I
simply pushed it to our branch... Jef, I /think/ you want this as
well) to recognize the Aqualung i750TC as Bluetooth capable
divecomputer. I don't know, yet, if it needs any additional code to
actually work - I created an Android APK for the one user who appears
to have this dive computer to try a download under Android


I also don't know whether bluetooth (rfcomm) communication will work out 
of the box or not. I know from Nick that the BLE communication requires 
some small changes to protocol, and to make things even worse there are 
several different BLE variants. So BLE support will certainly need some 
more work first. But for rfcomm, I have no idea. I don't even know 
whether the device support it.


So for the time being, I think I'll postpone applying this patch until 
someone can conform it does indeed work. Otherwise it will create false 
expectations for users.


Note that there are some more bluetooth capable models as well:

 * Aeris A300CS
 * Oceanic Pro Plus X
 * Oceanic VTX
 * Aqualung i300C (not supported yet)

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

Re: Seeman XP5

[Jef Driesen]

On 22-07-18 00:15, stra...@wp.pl wrote:
I have tried to import the dive data from computer logs. I could only get 2 last 
dives whlie there is 6 in the computer log book history.


I checked your data, and there are only two dives present. You have configured a 
(very short) 2 second sample rate, and thus the available memory (only 32K, yes 
that's kilobyte) fills very quickly! For example your two dives are 10.8K and 
12.6K in size, so you won't be able to store more than 2-3 dives. Configure a 
longer sample rate and your dive computer will be able to store much more dives 
(e.g. roughly 15 times more with a sample rate of 30 seconds). The only 
alternative is to download much more frequently.


Also relevant from the subsurface faq:

"I cannot download all my dives, only the most recent ones even though my dive 
computer's manual states that it records history of e.g. 999 dives.


Dive history is different than the dive profiles on the log. The history only 
keeps track of the total number of dives and total amount of time spent below 
surface. The logs, on the other hand, store the dive profile, but they have 
limited amount of memory to do so. The exact amount of dive profiles that can be 
stored on the device depend on sample interval and duration of the dives. Once 
the memory is full the oldest dives get overwritten with new dives. Thus we are 
only able to download the last 13, 30 or 199 dives.


If you have downloaded your dives to different dive logging software before they 
were overwritten, there is a high chance that Subsurface can import these. 
However, if the logs are only on your dive computer, they cannot be salvaged 
after being over written by new dives."


@Dirk: It would be very handy if the entries in the faq had some fixed id, so we 
can point users directly to a specific item.


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

Re: Bug with MacOS and OSTC3

[Jef Driesen]

On 2018-07-05 21:10, Otto Strassen wrote:

After updating to 4.8.0 I can no longer sync my OSTC3 with subsurface.
I have re-paired the device but it still does not work.

Someone else seems to be having the same problem:
https://subsurface-divelog.org/user-forum/?place=topic%2Fsubsurface-divelog%2FXJyZ2KWusHc%2Fdiscussion

Log from libdivecomputer
---
Subsurface: v4.8.0, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
INFO: Open: name=/dev/tty.OSTC304462-SPP
...
INFO: Write: size=1, data=6D
INFO: Read: size=1, data=6D
INFO: Read: size=607, data=...
ERROR: Failed to receive the answer. [in ../../src/hw_ostc3.c:323
(hw_ostc3_transfer)]
ERROR: Failed to read the header. [in ../../src/hw_ostc3.c:702
(hw_ostc3_device_foreach)]
INFO: Write: size=1, data=FF
INFO: Read: size=1, data=24
ERROR: Unexpected echo. [in ../../src/hw_ostc3.c:305 
(hw_ostc3_transfer)]

ERROR: Failed to send the command. [in ../../src/hw_ostc3.c:568
(hw_ostc3_device_close)]


This looks like the Mac OS X timer bug again. The libdivecomputer SHA1 
confirms that this is indeed a version without the timer fix.


@Dirk: It looks like v4.8.0 got build against an old libdivecomputer 
version. According to tags in git, it should be build against 
02560a7e7fe82919d584d3edbf3876f90382052c, which includes the fix. But 
the logs in the bugreports indicate otherwise.


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

Re: new releases

[Jef Driesen]

On 2018-06-16 01:16, Dirk Hohndel wrote:

We have lapsed on our goal to do regular releases.

Can we use the next two weeks to get both desktop and mobile into
releasable shape? Linus and I are doing "in the field testing" this
week in Japan - and true to our past track record, we have brought a
freak storm to Okinawa...

So far I found one odd bug in Subsurface-mobile with downloading from
the Suunto EON Steel. Even though I had new dives on the DC,
Subsurface-mobile told me there were no new dives. I added debug
output and tried again, and of course it worked correctly :-/
The other issue I see on Mac is that some of the dialogs have
partially cut off texts. I'm currently trying to figure out how to
even debug this. There's no reason I can figure out why those should
not automatically size correctly...

What other bugs do we know of for either desktop or mobile?

I just pushed the latest strings to transifex, hopefully two weeks of
warning should make it reasonably easy to get the translations dealt
with...

Thanks everyone!


I pushed the fix for the Mac OS X timer bug. Can you make sure that 
makes it into the next release? There is also support for the 
DiveComputer.eu dive computer. Would be nice to have that included as 
well. They are very eager to see support for their dive computer in 
subsurface :-)


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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Jef Driesen]

On 11-06-18 20:21, Anton Lundin wrote:

On 04 June, 2018 - Dirk Hohndel wrote:


I don't have an outstanding patch from you, so not sure what you are referring 
to.


There was a diff a while back in this thread, in
20180523144751.gc12...@hirohito.acc.umu.se , which made the code fall
back to the voted/averaged ppo2 instead of reporting individual sensors
if we couldn't find sane calibration values.


Jef didn't like it, but I think its a step to a better place than where
we're right now, and as far as I've read it, both Davide and Martin who
is affected agrees.


Anyway, now when I'm back on solid ground (I still feel the waves in my
legs) I might get around to making up a commit message and formating it
as a patch.


It's not that I really disliked the patch. I just wanted to point out that it 
introduces a possible disambiguity in the sense that in the application you no 
longer know which type of ppo2 you are getting (voted or sensor). I would rather 
go for a solution that indicates the type. That's exactly what's on my (long) 
todo list.


But I'm fine with your patch as an interim solution as well. Btw, an alternative 
could be to always deliver both the voted *and* the sensor ppO2. Then you know 
for sure that the first value is always the voted value, and the remaining ones 
(if present) are the sensor ones.


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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Jef Driesen]

On 25-05-18 16:35, Willem Ferguson wrote:

On 25/05/2018 15:55, Jef Driesen wrote:

The main disadvantage is that you'll no longer know which type of ppO2
(sensor or voted/average) you are getting. Especially if you only have
one sensor.


I would agree, but at least one gets the calculated pO2 as perceived by
the machine at the time, even though there is no idea about sensor
problems during the dive. It is so much better than having no pO2 data
to evaluate after a dive. This pO2  would still correspond to the data
in the pO2 graph of the Shearwater Desktop software.

I do not quite get the argument about one sensor? For one sensor there
is no averaging or voting?? I'm not seeing something, so please spell it
out?


The average ppO2 is always a single value. But there is often more than one 
sensor. So you could assume that if you get more than one ppO2 value that they 
are values from a sensor. But in the case of a single sensor, that doesn't work, 
and you won't be able to tell which value you got.


I'm not sure if the average ppO2 is always equal to the sensor ppO2 for the 
single sensor case. Maybe the dive computer does averaging over several 
measurements to ignore outliers? (Is simply don't know.)


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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Jef Driesen]

On 2018-05-23 16:47, Anton Lundin wrote:

On 23 May, 2018 - Anton Lundin wrote:
The simple solution is to just emit the average/voted ppO2 when we 
can't

find the calibration values.

Its a graceful degradation of functionality, and way better than not
showing any ppO2 at all.

It should be simple to write.


Something simple like:

diff --git i/src/shearwater_predator_parser.c 
w/src/shearwater_predator_parser.c

index dda042c..e5194e8 100644
--- i/src/shearwater_predator_parser.c
+++ w/src/shearwater_predator_parser.c
@@ -669,19 +669,19 @@ shearwater_predator_parser_samples_foreach
(dc_parser_t *abstract, dc_sample_cal
if ((status & OC) == 0) {
// PPO2
if ((status & PPO2_EXTERNAL) == 0) {
-#ifdef SENSOR_AVERAGE
-   sample.ppo2 = data[offset + 6] / 100.0;
-   if (callback) callback
(DC_SAMPLE_PPO2, sample, userdata);
-#else
-   sample.ppo2 = data[offset + 12] *
parser->calibration[0];
-   if (callback && (parser->calibrated &
0x01)) callback (DC_SAMPLE_PPO2, sample, userdata);
-
-   sample.ppo2 = data[offset + 14] *
parser->calibration[1];
-   if (callback && (parser->calibrated &
0x02)) callback (DC_SAMPLE_PPO2, sample, userdata);
-
-   sample.ppo2 = data[offset + 15] *
parser->calibration[2];
-   if (callback && (parser->calibrated &
0x04)) callback (DC_SAMPLE_PPO2, sample, userdata);
-#endif
+   if (!parser->calibrated & 0x07) {
+   sample.ppo2 = data[offset + 6] 
/ 100.0;

+   if (callback) callback
(DC_SAMPLE_PPO2, sample, userdata);
+   } else {
+   sample.ppo2 = data[offset +
12] * parser->calibration[0];
+   if (callback &&
(parser->calibrated & 0x01)) callback (DC_SAMPLE_PPO2, sample,
userdata);
+
+   sample.ppo2 = data[offset +
14] * parser->calibration[1];
+   if (callback &&
(parser->calibrated & 0x02)) callback (DC_SAMPLE_PPO2, sample,
userdata);
+
+   sample.ppo2 = data[offset +
15] * parser->calibration[2];
+   if (callback &&
(parser->calibrated & 0x04)) callback (DC_SAMPLE_PPO2, sample,
userdata);
+   }
}

// Setpoint

Should be enough.


The main disadvantage is that you'll no longer know which type of ppO2 
(sensor or voted/average) you are getting. Especially if you only have 
one sensor.


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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Jef Driesen]

On 2018-05-23 14:58, Davide DB wrote:
On Wed, May 23, 2018, 12:08 Willem Ferguson 
<willemfergu...@zoology.up.ac.za>

wrote:

If this is the case, then the problem should in principle be solvable
and it possibly means that the coding in the dive log is slightly
different from that of the standard Petrel and the Fischer Petrel 2. 
The

most knowledgeable person to approach is Jef Driesen but he would need
some specific information from your download. A first approach is to
inspect the .bin dumpfile generated for debug in Subsurface. Then use
his dctool executable (If I remember correctly it can do Bluetooth and
it is extremely flexible) and see if you can trace the pO2 values.

I am not sure this is what you may want to hear, but assume that (if 
you

want the problem solved) you need to take the initiative. You may
possibly be the only person in this circle which has a divecan Petrel 
so

you are in the best position to address the problem.



While I do not pretend anything (of course), regarding your questions I 
can

assure you that I made everything I could as end user. I gave
- Shearwater desktop screenshots
- Shearwater xml exported logs
- Subsurface xml logs
- Subsurface bin dumps
- dctool dump files

My only fault was not filing a bug report on Github to resume 
everything in

one place.
I even asked on the list if someone else was using a Shearwater Petrel 
ECCR
controller and, maybe experiencing the same behavior. No reply. So I 
don't

know if it's my specific unit or not.
BTW I recently updated Petrel firmware to the latest version without
results. While it's possible I'm the only Shearwater ccr user on this 
list,
we are speaking of the most common eccr controller on the market 
nowadays.

It's used on countless rebreathers not an obscure dive computer
implementation.

Everything started months ago when I discovered that pO2 samples 
reported
by Subsurface were completely different (and wrong) from Shearwater 
desktop.

There was a long email thread in which AFAIK no solution was found: my
Petrel is strange.
Maybe I missed something and Jef or Anton modified something. I don't 
know
but at some point pO2 samples disappeared from Subsurface hence I 
opened
this thread but I'm failing to understand what "default calibration" 
means
and why in my logbook I find the same device listed with random number 
of

sensors.
I asked again today because because even a "guy you must die!" reply  
it's

ok but I got no replies at all.


Sorry for the lack of response, but for the last few weeks, I was just 
too busy with non-libdivecomputer related things.


Anyway, the problem is as follows. The shearwater devices record two 
different things:


   1. The average/voted ppO2.

   2. The value from each O2 sensor. Unfortunately this value is not the 
ppO2 value, but the raw millivolt measurement from the sensor. In order 
to convert this value to a ppO2 value, we need to take into account the 
calibration values.


Last time I checked, shearwater desktop only shows the average/voted 
ppO2 (#1). It doesn't show the individual ppO2 from each sensor (#2) at 
all (e.g. no millivolt values nor the converted ppO2).


Now, originally libdivecomputer only reported the average/vote ppO2. 
Later on we figured out how the sensor calibration worked, and this was 
replaced with the ppO2 value from the individual sensors. But afterwards 
we also discovered that some devices (like the one from Davide) don't 
seem to store the calibration values correctly, and leave them at their 
default values (2100). I have no idea why this happens. Anyway, because 
applying those calibration values produces incorrect ppO2 values, I 
added some code to detect this case and disable the ppO2 from the 
sensors. Since the average/voted ppO2 was already disabled earlier, that 
also means you won't get any ppO2 values at all anymore.


For those bogus default calibration values, there is not much we can do 
about that. Without the (correct) calibration values, we simply can't 
calculate the ppO2 values. So unless the calibration values are for some 
reason stored elsewhere, and we just don't know about this, we're simply 
stuck here. Shearwater desktop doesn't show this info, so it's difficult 
to tell what's going on.


The only part that we can do something about, is restoring the 
average/voted ppO2 again. That's already on my todo list. But right now 
the libdivecomputer api doesn't have a way to indicate the type of the 
ppO2 value (e.g. average/voted or from an individual sensor), so that 
would cause confusing. So this will require some (backwards 
incompatible) changes, and that's why it's not done yet.


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

Re: Any brave dive computer download testers out there?

[Jef Driesen]

On 2018-04-23 19:07, Linus Torvalds wrote:

On Mon, Apr 23, 2018 at 12:56 AM, Sébastien Dugué
 wrote:

On Sun, Apr 22, 2018 at 10:09 PM, Linus Torvalds
 wrote:


It still has the exact same problem it always had: it's random binary 
data

that we'd have to encode some way.


  Well, it's not so random. It's in fact a timestamp in the DC format 
which

specifies from which dive we wish to download.


I wish that was the case. It's not.

It's a timestamp on _some_ dive computers. On others, it's other random 
data.


On most dive computers, it's 4 bytes, on others it's 5-6, and on some
it's 16 bytes of random binary data.

On many dive computers it's entirely pointless (yes, yes, you may be
able to avoid downloading that one last dive), but they still have a
fingerprint, and there's no way to know "don't bother".

So to really get it right and download the least amount of dives you 
have to:


 - encode this insane random binary data without knowing what it is

 - also encode the insane garbage "serial number" (that isn't actually
a valid serial number at all, and hasn't even been stable across
libdivecomputer versions)

 - then before downloading, match the garbage serial number and
vendor/device string to find the last dive with that dive computer, in
order to find the other garbage random binary data

honestly, it's nasty nasty nasty.

What we *could* do is to do it knowingly wrong, the way dctool does
it: don't save the fingerprint data with the real dive data at all,
just have a random "last download" cache indexed by device family and
serial number.

That's how the feature is designed to be used, and it would avoid the
nasty "pollute our logs with meaningless and badly defined crazy data
that will never be useful in the future".

"So why don't you do that, then?" I hear you say.

It's probably the best approach, and works fine if you just always
download from the same device (because the cache would be specific to
the installation, not be part of our dive data). And when it doesn't
work, arguably we wouldn't be in any worse condition that we already
are in (ie "download everything" from the devices that can't download
dives one by one), so why not?

The "why not" is because it makes re-downloading dives much nastier.
If you actually want to re-download dives (maybe because you didn't
save the dives after the last download due to some other problem?) you
now need a way to clear the cache data. And the "download all dives"
thing could do that, but then  you wouldn't have the existing "don't
duplicate dives" that we *currently* have.

But it also means that when you download from the same dive computer
on a different device (ie your phone vs your laptop), you'll get get
potentiall ydifferent results. It can be very confusing.

So it's a hack, but it might be acceptable. As long as I don't have to
save that stupid fingerprint - and that broken serial number that
isn't - in the logs, I'm certainly happier with it.


The fingerprint usually contains the raw date/time data, but it depends 
on the dive computer. Why should the application need to know what's 
inside? It only needs to store the data somewhere until the next 
download.


Using something less arbitrary for the fingerprint data, like a hash 
over the dive data or even the date/time of the dive, doesn't work. 
There are several reasons for that:


1. As explained before, the Uwatec/Scubapro protocol requires sending 
the timestamp to the dive computer. That already rules out the use of a 
hash, because we can't retrieve the timestamp back from the hash. Even 
using the date/time is tricky here, because this timestamp should be 
relative to the device clock, not the host clock. Since some of those 
devices rely on the host clock for parsing the date/time, that means you 
would have to store those values as well. Using the raw dive timestamp 
as the fingerprint doesn't have those problems.


2. Many dive computer protocols support downloading some kind of index 
with a summary of the available dives. That allows libdivecomputer to 
check the fingerprint and decide which dives need to be downloaded 
before actually downloading the dive. That's not only a bit more 
efficient, but it also allows to deliver much more accurate progress 
events. That improves the user experience. So this is not only about 
being a little bit faster. But this is only possible if libdivecomputer 
can use whatever information is available in the index that can uniquely 
identify a single dive, and that's of course different for each 
protocol. Hence the need to use arbitrary data.


So even if you don't really care about this last argument, then how 
would you handle the first one?



The only alternative solution that I can think of is to replace the 
fingerprint with the raw dive data itself. That way, the feature would 
still work exactly the same as before, but with the entire dive as the 
fingerprint. 

Re: Any brave dive computer download testers out there?

[Jef Driesen]

On 2018-04-25 22:12, Linus Torvalds wrote:
On Wed, Apr 25, 2018 at 11:51 AM, Dirk Hohndel  
wrote:


I have a Petrel (single stack BT) and Petrel 2 (dual stack) and will 
test
those over lunch today. I'll try to test Mac and Android 
(embarrassingly,

I currently don't have a Linux laptop with working BLE...)


Note that the magic channel/port number thing is Linux 
desktop-specific:


  #if defined(Q_OS_LINUX) && !defined(Q_OS_ANDROID)

And it was literally the Petrel 2 that triggered that "try channel 5".

I have no idea how that is supposed to work, or what the crazy rules
about rfcomm ports even -are-. I'm just looking at the code, and going
"eww".

Also note that on Linux and Windows, we could just use the
libdivecomputer bluetooth backend that just uses the raw socket.

Also, Jef just uses port 0 for everything.

So the whole "port/channel" thing may be entirely pointless.


In the libdivecomputer rfcomm implementation, port 0 means 
auto-detection. On linux it does an SDP discovery internally to find the 
correct rfcomm port number, and on Windows it uses the rfcomm uuid 
instead of the port number. That way, it should always just work. And on 
the hardware I tested, it does indeed.


I also don't know the exact details on how these port numbers are 
assigned. I guess it depends on the dive computer firmware and/or its 
bluetooth stack. The valid range for rfcomm ports is 1-30 if I remember 
correctly.


The Petrel is certainly not the only one which is using a different port 
number. I'm currently testing the divecomputer.eu and it seems to use 
port 6.


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

Re: question about declared transports

[Jef Driesen]

On 2018-04-20 20:25, Linus Torvalds wrote:
On Thu, Apr 19, 2018 at 4:29 AM, Jef Driesen <j...@libdivecomputer.org> 
wrote:

On 2018-04-19 12:10, Dirk Hohndel wrote:


To the best of my knowledge, no version of the Predator / Petrel / 
Nerd
family has a wired serial interface, all they do is BT or BLE (I 
actually

checked the website to make sure).


You forgot about the serial port emulation feature of classic 
bluetooth

(rfcomm). Basically any devices that supports bluetooth classic
(DC_TRANSPORT_BLUETOOTH) can also use the serial port emulation mode
(DC_TRANSPORT_SERIAL). This remains supported, and that's why they are
listed both.


I think this would be better left to the user of the library.

*ANY* dive computer that does rfcomm is probably able to just say
"open as serial line to /dev/rfcomm*".

So by that logic, if  a dive computer supports DC_TRANSPORT_BLUETOOTH,
then it always supports DC_TRANSPORT_SERIAL.


Correct, and that's also why they are both listed explicitly.


And the thing is, it's actually actively incorrect. The /dev/rfcomm
model only exists on Linux, afaik. So now that DC_TRANSPORT_SERIAL is
actively wrong on other platforms, like Windows, iOS and OS X.


You are wrong about that. This is certainly not a Linux only feature. 
Windows and OS X also support it, and I think the BSD's too. So 
basically it's supported by all desktop OS'es. In fact, before the I/O 
refactoring, this serial emulation was the only way to communicate with 
bluetooth enabled dive computers!


I suspect the reason behind the existence of this feature is backwards 
compatibility. Applications that did already support serial 
communication, can easily migrate to bluetooth because the underlying 
api remained the same. For the mobile platforms this does not apply, and 
hence they also don't provide the legacy serial emulation support.



In fact, while Android is Linux too, it doesn't do the whole "rfcomm
bind" thing, so it's wrong there too.

Let's say that you have a platform that supports real serial lines,
but doesn't support legacy bluetooth, now  that DC_TRANSPORT_SERIAL is
actively  wrong.

So adding that DC_TRANSPORT_SERIAL doesn't actually buy you anything,
but it does make it harder for the actual users.

I think it would be better for us to remove the thing, or perhaps at
least make it more accurate by making the serial bit depend on the
platform being Linux.

We could also do that automatically in subsurface instead. And then we
could make it actually depend on finding a /dev/rfcomm* device.


The dc_descriptor_get_transports() function tells you which transports 
the dive computer supports, and not underlying platform! That are two 
completely independent things. If you have a platform that doesn't 
support a certain transport, then it's up to the application to ignore 
that bit. That's why there is the new dc_context_get_transports() 
function, to tell you which (built-in) transports are available on the 
platform. The intersection of both tells you which transport(s) are 
usable.



I guess we could also do a dc_serial_iterator thing to see if we find
any serial devices at all, but sadly, that isn't really all that
useful. That  does't actually limit the devices searched for, and
generally you'll have at least the hardcoded /dev/ttyS* devices
available on Linux whether anything is connected or not. So that will
always report serial devices as available, even if they aren't useful
(and particularly not useful for a rfcomm connection).

Maybe dc_descriptor_get_transports() could do something like

unsigned int
dc_descriptor_get_transports (dc_descriptor_t *descriptor)
{
unsigned int transports = DC_TRANSPORT_NONE;
DC_TRANSPORT_NONE
if (descriptor) {
transports = descriptor->transports;
if ((transports & DC_TRANSPORT_BLUETOOTH) &&
devfnmatch("rfcomm*"))
   transports |= DC_TRANSPORT_SERIAL;
}
return transports;
}

where that "devfnmatch()" obviously does the whole
"opendir("/dev")+readdir+fnmatch" loop that dc_serial_iterator_next()
already does, but limited to just rfcomm.

Then DC_TRANSPORT_SERIAL would only show up if you have actually done
that rfcomm binding that makes it possible..


What you describe here, can already be done with a filter function. With 
such a function you can easily let the dc_serial_iterator_next() filter 
out entries that don't match a certain pattern.


The only reason why I didn't commit those patches yet, is because on 
Windows both rfcomm and (usb-)serial ports are named COMx. It might be 
possible to get the type of the serial port somehow. And on Mac OS X, 
I'm also not sure whether there is a standard pattern or not.


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

Re: Any brave dive computer download testers out there?

[Jef Driesen]

On 2018-04-20 04:56, Matt Thompson wrote:
My Atomic Cobalt2 worked on Windows and macOS but failed on Linux.  I 
think

the failure on Linux is a configuration issue on my part but for
completeness I get the following in the console:
ERROR: Failed to open the usb device. [in 
../../src/atomics_cobalt.c:117

(atomics_cobalt_device_open)]
INFO: dc_deveice_open error value of -6
I get that error on both 
Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage

and Subsurface-4.7.8-x86_64.AppImage.


This looks like a permission error. Have you installed the necessary 
udev rules?


Download this file:

https://raw.githubusercontent.com/libdivecomputer/libdivecomputer/master/contrib/udev/libdivecomputer.rules

and copy it to /etc/udev/rules.d/ directory.

(This assumes you are in the plugdev group.)

My Suunto D4i failed on all three platforms.  It gave various errors on 
the

platforms:
Windows 10:
 the red banner at the bottom of the main window with the message
"Unsupported operation"


Difficult to tell without further info. Did you install the USB driver?

Fedora: A message box  with the message "Unable to open /dev/ttyUSB0" 
and a

message on the console "ERROR: Failed to receive the answer. [in
../../src/suunto_d9.c:253 (suunto_d9_device_packet)]


Looks again like a permission error. Make sure you're in the dialout 
group:


sudo usermod -a -G dialout $USER

(You'll have to logout and login again before this takes effect.)


macOS: A message box with the message "Error downloading dive data"


No idea.

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

Re: Any brave dive computer download testers out there?

[Jef Driesen]

On 22-04-18 18:37, Linus Torvalds wrote:

On Sun, Apr 22, 2018 at 3:52 AM, Jérémie Guichard  wrote:


I just tried Scubapro G2 over bluetooth on Android build and it did not
work, but I must say this was already the case on Android for the normal
release.


Hmm. I just tried my G2 over USB, and that worked fine.

But bluetooth connects and starts downloading the data fine, but then
it doesn't import:

 Dive data import error dives downloaded 0

but I did get one "Failed to receive the packet" error. The BLE packet
handling is a _lot_ less reliable than serial is.

Hmm. I tried again, and it worked and downloaded all 78 dives on my G2.

So the bluetooth case works (at least on Linux desktop), it's just:

  (a) really really damn slow, and you can't interrupt it in the middle
because it doesn't download one dive at a time

  (b) fragile and does bad things if you get any BLE errors.

and that makes it less than wonderful (to the point of maybe being useless).

Jef, even when I already have all dives, the G2 download will
apparently just download the whole memory dump and then parse later.
That _really_ doesn't work very well. Is there no way to download one
dive at a time?


No, the protocol doesn't support that. But it does support downloading only the 
new dives. Unfortunately, the only way to take advantage of that is by means of 
the libdivecomputer fingerprint feature.


This is actually one of those cases where trying to implement the download only 
new dives feature entirely on the application side (without using the 
fingerprint feature) will always be inefficient. That's because the protocol 
works a bit different here. Unlike most other dive computers, it's the dive 
computer that does the work. You need to send a timestamp (of the most recent 
previously download dive) to the dive computer, and then the dive computer will 
only send back the newer dives.


The result is that if you don't use the fingerprint feature, then you will 
always request ALL dives And once you have all dives, you can ignore the ones 
you already had. But at that point you have already downloaded them all.


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

Re: Any brave dive computer download testers out there?

[Jef Driesen]

It looks like some data got transferred succesfully. But then the logging 
stops. Can you send the libdivecomputer logfile? That should give some more 
info. (I'm not sure whether android app supports saving libdc log.)

Jef

On April 22, 2018 12:52:48 PM GMT+02:00, "Jérémie Guichard" 
 wrote:
>Hi guys,
>
>I just tried Scubapro G2 over bluetooth on Android build and it did not
>work, but I must say this was already the case on Android for the
>normal
>release.
>This use case was working few month ago but cannot remember the version
>it
>was.
>
>I'm not sure it actually helps but I attached the log file.
>
>Jeremie
>
>
>
>2018-04-20 23:10 GMT+07:00 Murillo Bernardes :
>
>> Successfully downloaded dives on a Mac from:
>> - Oceanic OCi over USB
>> - Perdix AI over BLE
>>
>> Murillo Bernardes
>>
>> On Fri, Apr 20, 2018 at 1:05 PM, Jérémie Guichard
>
>> wrote:
>>
>>> Hey guys,
>>>
>>> Just tried this build on Windows 10: https://github.com/Subsurf
>>> ace-divelog/subsurface/releases/download/continuous-NG/
>>> subsurface-4.7.8-73-ga12ea13d51f5.exe
>>>
>>> With Scubapro G2 and Suunto Zoop over USB. Seems to work like a
>charm.
>>>
>>> Jeremie
>>>
>>> 2018-04-20 9:56 GMT+07:00 Matt Thompson :
>>>


 On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel 
>wrote:

>
> We now have binaries for Windows, Mac, and Linux (AppImage only)
> available in order for people to test this.
>
> https://github.com/Subsurface-divelog/subsurface/releases/ta
> g/continuous-NG
>
>
> I tested all three of my computers on Windows 10, macOS 10.13.4,
>and
 Fedora 27.

 My Aqualung i750TC worked correctly on all three platforms using
>the USB
 cable.

 My Atomic Cobalt2 worked on Windows and macOS but failed on Linux. 
>I
 think the failure on Linux is a configuration issue on my part but
>for
 completeness I get the following in the console:
 ERROR: Failed to open the usb device. [in
>../../src/atomics_cobalt.c:117
 (atomics_cobalt_device_open)]
 INFO: dc_deveice_open error value of -6
 I get that error on both
>Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
 and Subsurface-4.7.8-x86_64.AppImage.

 My Suunto D4i failed on all three platforms.  It gave various
>errors on
 the platforms:
 Windows 10:
  the red banner at the bottom of the main window with the message
 "Unsupported operation"

 Fedora: A message box  with the message "Unable to open
>/dev/ttyUSB0"
 and a message on the console "ERROR: Failed to receive the answer.
>[in
 ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]

 macOS: A message box with the message "Error downloading dive data"



 ___
 subsurface mailing list
 subsurface@subsurface-divelog.org

>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


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

Critical bug in OSTC3 backend discovered

[Jef Driesen]

Hi,

I just fixed a nasty bug in the ostc3 backend that was introduced with 
the BLE support (commit 0978f8c0fa70710bad3fb865ffe3a20961c408dc). 
Ironically everything works fine when using BLE, but not for bluetooth 
classic or its serial emulation.


Please upgrade asap, because this bug not only causes the download to 
fail, but it also appears to change random settings on the dive 
computer!


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

Re: question about declared transports

[Jef Driesen]

On 2018-04-19 12:10, Dirk Hohndel wrote:

I have a question about the meaning of the transport flags.
My understanding was that DC_TRANSPORT_SERIAL is an indication that the
dive computer supports some form of wired serial interface (Rs232 or 
more

typically serial over USB). What I don't understand in this context is
this:

/* Shearwater Predator */
{"Shearwater", "Predator", DC_FAMILY_SHEARWATER_PREDATOR, 2,
DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH, dc_filter_shearwater},
/* Shearwater Petrel */
{"Shearwater", "Petrel",DC_FAMILY_SHEARWATER_PETREL, 3,
DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH, dc_filter_shearwater},
{"Shearwater", "Petrel 2",  DC_FAMILY_SHEARWATER_PETREL, 3,
DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH | DC_TRANSPORT_BLE,
dc_filter_shearwater},
{"Shearwater", "Nerd",  DC_FAMILY_SHEARWATER_PETREL, 4,
DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH, dc_filter_shearwater},
{"Shearwater", "Perdix",DC_FAMILY_SHEARWATER_PETREL, 5,
DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH | DC_TRANSPORT_BLE,
dc_filter_shearwater},
{"Shearwater", "Perdix AI", DC_FAMILY_SHEARWATER_PETREL, 6,
DC_TRANSPORT_BLE, dc_filter_shearwater},
{"Shearwater", "Nerd 2",DC_FAMILY_SHEARWATER_PETREL, 7,
DC_TRANSPORT_BLE, dc_filter_shearwater},

To the best of my knowledge, no version of the Predator / Petrel / Nerd
family has a wired serial interface, all they do is BT or BLE (I 
actually

checked the website to make sure).

What am I missing?


You forgot about the serial port emulation feature of classic bluetooth 
(rfcomm). Basically any devices that supports bluetooth classic 
(DC_TRANSPORT_BLUETOOTH) can also use the serial port emulation mode 
(DC_TRANSPORT_SERIAL). This remains supported, and that's why they are 
listed both.


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

Re: Any brave dive computer download testers out there?

[Jef Driesen]

On 2018-04-19 09:42, Sébastien Dugué wrote:

On Thu, Apr 19, 2018 at 1:50 AM, Linus Torvalds
 wrote:

On Wed, Apr 18, 2018 at 4:18 PM, Linus Torvalds
 wrote:


Hmm. Which IRDA chip is it that is in the Uwatec dongle?

Is it perhaps the MosChip MCS7780? You'd know, because then it would
be using USB ID 9710:7780. That seems to be the common case.


Hmm. Googling around, I see that it might also be the Sigmatel
Stir4200 (USB ID 066F:4210).

That actually has better documentation, and shows exactly the framing
for the normal MIR format (which it would be for the normal 9600
baud). I suspect the MCS7780 needs that same format, it's just not
documented as well.

The packet wrapping looks like this:

0x55 0xaa 2-byte LE length, 0xC0*n  .. escaped data .. 2-byte LE 
CRC 0xc1


and from what I can tell, the Stir4200 also resets to sane default
values (9600 baud SIR).

But you may have to do some USB control transfers to set the data
direction. It *looks* like the MCS7780 is simpler and defaults to just
"automatic data direction" (which presumably just means "send if there
is TX data, receive otherwise").


  Yes, but to me talking to the chip is the easy part. I'm more 
concerned

about implementing enough of the irda protocol stack to be able to talk
to all those embedded stacks.


I discovered this a while ago:

https://github.com/Diveboard/DC-agent/tree/master/3d-party/irda_mac

It seems to be based on some minimal IrDA stack for micro-controllers:

http://web.archive.org/web/20061124205138/www.blaulogic.com/pico_irda.shtml

This is probably a good starting point!

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

Re: this looks suspiciously easy

[Jef Driesen]

On 2018-04-19 08:40, Dirk Hohndel wrote:

On Wed, Apr 18, 2018 at 11:37:53PM -0700, Dirk Hohndel wrote:

On Thu, Apr 19, 2018 at 08:13:23AM +0200, Jef Driesen wrote:
>
> You can also get the mask with the built-in transports from libdivecomputer
> with the dc_context_get_transports() function. With the above, you'll for
> example show usb or usbhid devices even when libdivecomputer was build
> without usb or usbhid support.
>
> For transports where subsurface uses a custom I/O implementation (bluetooth
> and ble), you of course need to set the bits as above.

Cool - that's even better.
Of course I first wondered... darn, where do I get the context from in
this part of my code. Then I looked at the sources of 
libdivecomputer...


unsigned int
dc_context_get_transports (dc_context_t *context)
{
UNUSED(context);

return DC_TRANSPORT_SERIAL
#if defined(HAVE_LIBUSB)
| DC_TRANSPORT_USB
#endif
...

OK, I guess I'll just pass in a NULL pointer :-)


That should be fine. I only added the context pointer in case we ever 
need it in the future. I doubt that will ever be necessary, but it was 
easier to add now then having to change it later.


... and of course... since it ALWAYS adds in the 
DC_TRANSPORT_SERIAL
flag, I guess I have to mask that back out on iOS where we don't 
actually

have support for serial dive computers...


Yeah, that's indeed an annoying special case. The code builds just fine 
and probably works too, but without any usb-serial drivers (or even the 
ability to connect those devices) you can't really do much with it.


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

Re: this looks suspiciously easy

[Jef Driesen]

On 2018-04-19 06:25, Dirk Hohndel wrote:

@@ -123,10 +109,31 @@ void fill_computer_list()
dc_iterator_t *iterator = NULL;
dc_descriptor_t *descriptor = NULL;

+   int transportMask = 0;
+#if defined(BT_SUPPORT)
+   transportMask |= DC_TRANSPORT_BLUETOOTH;
+#endif
+#if defined(BLE_SUPPORT)
+   transportMask |= DC_TRANSPORT_BLE;
+#endif
+#if !defined(Q_OS_ANDROID) && !defined(Q_OS_IOS) && !defined(Q_OS_MAC)
+   transportMask |= DC_TRANSPORT_IRDA;
+#endif
+#if !defined(Q_OS_IOS)
+   transportMask |= DC_TRANSPORT_USB | DC_TRANSPORT_USBHID;
+#endif
+#if !defined(Q_OS_ANDROID) && !defined(Q_OS_IOS)
+   transportMask |= DC_TRANSPORT_SERIAL;
+#endif
+


You can also get the mask with the built-in transports from 
libdivecomputer with the dc_context_get_transports() function. With the 
above, you'll for example show usb or usbhid devices even when 
libdivecomputer was build without usb or usbhid support.


For transports where subsurface uses a custom I/O implementation 
(bluetooth and ble), you of course need to set the bits as above.


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

Re: Mares Quad with BLE Interface

[Jef Driesen]

On 2018-04-12 20:57, Linus Torvalds wrote:
On Thu, Apr 12, 2018 at 10:52 AM, Allen Hall  
wrote:
BLE communications log is attached.  I may be able to tease out more 
verbose

info if needed, but this looks pretty complete to me.


This looks like it does contain all the information. I won't have time
to look at it until next week, but maybe Jef will.

The one question I have, is what the iOS encoding is for the data. The
logs show the actual data transfers as strings like this:

   "value":"BQAdAGgfAwBIAO8="

and I'm *guessing* that is just a base64 encoding, but it would be
good to validate in case somebody knows the iphone logging model..

If it's base64-encoded, then it decodes to 20 bytes :

   000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
   020 00 00 00 ef

and this all should be possible to figure out.

In fact, I wrote a really stupid script to turn that into something
slightly more legible:

zcat < mares_bluelink_pro_ble.log.gz |
grep '"value"' |
sed 's/^.*{/{/' |
while IFS=, read a b c d e f g h
do
val=$(echo "$d" | sed 's/"value"://' | tr -d '"')
echo "$c $e:"
echo $val | base64 -d | od -t x1
done | less -S

and it superficially looks like it's the standard Mares Icon HD
protocol to me. I see one-byte 'aa' responses (which is just the ACK
character). And I see sequences like this:

"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" 
"status":"written":

000 e7 42
002
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 aa
001
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" 
"status":"written":

000 78 ad 00 00 04 00 00 00
010
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 78 13 00 00 ea
005
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" 
"status":"written":

000 e7 42
002
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 aa
001
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" 
"status":"written":

000 1c ad 00 00 5c 00 00 00
010
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 f0 00 a3 01 79 00 02 00 14 00 0e 00 00 00 74 00
020 40 95 00 00
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 1e 00 78 05 20 80 78 05 32 80 78
013
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
020 00 00 00 ef
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef
020 18 ef 18 f7
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 00 0d 01 cc 00 fa 00 00 00 00 00 00 00 00 00 00
020 00 00 00 00
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 00 ea
002

where that "e7 42" is "device read", it gets "aa" back, then we send
eight bytes of data (address and length, little-endian 4-byte each),
then we get the data followed by "ea".

(The "status":"written" is the phone sending, the
"status":"subscribedResult" is the dive computer answering).

That all looks exactly like the Icon HD serial protocol.

Jef, any additional comments?

Anyway, I suspect it all might just automatically work if we just add
the Mares to the list of bluetooth targets. The BLE GATT layout looks
like the normal "hacky serial over GATT" and might even match what we
already try to do.


I haven't looked at the logfile in detail, but based on your description 
it looks indeed like the standard iconhd protocol. That's also what I 
expected: same protocol but send over BLE instead of usb-serial.


The base64 encoding is probably done by the iOS logger. I see absolutely 
no reason to use base64 encoding over ble. It's perfectly possible to 
send binary data over ble, and the large base64 overhead (about 33%) 
would only make the relative slow ble even slower.


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

Re: Bluetooth fails on mobile

[Jef Driesen]

On 2018-04-10 16:42, Davide DB wrote:

On 10 April 2018 at 16:10, Willem Ferguson
 wrote:


On a Samsung S6 (Android 7.0)  the phone sees my Petrel 2 and pairs to 
it.

However, when downloading dives, the phone only sees a BTLE device and
apparently cannot handle the BTLE mode (error 133). Have no idea why 
it

doesn't  also see an ordinary BT device. Therefore no downloads.


Yes but how to save partial downloads?
If my Petrel has 100 dives on it and I miss just the last three of
them on my logbook why I have to download 100 dives.


Recovering from a partial download is tricky!

To be able to download only the new dives (which is the most common 
use-case), libdivecomputer downloads the dives in reverse order (e.g. 
newest first). Thus after a partial download, you have the newest dives, 
but not the oldest dives. But if you try to download again, in an 
attempt to get those old dives as well, there are two problems:


(1) When the download only new dives logic sees the newest dive again, 
it will abort the download. So you need to disable it and force it to 
download all dives.


(2) There is no way to skip dives you already have. So you'll be 
downloading those dives again before reaching the old dives you're 
interested in. This is inefficient, but the worse part is that if you 
encounter again an error before reaching those old dives, then you're 
still stuck. If the error is due to some unreliable connection, then you 
may need many attempts, which is of course very annoying.



Note that subsurface also has another related problem. When there is an 
error during the parsing of a dive, the download is aborted. And thus 
you won't be able to download any of the older dives before the 
problematic dive!


Even the plain libdivecomputer utility has a lot of problem downloading 
them.


Have you already tried with the new bluetooth transport? The native 
bluetooth transport appears to be a lot more reliable than the serial 
port emulation. I'm not sure what is going on, but it's certainly not 
something specific to the Shearwater dive computers, because I've seen 
similar reports with other brands.


You can download a pre-build binary here:

https://libdivecomputer.org/builds/stable/windows/dctool.exe

Instead of specifying the name of the virtual serial port, you pass the 
bluetooth mac address, along with the '-t bluetooth' option to enable 
the bluetooth transport:


dctool -v -l petrel.log -f petrel download -o petrel.xml -t bluetooth 
00:11:22:33:44:55


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

Re: Mares Quad with BLE Interface

[Jef Driesen]

On 2018-04-10 18:44, Linus Torvalds wrote:

On Tue, Apr 10, 2018 at 9:26 AM, Dirk Hohndel  wrote:

What's our best bet to create a process to do this?
Ask people to send their dive computers to Linus? Tempting, but maybe
not as scalable as one might hope.


Yeah. Especially since I wouldn't be very motivated by most dive
computers. I've not been all that excited about the Mares ones I've
seen: the Icon HD is ok, but I had issues with the screen.


In this case, the easiest option is probably to contact Mares, and ask 
them for the info we need. They have supported us in the past, and I 
assume that hasn't changed.


I'll send them an email.

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

Re: Accessing Petrel downloads and events

[Jef Driesen]

On 2018-02-28 11:52, Willem Ferguson wrote:

1) In both CCR mode as well as SCR mode, the Petrel 2 allows switching
between OC bailout gases and CC gases. This done by performing
selecting either  BO->SC  or  SC->BO from the Shearwater menu. These
events must be recorded in the dive log but are presently not easily
accessible, at least from within Subsurface. How does libdivecomputer
see the events? Is there any way to acces them from Subsurface?


There is an OC/CC bit in every sample. It's currently only used for 
enabling/disabling the ppO2 and setpoint samples. But the value itself 
(or a change of the value) is not reported.



2) Shown below is the Subsurface log trying to download a Petrel 2
dive into a dump for better analysis. However, every time I try this,
the download aborts. With the "Save dumpfile" and Save logfile:
options NOT checked, the download goes flawlessly.


The Petrel protocol doesn't support downloading memory dumps.

(1) Download a memory dump using the older predator protocol. This 
protocol supports memory dumps, but the drawback is that not all 
information will be downloaded this way. Only the most recent dives are 
accessible and even the dives that can be downloaded have some 
information removed. (The Petrel sample size is twice as large as the 
Predator samples, so some info gets dropped when using the older 
protocol.)


(2) Dump the raw data of the individual dives. Unfortunately Subsurface 
doesn't support this and you'll need to use libdivecomputer's dctool 
command-line application:


dctool -vv -l petrel.log -f petrel download -o dive.%n.bin -f raw 



Or as an alternative, only enable the libdivecomputer logfile checkbox 
(but NOT the dumpfile checkbox). I can extract the raw data from the 
logfile.



One thing to notice is the warning below:

WARNING: Disabled all O2 sensors due to a default calibration value.

This is despite explicit calibration before the dive. This is similar
to your issue with my Predator download, previously discussed.
Unfortunately the Predator is in the UK at present, so I could not do
an analogous download from that dive computer.


This warning means that all O2 sensors are marked as being calibrated in 
the data, but the calibration values are left at their factory default 
settings. So the sensors were probably calibration (as you confirm), but 
for some reason the calibration values are not stored. And thus we can't 
convert the ppO2 data from millivolt to ppO2.


Do you have a divecan unit? I believe Anton mentioned a while ago that 
he suspects the calibration might be done a bit different there. In a 
way where the dive computer gets the ppO2 values directly and thus 
doesn't need the calibration values. But only the millivolt values are 
stored, but we can't convert them to ppO2 without the correct 
calibration values.


So this warning means you won't get any ppO2 samples from 
libdivecomputer.


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

Re: Shearwater upload problems

[Jef Driesen]

On 2018-02-07 07:48, Willem Ferguson wrote:

I will be using Shearwater again within the next week and cross-check.
I will also be diving the same Predator with a single sensor two weeks
from now. One thing that may be relevant is that the Shearwater has
two different calibration modes, one for 3 connected sensors (usually
eCCR) and another calibration mode for a single sensor. Perhaps the
way the information in memory differs between these two modes?? Is
there anything specific that I should look out for or do during the
next 2 weeks??


I don't expect anything special about the single sensor mode (just 
values for one sensor instead of three). But of course I don't know that 
for sure. I just checked the memory dumps I have, and it looks like I 
don't have data from a shearwater dive computer in single sensor mode. 
So it's difficult to tell what should be there or not, because I have 
nothing to compare against.


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

Re: Shearwater upload problems

[Jef Driesen]

On 2018-02-05 15:42, Willem Ferguson wrote:

I definitely did pick the Predator option, both in the Linux OS
Bluetooth setup and within Subsurface. The O2 sensor on the computer
was calibrated using oxygen in the way specified in the user manual
and it performed very well. I have no idea how this relates to the
calibration bit and calibration value.


The dive header contains the number of sensors, and for each sensor a 
bit to indicate whether it was calibrated, and the calibration value. 
But your data only contains the number of sensors (1). Both the 
calibrated bit and the calibration value are zero. That's not what I 
expected to see.



The temperature data are ok. There are issues with the deco ceiling
calculated in Subsurface, but since deco is time-bound and we have an
erroneous time scale, it remains to be seen if the deco effects are
genuine or an artifact of the time scale problem.


I meant the data that came from the dive computer, and not some info 
that is calculated by subsurface. The fact that some of your data looks 
wrong, made me wonder whether there is some sort of data corruption. 
Hence my question whether some other data (depth, temperature, etc) 
looks wrong or not. If other data is clearly wrong too, then data 
corruption might indeed be the cause.


Do you happen to have memory dumps downloaded in the past?

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

Re: Shearwater upload problems

[Jef Driesen]

On 2018-02-05 15:35, Davide DB wrote:
On 5 February 2018 at 13:49, Jef Driesen <j...@libdivecomputer.org> 
wrote:

Last week, I merged a change to disable the ppO2 samples if all
(calibrated) sensors have the factory default calibration value 
(2100). If

you happen to have a unit that doesn't store the calibration values
properly, then this could explain why you are no longer seeing ppO2 
samples

with the latest libdivecomputer.


Should this solve the problem on my graph?

https://github.com/Subsurface-divelog/subsurface/issues/971


Yes and no. The fix disables the ppO2 samples. So you'll no longer get 
bogus ppO2 values. But of course that doesn't really fix the underlying 
problem (the missing calibration values).


Sorry, I forgot to notify you about the change.

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

Re: Shearwater upload problems

[Jef Driesen]

On 2018-02-05 14:00, Anton Lundin wrote:

On 05 February, 2018 - Willem Ferguson wrote:


This weekend I used a Shearwater predator dive computer. Connecting
via Bluetooth no problem, had to force it to classical bt as it
defaulted to LE. However, downloading the dive to Subsurface
provides two problems:

1) The duration for each dive is exactly half of what it was in real
life. So there is a problem with setting up the correct time
increments for successive samples.


This might be due to the parser by some reason parsing it as petrel
data. The petrel sample size is twice the sample size of the predator.

Are you sure you did pick "predator" ?


The predator doesn't support the newer petrel protocol. So I assume 
Willem did indeed select "Predator", otherwise the download would have 
failed.


But you are pointing in the right direction. The subsurface branch 
introduced a bug with commit 8ea8cebb4e6c3d86b9ceb2291caa077dabd2a3f7. 
There, the "petrel" parameter was removed and replaced with the model 
number. But the purpose of that parameter is to indicate whether the 
data came from the petrel or the predator backend. And because the model 
number appears to be stored incorrect in Willem's data (zero instead of 
2), the data gets indeed parsed using the petrel format.


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

Re: Shearwater upload problems

[Jef Driesen]

On 2018-02-05 11:31, Willem Ferguson wrote:

This weekend I used a Shearwater predator dive computer. Connecting
via Bluetooth no problem, had to force it to classical bt as it
defaulted to LE. However, downloading the dive to Subsurface provides
two problems:

1) The duration for each dive is exactly half of what it was in real
life. So there is a problem with setting up the correct time
increments for successive samples.


The shearwater sample rate is hardcoded to 10 seconds. So I don't see 
how that can produce unexpected results. Or are you referring to the 
reported dive time?



2) I had an oxygen sensor connected to the Shearwater. The oxygen
values are not shown in the downloaded log.


Last week, I merged a change to disable the ppO2 samples if all 
(calibrated) sensors have the factory default calibration value (2100). 
If you happen to have a unit that doesn't store the calibration values 
properly, then this could explain why you are no longer seeing ppO2 
samples with the latest libdivecomputer.



Below is a dropbox link to the Subsurface log and bin dumps of the
download. I am hoping someone can provide more information.

https://www.dropbox.com/sh/jiogq7li1bwpysl/AADZNPVfDhFlHXM6ZbpYMp3ja?dl=0


There is something strange with this data. The model number is zero, 
while it's supposed to be 2 for the Predator. The number of sensors is 
1, but none of the three sensors has its calibrated bit set, and all 
three calibration values are also zero.


Does the rest of the data looks good, or are there other errors as well?

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

Re: Device mount point is disabled (and fixed to wrong device)

[Jef Driesen]

On 03-02-18 18:05, Berthold Stoeger wrote:

On Samstag, 3. Februar 2018 17:46:10 CET Rob Mason wrote:

Hi Berthold - the subgear is irda, not bluetooth. It has worked previously
on older versions, but unable to connect on 4.7.6-1 on Mint Linux 18.3. --


Yes I know. Nevertheless, the "interface consistency fix" in commit  d23bd46
enables the device field only for serial transport.

To my defense - I just copied old buggy code, but made it more noticeable. I
pushed a fix to github. If you can compile from source, you can use this. If
not, there is a workaround: Select a dive computer with serial transport (I
think the XP-Air is), change the device and then go back to the XP-10. This
should be saved to the preferences, so you only have to do it once (until you
change dive computer).


The reason why the dropdown is disabled is because IrDA communication doesn't 
use a device node at all. Libdivecomputer will automatically discover the IrDA 
device address. So it doesn't matter what is shown in the dropdown box, because 
it's not used for anything.


If the download fails because no dive computer is found, that means the 
discovery did not found any IrDA device (or at least not one that matches a 
known dive computer). Enable the libdivecomputer logfile checkbox and send us 
the log. That should tell us what is going on.


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

Re: changes to our infrastructure

[Jef Driesen]

On 19-01-18 14:14, Robert Helling wrote:

Dirk,

On 19. Jan 2018, at 08:52, Dirk Hohndel > wrote:


Here's a quick heads up: I am planning to shut down some of the services that I
provide on my hardware (and that aren't really used anymore). In the next few 
days
(well, when we are ready to do this, I guess), I will shut down the git and 
trac server
under thesubsurface-divelog.org domain. The 
main git server has been GitHub for
quite a while now, but I can see in the logs that some people still pull from 
the old
git.subsurface-divelog.org - so please 
adjust your .git/config files if that includes you.

And Trac has been deprecated for over a year now. If you have data in there that
you want to migrate to GitHub issues or to another wiki, please talk to me so 
I know

that you are working on this and don't shut things down before you are ready.

Of course, we also need to do a scan through our documentation both in the
sources and on the website to ensure that we no longer mention these services.


I was about to download the stuff I wanted to preserve but I get:


  Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET / 
.


Reason: Error reading from remote server



Apache/2.4.18 (Ubuntu) Server at trac.subsurface-divelog.org 
 Port 80



Any idea? Please don’t waste any time on this but I had hoped to copy what I had 
written in the wiki about headless subsurface on a RaspberryPI like device. IIRC 
those were two wiki pages. So if you had access to those and could mail them to 
me that would be great. The other thing I wanted to check was if there were any 
interesting open issues that we need to move to GitHub.


You just need to try a few times. Once every few attempts it suddenly works. And 
then you can get at the "source" of the page by clicking the download as plain 
text link at the bottom. That's how I did backup the contents of the 
libdivecomputer wiki. Those plaintext files (markdown format I believe) can then 
hopefully be imported somehow in github wiki. At least that's my plan for 
migrating the libdivecomputer wiki.


If someone knows or finds a better way, let me know!

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

Re: O2 sensor values on CCR dives

[Jef Driesen]

On 22-12-17 10:53, Davide DB wrote:

I added this bug on Github for future reference:

https://github.com/Subsurface-divelog/subsurface/issues/971


I think Anton's suggestion, to check the calibration factors and emit the 
average ppo2 instead of the individual values if they are all equal to 2100, is 
not a bad idea. I just didn't get to the implementation yet, but it's on my todo 
list.


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

Re: O2 sensor values on CCR dives

[Jef Driesen]

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 255.


I assume you are talking about the ADC offset field?


The thing is also that if i "correct" your mV values by about -8, the
data lines up pretty nicely, so there's some correcting needing to be
done.

Can you save the same dive from Shearwater Desktop so I can take a 
look

at the mV values they report there, so see of they are out by about -8
or so?


The sensor millivolt values in the xml export and the raw data seems to 
be identical. At least for the few I checked. So I don't think we have 
to look there.



What I've guest previously, is that the unknown parameter there is
related to O2 Offsets.

Some related material on the subject is from when a production mis
caused them to be left as zero:
https://www.shearwater.com/wp-content/uploads/2016/07/O2-Offsets-Public-Notice-RevA.pdf

Why your's are max value 255 (signed -127), I don't know but they might
be just that.

What we never knew earlier was the unit of the offset value, or if it
was already applied to the value stored in the log.


Just a minor correction: When interpreted as a signed 8 bit number, the 
value 255 is -1, not -127.



Anyway, I analyzed all the data I have available and listed the 
calibration values stored in the dive header. The results are shown 
below.


The numbers are respectively:
 * sensor voting status bit (at offset 16)
 * calibration status bit (at offset 86)
 * calibration value (at offset 87-92)
 * adc offset (at offset 93-95)

perdixai.jongross
Sensor 0: 0 0 2100 -1
Sensor 1: 0 0 2100 -1
Sensor 2: 0 0 2100 -1

perdixai.linustorvalds
Sensor 0: 0 0 2100 -1
Sensor 1: 0 0 2100 -1
Sensor 2: 0 0 2100 -1

perdix.alvaroaguilera
Sensor 0: 0 0 2100 -1
Sensor 1: 0 0 2100 -1
Sensor 2: 0 0 2100 -1

perdix.timmassey
Sensor 0: 0 0 2100 -1
Sensor 1: 0 0 2100 -1
Sensor 2: 0 0 2100 -1

petrel.davidedb.310d20b4 (CCR, extppo2)
Sensor 0: 1 1 2100 -1
Sensor 1: 1 1 2100 -1
Sensor 2: 1 1 2100 -1

petrel.davidedb.39117da9 (CCR, extppo2)
Sensor 0: 0 1 2100 -1
Sensor 0: 1 1 2100 -1
Sensor 1: 0 1 2100 -1
Sensor 1: 1 1 2100 -1
Sensor 2: 0 1 2100 -1
Sensor 2: 1 1 2100 -1

petrel.henrikaronsen
Sensor 0: 0 0 0 -5
Sensor 0: 0 0 2100 -5
Sensor 1: 0 0 2100 -27
Sensor 1: 0 0 2148 -27
Sensor 2: 0 0 0 -9
Sensor 2: 0 0 2100 -9

petrel.jimpiavis
Sensor 0: 0 0 2100 -1
Sensor 1: 0 0 2100 -1
Sensor 2: 0 0 2100 -1

petrel.nickshore
Sensor 0: 0 0 2100 13
Sensor 1: 0 0 2100 11
Sensor 2: 0 0 2100 -23

petrel.stevewilliams (CCR, extppo2)
Sensor 0: 0 0 2100 2
Sensor 0: 0 1 1986 2
Sensor 0: 1 1 1769 2
Sensor 0: 1 1 1793 2
Sensor 0: 1 1 1826 2
Sensor 0: 1 1 1879 2
Sensor 0: 1 1 1935 2
Sensor 1: 0 0 2100 16
Sensor 1: 0 1 1970 16
Sensor 1: 0 1 2229 16
Sensor 1: 1 1 2227 16
Sensor 1: 1 1 2229 16
Sensor 1: 1 1 2263 16
Sensor 1: 1 1 2269 16
Sensor 1: 1 1 2533 16
Sensor 2: 0 0 0 4
Sensor 2: 0 0 2100 4
Sensor 2: 0 1 1986 4
Sensor 2: 1 1 1689 4
Sensor 2: 1 1 1817 4
Sensor 2: 1 1 1931 4
Sensor 2: 1 1 1974 4

petrel.45df0631
Sensor 0: 0 0 2100 13
Sensor 1: 0 0 2100 11
Sensor 2: 0 0 2100 -23

petrel.d3ea0432
Sensor 0: 0 0 2100 -1
Sensor 1: 0 0 2100 -1
Sensor 2: 0 0 2100 -1

petrel.larrybainbridge (CCR)
Sensor 0: 0 1 2045 44
Sensor 1: 0 1 2025 -9
Sensor 2: 0 1 2045 51

petrel.marklee (CCR)
Sensor 0: 0 0 2100 -1
Sensor 1: 0 0 2100 -1
Sensor 2: 0 0 2100 -1

petrel.rainer (CCR, extppo2)
Sensor 0: 0 1 1990 0
Sensor 0: 0 1 2034 0
Sensor 0: 1 1 1671 0
Sensor 0: 1 1 1990 0
Sensor 0: 1 1 2034 0
Sensor 0: 1 1 2038 0
Sensor 0: 1 1 2112 0
Sensor 1: 0 1 1810 39
Sensor 1: 1 1 1810 39
Sensor 1: 1 1 1929 39
Sensor 1: 1 1 2007 39
Sensor 1: 1 1 2068 39
Sensor 1: 1 1 2326 39
Sensor 2: 1 1 1621 2
Sensor 2: 1 1 1866 2
Sensor 2: 1 1 1939 2
Sensor 2: 1 1 2010 2
Sensor 2: 1 1 2108 2

predator.janschubert (CCR, extppo2)
Sensor 0: 1 1 859 -16
Sensor 0: 1 1 866 -16
Sensor 0: 1 1 867 -16
Sensor 0: 1 1 868 -16
Sensor 0: 1 1 878 -16
Sensor 0: 1 1 879 -16
Sensor 0: 1 1 881 -16
Sensor 0: 1 1 888 -16
Sensor 0: 1 1 890 -16
Sensor 0: 1 1 892 -16
Sensor 0: 1 1 895 -16
Sensor 1: 1 1 812 -24
Sensor 1: 1 1 814 -24
Sensor 1: 1 1 819 -24
Sensor 1: 1 1 828 -24
Sensor 1: 1 1 829 -24
Sensor 1: 1 1 834 -24
Sensor 1: 1 1 839 -24
Sensor 1: 1 1 843 -24
Sensor 2: 1 1 827 -11
Sensor 2: 1 1 831 -11
Sensor 2: 1 1 832 -11
Sensor 2: 1 1 836 -11
Sensor 2: 1 1 837 -11
Sensor 2: 1 1 839 -11
Sensor 2: 1 1 841 -11
Sensor 2: 1 1 844 -11
Sensor 2: 1 1 845 -11
Sensor 2: 1 1 856 -11

predator.kasrafaghihi
Sensor 0: 0 0 0 0
Sensor 1: 0 0 0 0
Sensor 2: 0 0 0 0

predator.marklee (CCR, extppo2)
Sensor 0: 1 1 1069 -41
Sensor 0: 1 1 885 -41
Sensor 0: 1 1 904 -41
Sensor 0: 1 1 982 -41
Sensor 1: 1 1 1000 -39
Sensor 1: 1 1 1016 -39
Sensor 1: 1 1 989 -39
Sensor 1: 1 1 996 -39
Sensor 2: 1 1 1179 -5
Sensor 2: 1 1 1228 -5
Sensor 2: 1 1 1261 -5
Sensor 

Re: O2 sensor values on CCR dives

[Jef Driesen]

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 millivolt
values is wrong. But the problem here is how do we verify this?

Look at the sample data in your xml export from shearwater desktop:


 0
 4
 0
 1
 0.98
 0.18
 0.45
 0
 99
 0
 20
 false
 false
 0
 0
 54
 55
 54
 1.52
 0
 0
 0
 0


There are millivolt values, but no corresponding ppO2 values. So I can
double check the millivolt values, but we have nothing to compare our ppO2
values against.


Hummm...
If I enable the average pO2 display on Subsurface even that values are
higher than the average calculated by Shearwater Desktop (SD).
Of course if the input data have an offset, even the resulting average will
be biased.
You wrote:


In the data there is only the millivolt, and libdivecomputer converts

this into a ppO2 value based on the calibration values. This conversion is
reverse engineered, so a mistake there is not impossible.

What I do not understand is how this conversion was made the very first
time. I mean how did you reverse engineered those values? I mean did you
have a reference data set (mV, calibration K and resulting po2) to compare
against?


Anton implemented the conversion for the Petrel. It's a simple multiplication:

   ppO2 = millivolt * calibration / 10.0;

So very straightforward to guess and then check whether the result is close to 
the average value (which is stored in the data as ppO2 value).


The Predator needed an extra scaling factor of 2.2. I found the scaling factor 
by doing the ppO2 conversion above, then average the three values and doing a 
linear regression against the average ppO2 from the data.


I think I still have that code lying around somewhere. I'll have a look again, 
but my weekend is fully booked, so that will probably be something for next week.



SD optionally shows the individual mv values against the average pO2. Is
this sufficient?


No, because both values are available in the data.


Going Sci-Fi the hard way to solve this is having the computer recording a
dive at a fixed depth and a fixed FO2 input. I have (nearly) all the pieces
to setup a test like this except that the sensor cable doesn't pass through
the pressure chamber :) I don't know if the Petrel can be forced to record
a dive at ambient pressure.


Well, the easiest and most reliable solution would be if Shearwater would tell 
us how to do the conversion :-)


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

Re: O2 sensor values on CCR dives

[Jef Driesen]

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 will send you everything off list.


The raw dive data, and also the data from Shearwater Desktop to compare 
against. The subsurface xml is useless here, because that's just the 
output of the libdivecomputer parser. Since that's basically what we 
want to verify it useless as "ground truth".


The average ppO2 is stored directly in the data, so that shouldn't 
match
perfectly. But the individual sensors is another story. In the data 
there is
only the millivolt, and libdivecomputer converts this into a ppO2 
value
based on the calibration values. This conversion is reverse 
engineered, so a
mistake there is not impossible. Note that libdivecomputer no longer 
reports

the average ppO2, only the individual sensors.

Is the resulting ppO2 wrong for the entire dive, or only during the 
deco
stop? The calibration does a simple multiplication with a constant 
value, so
if there is something wrong there, I would expect to see the same kind 
of

error throughout the entire dive.


Yes, it's wrong for the entire dive. I noticed the error looking at
the deco part just because Subsurface signalled me being at over 1.6
for all the 6 meter stop. But looking at O2 values in the deep part,
Subsurface seems to report always 0.1, 0.2 more than the real value.


That's already good to know. So that means that either the calibration 
constant, our calibration formula, or even the decoding of the millivolt 
values is wrong. But the problem here is how do we verify this?


Look at the sample data in your xml export from shearwater desktop:


0
4
0
1
0.98
0.18
0.45
0
99
0
20
false
false
0
0
54
55
54
1.52
0
0
0
0


There are millivolt values, but no corresponding ppO2 values. So I can 
double check the millivolt values, but we have nothing to compare our 
ppO2 values against.


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

Re: O2 sensor values on CCR dives

[Jef Driesen]

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
../../source/src/shearwater_common.c:319 
(shearwater_common_transfer)]

[73.192715] ERROR: Failed to download the dive. [in
../../source/src/shearwater_petrel.c:266
(shearwater_petrel_device_foreach)]
[73.193107] ERROR: Error downloading the dives. [in
../../source/examples/dctool_download.c:218 (download)]
[73.193712] INFO: Write: size=9, data=FF0105002E902000C0


On windows (and linux too), I already have a build of dctool available 
which uses native bluetooth communication. This should be a bit more 
reliable then the serial emulation. (On the Petrel, I've noticed that a 
low battery also causes download issues, probably because the bluetooth 
chip draws more power.) The bluetooth build is available here:


http://libdivecomputer.org/builds/experimental/windows/dctool-bluetooth.exe

Instead of the serial port, you need to pass the bluetooth mac address 
as a hexadecimal number (e.g. prefix with 0x, and remove the colons).



I haven't gotten around to it. Jef might be interested in looking at it
to, so I'll ping him.


Do we have some ground truth to compare against? Last time I checked 
Shearwater Desktop didn't show the ppO2 values. And if they do, do they 
show the average ppO2 or the individual sensors?


The average ppO2 is stored directly in the data, so that shouldn't match 
perfectly. But the individual sensors is another story. In the data 
there is only the millivolt, and libdivecomputer converts this into a 
ppO2 value based on the calibration values. This conversion is reverse 
engineered, so a mistake there is not impossible. Note that 
libdivecomputer no longer reports the average ppO2, only the individual 
sensors.


Is the resulting ppO2 wrong for the entire dive, or only during the deco 
stop? The calibration does a simple multiplication with a constant 
value, so if there is something wrong there, I would expect to see the 
same kind of error throughout the entire dive.


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

Re: Anybody with a Suunto EON Core?

[Jef Driesen]

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 device ID and
physical form factor, otherwise identical dive computer), but it would
be lovely to have somebody check and verify..


I also got the info on the new USB PID from Nick, and already made the 
necessary changes to libdivecomputer. My patch is almost identical to 
yours.


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

Re: Scubapro Aladin Square

[Jef Driesen]

On 14-11-17 23:04, Linus Torvalds wrote:

On Tue, Nov 14, 2017 at 2:00 PM, vavincavent <vavincav...@gmail.com> wrote:


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


Oh, I thought it already worked?

When  you ask subsurface to generate a dump file, it will not actually
import the dives at all.

But now that the communication is working, uncheck that, and see if
the download just works and the dives get imported..


The parsing needs some changes too for the new model number. The attached patch 
is what I have so far.


Jef
>From 9f18c74c1c576b34ee25591f5c6e999592e1e7ae Mon Sep 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 --
 src/uwatec_g2.h   |  2 +-
 src/uwatec_smart_parser.c |  8 ++--
 5 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/src/descriptor.c b/src/descriptor.c
index 6a2d6959..52186f44 100644
--- a/src/descriptor.c
+++ b/src/descriptor.c
@@ -139,6 +139,7 @@ static const dc_descriptor_t g_descriptors[] = {
 	/* Scubapro G2 */
 #ifdef USBHID
 	{"Scubapro", "Aladin Sport Matrix", DC_FAMILY_UWATEC_G2, 0x17},
+	{"Scubapro", "Aladin Square",   DC_FAMILY_UWATEC_G2, 0x22},
 	{"Scubapro", "G2",  DC_FAMILY_UWATEC_G2, 0x32},
 #endif
 	/* Reefnet */
diff --git a/src/device.c b/src/device.c
index 6277c900..349ed1d6 100644
--- a/src/device.c
+++ b/src/device.c
@@ -140,7 +140,7 @@ dc_device_open (dc_device_t **out, dc_context_t *context, dc_descriptor_t *descr
 		rc = uwatec_meridian_device_open (, context, name);
 		break;
 	case DC_FAMILY_UWATEC_G2:
-		rc = uwatec_g2_device_open (, context);
+		rc = uwatec_g2_device_open (, context, dc_descriptor_get_model (descriptor));
 		break;
 	case DC_FAMILY_REEFNET_SENSUS:
 		rc = reefnet_sensus_device_open (, context, name);
diff --git a/src/uwatec_g2.c b/src/uwatec_g2.c
index 4ef949fa..a30c7bda 100644
--- a/src/uwatec_g2.c
+++ b/src/uwatec_g2.c
@@ -35,6 +35,8 @@
 #define RX_PACKET_SIZE 64
 #define TX_PACKET_SIZE 32
 
+#define SQUARE0x22
+
 typedef struct uwatec_g2_device_t {
 	dc_device_t base;
 	dc_usbhid_t *usbhid;
@@ -178,7 +180,7 @@ uwatec_g2_handshake (uwatec_g2_device_t *device)
 
 
 dc_status_t
-uwatec_g2_device_open (dc_device_t **out, dc_context_t *context)
+uwatec_g2_device_open (dc_device_t **out, dc_context_t *context, unsigned int model)
 {
 	dc_status_t status = DC_STATUS_SUCCESS;
 	uwatec_g2_device_t *device = NULL;
@@ -200,7 +202,15 @@ uwatec_g2_device_open (dc_device_t **out, dc_context_t *context)
 	device->devtime = 0;
 
 	// Open the irda socket.
-	status = dc_usbhid_open (>usbhid, context, 0x2e6c, 0x3201);
+	unsigned int vid = 0, pid = 0;
+	if (model == SQUARE) {
+		vid = 0xc251;
+		pid = 0x2006;
+	} else {
+		vid = 0x2e6c;
+		pid = 0x3201;
+	}
+	status = dc_usbhid_open (>usbhid, context, vid, pid);
 	if (status != DC_STATUS_SUCCESS) {
 		ERROR (context, "Failed to open USB device");
 		goto error_free;
diff --git a/src/uwatec_g2.h b/src/uwatec_g2.h
index c7ac7ca3..801e15d3 100644
--- a/src/uwatec_g2.h
+++ b/src/uwatec_g2.h
@@ -31,7 +31,7 @@ extern "C" {
 #endif /* __cplusplus */
 
 dc_status_t
-uwatec_g2_device_open (dc_device_t **device, dc_context_t *context);
+uwatec_g2_device_open (dc_device_t **device, dc_context_t *context, unsigned int model);
 
 #ifdef __cplusplus
 }
diff --git a/src/uwatec_smart_parser.c b/src/uwatec_smart_parser.c
index e0726e41..e47320c5 100644
--- a/src/uwatec_smart_parser.c
+++ b/src/uwatec_smart_parser.c
@@ -46,6 +46,7 @@
 #define GALILEOTRIMIX 0x19
 #define SMARTZ0x1C
 #define MERIDIAN  0x20
+#define SQUARE0x22
 #define CHROMIS   0x24
 #define MANTIS2   0x26
 #define G20x32
@@ -522,7 +523,8 @@ uwatec_smart_parser_cache (uwatec_smart_parser_t *parser)
 if (parser->model == GALILEO || parser->model == GALILEOTRIMIX ||
 	parser->model == ALADIN2G || parser->model == MERIDIAN ||
 	parser->model == CHROMIS || parser->model == MANTIS2 ||
-	parser->model == G2 || parser->model == ALADINSPORTMATRIX) {
+	parser->model == G2 || parser->model == ALADINSPORTMATRIX ||
+	parser->model == SQUARE) {
 	unsigned int offset = header->tankpressure + 2 * i;
 	endpressure   = array_uint16_le(data + offset);
 	beginpressure = array_uint16_le(data + offset + 2 * header->ngases);
@@ -600,6 +602,7 @@ uwatec_smart_parser_create (dc_parser_t **out, dc_context_t *context, unsigned i
 	case MERIDIAN:
 	case CHROMIS:
 	case MANTIS2:
+	case SQUARE:
 		parser->headersize = 152;
 		parser->header = _smart_galileo_header;
 		parser->samples = uwatec_smart_galileo_samples;
@@ -952,7 +955

Re: Scubapro Aladin Square

[Jef Driesen]

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 being relevant.

It makes no sense that the receiver cares about the number of padding
bytes, but the code originally always padded out to the full USB HID
packet size of 64 bytes.

The whole confusion between 32/33 is all kinds of crazy, but yes,
maybe some broken other end really wants to see 32 bytes plus report
byte.


For the G2 on windows, the output packet size is 32 bytes, not 64 bytes. The 
input size is indeed 64 bytes. At least that's what the Windows api tells us. (I 
confirmed that by patched hidapi to log those numbers.) And since it wants the 
report id prepended, the total input packet size is 33 bytes. Anything else 
results in an invalid parameter error.


I don't know for sure for the Square, but since it worked, I assume it's the 
same there.


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

Re: Scubapro Aladin Square

[Jef Driesen]

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 libdivecomputer. If you look at the
g2.log of the successful download on Windows, then you can clearly see
libdivecomputer is sending out 33 byte packets (1 byte report id and 32
bytes payload).


.. but that's _exactly_ the usb library difference. On Windows, it's
using hidapi instead. Just a library difference.


Ah ok, you are referring to libusb vs hidapi. I thought you were talking about a
difference in the libusb version.

Give me a couple of minutes to build a libusb based windows version.


It's available here:

http://libdivecomputer.org/builds/experimental/windows/libdivecomputer-0.dll.libusb

(remove the .libusb suffix after downloading)

You'll need the following files as well:

http://libdivecomputer.org/builds/experimental/windows/g2.cmd
http://libdivecomputer.org/builds/divinglog/dctool.exe
http://libdivecomputer.org/builds/divinglog/libusb-1.0.dll

@Vincent: Can you give this build a try?

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

Re: Scubapro Aladin Square

[Jef Driesen]

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 successful download on Windows, then you can clearly see
libdivecomputer is sending out 33 byte packets (1 byte report id and 32
bytes payload).


.. but that's _exactly_ the usb library difference. On Windows, it's
using hidapi instead. Just a library difference.


Ah ok, you are referring to libusb vs hidapi. I thought you were talking about a 
difference in the libusb version.


Give me a couple of minutes to build a libusb based windows version.


So somehow the subsurface branch doesn't use the right size.
It's probably the csize+1 in this code:


That "+1" should only trigger for GATT, since packet_size is 64 for usbhid, see

 static dc_custom_io_t custom = {
 .packet_size = 64,
 .packet_close = usbhid_packet_close,
 .packet_read  = usbhid_packet_read,
 .packet_write = usbhid_packet_write,
 };

in dc_usbhid_custom_io().

That said, the part that *should* trigger:


 status = io->packet_write(io, buf, sizeof(buf), );


In of you previous emails, you asked Vincent to patch the

if (io->packet_size < 64) {

to a

if (1) {

So I assumed he did exactly that and in that case the code always takes that 
branch and thus also the csize+1!



Already has that "sizeof(buf)", which is TX_PACKET_SIZE.

The reason it is then turned into 31 is because of this in src/usbhid.c:

 // Skip a report id of zero.
 unsigned char report = buffer[0];
 if (report == 0) {
 buffer++;
 length--;
 }

and that's because at least _my_ usblib doesn't need/want that extra
report byte.

I'm not sure if it hurts, though. So maybe that code could be disabled.


Ah that explains the difference. In upstream libdivecomputer the buffer is one 
byte larger:


unsigned char buf[TX_PACKET_SIZE + 1];

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

Re: Scubapro Aladin Square

[Jef Driesen]

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)
  - device 3: RealTek RTS5129 card reader (0bda:0129)
  - device 4: Realtek something (0bda:57de) Wifi?
  - device 59: Lite-On bluetooth donge (04ca:3018)
  - device 60: c251:2006

I assume that matches what you'd expect on that bus?

So it's that device 60.

And the only traffic I see there is (apart from the two empty reads)
is that one URB_INTERRUPT write packet with data 0110.

Very odd.

Also, for some reason wireshark is not showing it as a USB HID
protocol thing. That's odd. I was pretty sure wireshark should do
that.


Oh, it only does that for the setup packets that aren't there.

And I do notice a big difference to what I get when I do a similar dump.

Your dump shows:

   Frame 1573: 66 bytes on wire (528 bits), 66 bytes captured (528
bits) on interface 0
   USB URB
   [Source: host]
   [Destination: 1.60.2]
   URB id: 0x97a01200de40
   URB type: URB_SUBMIT ('S')
   URB transfer type: URB_INTERRUPT (0x01)
   Endpoint: 0x02, Direction: OUT
   Device: 60
   URB bus id: 1
   Device setup request: not relevant ('-')
   Data: present (0)
   URB sec: 1510685037
   URB usec: 39850
   URB status: Operation now in progress (-EINPROGRESS) (-115)
   URB length [bytes]: 2
   Data length [bytes]: 2
   [Response in: 1574]
   [bInterfaceClass: Unknown (0x)]
   Unused Setup Header
   Interval: 8
   Start frame: 0
   Copy of Transfer Flags: 0x
   Number of ISO descriptors: 0
   Leftover Capture Data: 0110

for that 0110 command packet.

When I do it, I get:

   Frame 579: 95 bytes on wire (760 bits), 95 bytes captured (760 bits)
on interface 0
   USB URB
   [Source: host]
   [Destination: 3.6.1]
   URB id: 0x914c372596c0
   URB type: URB_SUBMIT ('S')
   URB transfer type: URB_INTERRUPT (0x01)
   Endpoint: 0x01, Direction: OUT
   Device: 6
   URB bus id: 3
   Device setup request: not relevant ('-')
   Data: present (0)
   URB sec: 1510686848
   URB usec: 546665
   URB status: Operation now in progress (-EINPROGRESS) (-115)
   URB length [bytes]: 31
   Data length [bytes]: 31
   [Response in: 580]
   [bInterfaceClass: HID (0x03)]
   Unused Setup Header
   Interval: 4
   Start frame: 0
   Copy of Transfer Flags: 0x
   Number of ISO descriptors: 0
   Leftover Capture Data: 011b...

Notice the different in Data length and padding.

So I think what's going on here is that different versions of libusb
end up padding things differently, and your dive computer doesn't like
the short packets that your version of libusb creates.

I dunno. Maybe it's some other thing that results in this difference.

Anyway, let's just hack around it and test, See that
"libusb_interrupt_transfer()" call in the function dc_usbhid_write()
in src/usbhit.c?

Add something like

  if (length < 31)
   length = 31;

to just before it. It will send garbage padding, but the dive computer
sends _us_ garbage padding, so that's probably ok.

It's a horrible hack, but it's just for testing.


I suspect this is not caused by a difference in the libusb version, but a 
difference in the subsurface branch of libdivecomputer. If you look at the 
g2.log of the successful download on Windows, then you can clearly see 
libdivecomputer is sending out 33 byte packets (1 byte report id and 32 bytes 
payload). So somehow the subsurface branch doesn't use the right size. It's 
probably the csize+1 in this code:


// BLE GATT protocol?
if (io->packet_size < 64) {
// No report type byte
status = io->packet_write(io, buf+1, csize+1, );
} else {
status = io->packet_write(io, buf, sizeof(buf), );
}

I don't have an explanation for the 32 vs 31 bytes.

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

Re: Scubapro Aladin Square

[Jef Driesen]

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 zero byte for
the report type to make hidapi happy, and *my* version of usblib
certainly didn't care, but...


The zero report id should be stripped in our usbhid backend when using libusb, 
so I doubt that's the problem.


Logtrak is using hidapi, so it might be worth trying to build libdivecomputer 
with hidapi instead of libusb (./configure --without-libusb). That will already 
rule out one difference. And maybe also try libdivecomputer/subsurface on 
windows too, because we know for sure downloading there works. If we can confirm 
it works on windows, then we can move one step at a time, and try to identify 
which step is the culprit (hidapi vs libusb, windows vs linux, etc).


I have prepared a hidapi based windows build for you. Just download these files:

http://libdivecomputer.org/builds/experimental/windows/g2.cmd
http://libdivecomputer.org/builds/experimental/windows/libdivecomputer-0.dll
http://libdivecomputer.org/builds/divinglog/libhidapi-0.dll
http://libdivecomputer.org/builds/divinglog/dctool.exe

Place everything in the same directory, and start the download by 
double-clicking the g2 batch file. When done, email us the g2.log file, and if 
present also the g2.bin file.


(I also patched the g2 backend with the VID/PID of the aladin square in this 
build.)


I think you said this is on debian. Use 'tshark -i usbmon1 -w
out.pcap" (replace 'usbmon1' with whatever bus the device is on) to
capture a packet trace.

You can use wireshark as a GUI tool of course. Usually I find it's
nicer to first capture on the command line, and then use wireshark to
look at things, but whatever works for you...


Yes, this is indeed something worth trying.

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

Re: Scubapro Aladin Square

[Jef Driesen]

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, endpoints=81,02
ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in
../../src/usbhid.c:392 (dc_usbhid_open)]
ERROR: Failed to open Scubapro G2 device [in scubapro_g2.c:224
(scubapro_g2_device_open)]

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


You don't have permission to open the usb device. You'll need to add a 
udev rule for your dive computer. For example:


echo 'SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="c251", 
ATTR{idProduct}=="2006", GROUP="plugdev"' | sudo tee 
/etc/udev/rules.d/99-divecomputer.rules


(This assumes you are part of the "plugdev" group. On debian/ubuntu 
based systems that's normally the case.)


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

Re: Import data from Scubapro Aladin Sport Matrix

[Jef Driesen]

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 (device,
cmd_model, sizeof (cmd_model), model, sizeof (model));" and guess what?
I got both, 0x17 *and* 0xa5 (the latter much more commonly). There seems to be
some race. Will investigate further - tomorrow.

But when manually sending 0x10 manually with my test program, I consistently
get a 0x17, which therefore seems to be the correct model. Sigh.


That's indeed strange. Probably something is still wrong. Can you share the 
logs? Maybe we can spot something?


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

Re: Import data from Scubapro Aladin Sport Matrix

[Jef Driesen]

On 2017-10-31 12:12, Berthold Stoeger wrote:

Hi Jef,

On Dienstag, 31. Oktober 2017 11:29:00 CET Jef Driesen wrote:

On 2017-10-23 00:55, Berthold Stoeger wrote:
> On Sonntag, 22. Oktober 2017 04:31:39 CEST Linus Torvalds wrote:
>> so you literally *could* try to claim it's a G2 and try to see how far
>> it downloads.
>
> The handshake is different. The G2 client sends 1b and 1c1027 and
> expects
> 01 as the answer twice. The Aladin Sport returns 00 in both cases.
> Since
> LogTrak doesn't do any handshake, I just removed the call to
> scubapro_g2_handshake().

Am I right you only tested downloading over bluetooth (BLE)? Can you
also try over USB? I suspect that logtrak still does the handshaking
when downloading over USB. If that's correct, then omitting the
handshaking is not specific to the Sport Matrix, but the underlying
transport.


To my knowledge the Sport Matrix does only support BLE! At least that's 
how I

read
https://ww2.scubapro.com/en-GB/SWE/instruments/computers/products/aladin-sport-matrix.aspx:

| For PCs and Macs that are not equipped with built-in Bluetooth Low 
Energy
| technology, the end user will have to buy a Bluetooth Low Energy USB 
dongle

| which is available on the market.


I simply assumed it was similar to the G2, which supports both.

That's why I feel that dc_descriptor_get_transport() should return 
flags, not

enums. You want to differentiate between USB, BT, USB+BT, don't you?


Indeed! Such a change is already on my todo list :-)

Because it breaks backwards compatibility, I will introduce it together 
with some other non-backwards compatible changes, like the I/O 
factoring. That way applications only have to be updated once.



But yes, doing handshakes based on transport not model is a good idea.


The less "if (model == X)" code we need, the better!

Note that in most cases the exact model number is communicated by the 
device during the download. Needing the model number up front breaks 
this auto-detection mechanism. (You would be surprised how many users 
don't know exactly which model they have. For some dive computers, the 
naming can indeed be confusing.)


I don't have access to the computer right know and will answer to your 
other

remarks later.


Excellent!

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

Re: Import data from Scubapro Aladin Sport Matrix

[Jef Driesen]

On 2017-10-23 00:55, Berthold Stoeger wrote:

On Sonntag, 22. Oktober 2017 04:31:39 CEST Linus Torvalds wrote:


so you literally *could* try to claim it's a G2 and try to see how far
it downloads.


The handshake is different. The G2 client sends 1b and 1c1027 and 
expects
01 as the answer twice. The Aladin Sport returns 00 in both cases. 
Since

LogTrak doesn't do any handshake, I just removed the call to
scubapro_g2_handshake().


Am I right you only tested downloading over bluetooth (BLE)? Can you 
also try over USB? I suspect that logtrak still does the handshaking 
when downloading over USB. If that's correct, then omitting the 
handshaking is not specific to the Sport Matrix, but the underlying 
transport.


Note that logtrak also supports a second variant of the handshaking 
(0xF4), in case the other two (0x1B and 0x1C) return zero, but I have 
never seen that so far. Maybe the Sport Matrix is in this category?


Apart from that - you were right - it seems to be compatible with the 
G2! Only
the dates are incorrect - I will try to figure out what is going on. 
All I had
to do was adding a case in the switch in uwatec_smart_parser_create(). 
The id
of the Aladin Sport Matrix is 0xa5, by the way. And it works! Thank you 
very

much for your support!


I believe you have the model number wrong. I think it should be 0x17, 
and your test seems to confirm that:


Command: 0110
Output : 0117

Do you mind sending me a libdivecomputer memory dump and logfile?

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

Re: Unable to download Dive info from Oceanic VT 4.1

[Jef Driesen]

On 2017-10-27 05:00, Malcolm wrote:
I get a data error message when I try and download dives from my 
Oceanic VT
4.1 dive computer. I am using a new laptop computer. Attached are the 
files

suggested in subsurface help


It looks like this is yet another case of a corrupt ringbuffer begin 
pointer:


ERROR: Invalid logbook pointer detected (0x0240 0x0a30). [in 
../../source/src/oceanic_common.c:218 (oceanic_common_device_logbook)]
ERROR: Error downloading the dives. [in 
../../source/examples/dctool_download.c:218 (download)]

ERROR: Data format error

Since this "bug" (a firmware bug probably) shows up quite often, I have 
been looking at possible solutions already. I have some ideas on how to 
modify the download algorithm to no longer depend on the begin pointer. 
But at the moment that work isn't finished yet. It works most of the 
time, but it also causes some regression for others. So it needs some 
more polish.


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

Re: interpolating depth values

[Jef Driesen]

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 be bobbing at the
surface with your arm in the water, but almost certainly also simply
due to pressure sensor calibration issues (which might not be about
the sensor, it could be about simply dropping atmospheric pressure -
going from a high-pressure system to a low-pressure one - but rapidly
falling pressure of that magnitude really is "major storm is here or
imminent").


The dive computers that produce negative depths are the ones that store the 
depth as absolute pressure (e.g. reefnet and uwatec/scubapro). In order to 
convert to a depth value in meters, you subtract the atmospheric pressure, which 
is also recorded with the same sensor. Now, for a common pressure sensor like 
the Intersema MS5541C (which is used by many dive computers), the accuracy is 
-50 to 20 mbar.


Near the surface you subtract two nearly identical values, each with some error 
margin. The result will be close to zero, but not exactly. You end up with 
errors in both positive and negative direction with an order of magnitude of the 
accuracy of the sensor. So there is nothing special about those small negative 
values.


Dive computers that store the converted depth value in meters instead of the 
absolute pressure probably clamp the result to zero, and thus you won't see them 
there.


I assume most dive computers measure the atmospheric pressure by continuously 
sampling their pressure sensor while in surface mode (probably at a much lower 
frequency to save battery power). And once they detect a dive has started, they 
just use the last measured value (or a few ones ago) as the atmospheric 
pressure. In that case there is really no need to start with a surface pressure 
at about 1m depth.


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

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

[Jef Driesen]

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 parses the source to give me the
information that I want.


Well, that's a pretty ugly and error-prone hack. You hard-code 
everything in the application, based on whatever version that was used 
at build time (which may not even be the same as at runtime). But the 
reason why that table exists, is to let applications populate the list 
of supported devices dynamically at runtime! And by doing it this way, 
you also depend on some of the libdivecomputer internals.


If we're adding this kind of annotations, then I prefer to make this 
information available through the api. That will be a lot more useful, 
and may also benefit other applications.



Something like what I proposed for the I/O refactoring:

For the I/O refactoring, I'm already planning to add an extra field 
with the transport type. Since some devices support multiple 
transports, the transport type will need to change into a bitfield. So 
something like this:


{"Shearwater", "Petrel 2",  DC_FAMILY_SHEARWATER_PETREL, 4,
DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH | DC_TRANSPORT_BLE},


Which doesn't tell me if this is an FTDI chip - which is one of the
things that I need to know.


That's quite easy: Suunto (solution, eon, vyper and d9), Oceanic (vtpro, 
veo250 and atom2), HW (frog, ostc and ostc3) and Cressi (leonardo) 
backends use an FTDI chip. You don't need to annotate each device for 
that. Just check the family type.


Note that the usb-serial chipset is often not integrated in the dive 
computer, but in the external PC interface. So there is not always a 
nice one-to-one relationship. For example the official Suunto PC 
interface uses an FTDI chip, but there are also third-party interfaces 
available using a Silicon Labs chip (and those are quite common). And 
some really old models still have a real serial port, and thus the user 
can use any usb-serial dongle.


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

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

[Jef Driesen]

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 DC connected.

No errors reported.
Can we carefully conclude that BT comm works? ;)
I will be try same DC with dives/log after one week and revert.
Sorry, we have 3 Ratio DC here, but all pristine new w/o dives.


The last error in the logfile:

ERROR: Received NAK packet with error code 58. [in 
../../src/divesystem_idive.c:348 (divesystem_idive_packet)]


might be a bit misleading. Error code 58 means that the dive computers 
contains no dives yet. So it's completely harmless and the download was 
completed successfully.


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

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

[Jef Driesen]

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 strict syntax: two slashes, one space, then a token. There
can be more than one such comment, e.g.:

/* Shearwater Petrel family */
{"Shearwater", "Petrel",DC_FAMILY_SHEARWATER_PETREL, 3},
// BT // BLE
{"Shearwater", "Petrel 2",  DC_FAMILY_SHEARWATER_PETREL, 4},
// BT // BLE
{"Shearwater", "Nerd",  DC_FAMILY_SHEARWATER_PETREL, 5},  
// BT

{"Shearwater", "Perdix",DC_FAMILY_SHEARWATER_PETREL, 6},
// BT // BLE
{"Shearwater", "Perdix AI", DC_FAMILY_SHEARWATER_PETREL, 7},  
// BLE


(yes, I know this looks wrong, as the Petrel has no BLE version, but
the Petrel 2 unfortunately identifies itself as Petrel).

Would you be willing to take a patch that adds this for
libdivecomputer master? This would make our lives easier and it
certainly shouldn't cause any problems on your end as this is all just
comments...
Please let me know and I'll be happy to submit one clean patch to just 
add that.


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? Something 
like what I proposed for the I/O refactoring:


For the I/O refactoring, I'm already planning to add an extra field with 
the transport type. Since some devices support multiple transports, the 
transport type will need to change into a bitfield. So something like 
this:


{"Shearwater", "Petrel 2",  DC_FAMILY_SHEARWATER_PETREL, 4,
DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH | DC_TRANSPORT_BLE},

With this information, an application knows exactly which transport 
types are supported for each device, and can setup the appropriate I/O 
channel (built-in or custom implementation).


To find out what goes wrong, you'll need to enable the libdivecomputer 
logfile checkbox. Without the logfile, we have no idea where exactly 
it goes wrong. Screenshots are useless because they don't give the 
low-level detailed info.


I keep wanting to improve the error messages that we are able to give
- right now the useless default error that implies incorrect
permissions does a lot more harm than anything else. I just can't seem
to find the time with all the other things on my plate. A feeling that
I know you are well familiar with, Jef.

But until then, the libdivecomputer log file certainly is the correct
next step. Actually, I might be able to add a quick and dirty change
that suggests this to the user... then at least people using the test
builds would get that hint.


Just an idea: Why not always enable the logfile? Then whenever the 
download fails, you can notify the user about the error as usual, but 
also point to the log file. You probably don't want to show the contents 
of the log, but just the location of the file. That makes it very easy 
to report errors, because all the info is right there. Diving Log does 
something similar, and it works very well.


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

Re: Atmospheric pressure for Ratio iX3M

[Jef Driesen]

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 idea how those come about? Maybe there is something wrong in
the parser.


According to the documentation, the atmospheric pressure is stored in
millibar. That appears to be correct for the older models (Orca and 
iDive).
But for all the newer models (iX3M) the result is indeed a factor 10 
too
large. Probably a mistake in the documentation (or a bug in the 
firmware).

I'll take care of fixing that.

While you are making the surface pressure change can you also add the 
fixed

set point data.
I am manually adding the initial fixed setpoint ppo2 to the xml file 
and I

also don't think that the setpoint changes get added.
You should have my ix3m-reb data from our last testing that is using 
fixed

setpoint and without.


The atmospheric pressure was already added a few days ago, and I've now 
added the setpoint samples too.


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

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

[Jef Driesen]

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 cases where the actual model matters because there is a small but 
important difference in the communication protocol! (You can still 
choose any model from the iX3M series).


Support for the APOS4 firmware was added a few months ago, so I don't 
think that's the problem here. (Unless you are using a subsurface build 
where this change wasn't included yet.)


To find out what goes wrong, you'll need to enable the libdivecomputer 
logfile checkbox. Without the logfile, we have no idea where exactly it 
goes wrong. Screenshots are useless because they don't give the 
low-level detailed info.


Jef

On 2017-08-21 15:57, Gregory Sin wrote:

Dear Dirk,

Sorry for confusion.. perhaps its a bit complicated :)

To my understanding, issue with Os 10.9.5 is closed.
SubSurface has compatibility only 10.10 and above.

Today I did one more testing of iDive and iX3M on 10.12.6
Please find fresh screens attached.

One DC run “old” OS which is 4.0.9 and another DC run
updated/“new” OS which is 4.0.26.
Reason why I put this info up, because I’ve heard some rumors that
with latest update Ratio changed something in protocol.
By using same DC with different OS Im just trying to eliminate that
possible com-protocol issue.

Both DCs tested via USB not BT. I also deleted BT pairing to make
experiment more clean.
Both DCs were READY and shows DATA upon attempt of import or
configuration setup.
Both DCs have no data (no log yet).
SubSurf showed: usbserial-DN02DP66 port for both DC equally.
Both attempts of download showed Error Data import error.

Not sure, but may be its a good idea for time being to skip that DC
configuration feature because it is obviously not ready yet and focus
on importing data.
At least SubSurf may import data from DC log.

Screens are enclosed.
Please guide me how I can help more.

Remain at your disposal.
Greg

On 21 Aug, 2017, at 20:36, Dirk Hohndel  wrote:


It is also cant see USB unless you purposely put USB0 in the port
settings.


So if you put USB0 it works, but with /dev/tty.USB0 it doesn't? I'm
confused.


I tried iDive with old OS and iX3M with new.


I don't understand, I thought the old OS (10.9) didn't allow you to
run the new Subsurface build at all?

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

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

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

[Jef Driesen]

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 bluetooth MAC address 
(00:13:43:0C:56:29) is being passed to the dc_serial_open() function. And of 
course that doesn't work!


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

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

[Jef Driesen]

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
synchronized to the local time quite nicely).

And I just wrote the code for that for the Suunto EON Steel. Patch to
libdivecomputer attached in case anybody cares (and I was happy to
realize that it actually uses milliseconds for synchronization, but
then noticed that it may be just a protocol thing, and the extra
precision may get thrown away).

But I suspect people will hate that patch because it does that time
sync thing *unconditionally*. It would be good to have a check-box and
some way to actually set the "sync time" flag. But for that to happen,
we'd need not just the UI side, we'd need to have the libdivecomputer
interface too.

And yes, I know about "configure dive computer" and the "sync time"
hack there. But it's really an ostc-specific hack, not something that
can be used in general to synchronize the clock.

Thus the "request for discussion". I'd love to be able to pass in
flags like this to dc_device_open() or add a sane
"dc_device_set_feature()" interface or something..


How about turning the ostc specific clock sync function into a
standard function that is part of the dc_device_t interface? Then
every backend that supports setting the time can easily implement it.
I'm pretty sure there are more dive computers where the protocol
supports this (e.g. the oceanic software has a time sync setting), so
I see no reason not to support this as a standard feature.

dc_status_t
dc_device_clock (dc_device_t *device, const dc_datetime_t *datetime);

And then it's up to the application to call this function or not.
Doing this kind of stuff automatically from within libdivecomputer is
probably a bad idea (host clock can be wrong, set to a different time
zone, etc).


This feature is now available in the master branch! At the moment, the 
new dc_device_timesync() function is implemented for the Heinrichs 
Weikamp backends.


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

Re: Atmospheric pressure for Ratio iX3M

[Jef Driesen]

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 there is something wrong in
the parser.


According to the documentation, the atmospheric pressure is stored in 
millibar. That appears to be correct for the older models (Orca and 
iDive). But for all the newer models (iX3M) the result is indeed a 
factor 10 too large. Probably a mistake in the documentation (or a bug 
in the firmware). I'll take care of fixing that.


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