Stupidly, commit 731d9dc9bd ("DC download: tell user when no new dives
were found") was missing the conditional when to show that messages.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of the (usually incorrect) text about insufficient privileges,
just mention a generic error and suggest that the user creates a
libdivecomputer log file.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We had a "add_sample_pressure()" helper functions that was local to just
the libdivecomputer downloading code, but it really is applicable to
pretty much any code that adds cylinder pressure data to a sample.
Also add another helper: "legacy_format_o2pressures()" which checks the
sample data to see if we can use the legacy format, and returns the o2
pressure sensor to use for that legacy format.
Because both the XML and the git save format will need a way to save the
compatible old-style information, when possible, but save an extended
format for when we have data from multiple concurrent sensors.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This tries to sanely handle the case of a dive computer reporting
multiple cylinder pressures concurrently.
NOTE! There are various "interesting" situations that this whole issue
brings up:
- some dive computers may report more cylinder pressures than we have
slots for.
Currently we will drop such pressures on the floor if they come for
the same sample, but if they end up being spread across multiple
samples we will end up re-using the slots with different sensor
indexes.
That kind of slot re-use may or may not end up confusing other
subsurface logic - for example, make things believe there was a
cylidner change event.
- some dive computers might send only one sample at a time, but switch
*which* sample they send on a gas switch event. If they also report
the correct sensor number, we'll now start reporting that pressure in
the second slot.
This should all be fine, and is the RightThing(tm) to do, but is
different from what we used to do when we only ever used a single
slot.
- When people actually use multiple sensors, our old save format will
start to need fixing. Right now our save format comes from the CCR
model where the second sensor was always the Oxygen sensor.
We save that pressure fine (except we save it as "o2pressure" - just
an odd historical naming artifact), but we do *not* save the actual
sensor index, because in our traditional format that was always
implicit in the data ("it's the oxygen cylinder").
so while this code hopefully makes our libdivecomputer download do the
right thing, there *will* be further fallout from having multiple
cylinder pressure sensors. We're not done yet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a very timid start at making us actually use multiple sensors
without the magical special case for just CCR oxygen tracking.
It mainly does:
- turn the "sample->sensor" index into an array of two indexes, to
match the pressures themselves.
- get rid of dive->{oxygen_cylinder_index,diluent_cylinder_index},
since a CCR dive should now simply set the sample->sensor[] indices
correctly instead.
- in a couple of places, start actually looping over the sensors rather
than special-case the O2 case (although often the small "loops" are
just unrolled, since it's just two cases.
but in many cases we still end up only covering the zero sensor case,
because the CCR O2 sensor code coverage was fairly limited.
It's entirely possible (even likely) that this migth break some existing
case: it tries to be a fairly direct ("stupid") translation of the old
code, but unlike the preparatory patch this does actually does change
some semantics.
For example, right now the git loader code assumes that if the git save
data contains a o2pressure entry, it just hardcodes the O2 sensor index
to 1.
In fact, one issue is going to simply be that our file formats do not
have that multiple sensor format, but instead had very clearly encoded
things as being the CCR O2 pressure sensor.
But this is hopefully close to usable, and I will need feedback (and
maybe test cases) from people who have existing CCR dives with pressure
data.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We currently carry two pressures around for all the samples and plot
info, but the second pressure is reserved for CCR dives as the O2
cylinder pressure.
That's kind of annoying when we *could* use it for regular sidemount
dives as the secondary pressure.
So start prepping for that instead: don't make it "pressure" and
"o2pressure", make it just be an array of two pressure values.
NOTE! This is purely mindless prepwork. It literally just does a
search-and-replace, keeping the exact same semantics, so "pressure[1]"
is still just O2 pressure.
But at some future date, we can now start using it for a second sensor
value for sidemount instead.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
No idea why this now shows up as an error in the iOS build.
We need to refer to the typedef, not the underlying struct.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While it's nice to have the numerical model in the logfile,
on the screen the user wants to see the dive computer product
name. And none of those hex numbers that make the text so long
that it becomes useless.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This reverts commit ed43b5dced ("Add
support for tank sensor battery for Perdix AI") since a much better
solution to get to that information has been implemented in
libdivecomputer.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a bit awkward with a VENDOR event - but at the time the strings
are generated, we don't have the information, yet, that we need to
determine these values (we need the last sample parsed, but the strings
are created as part of the dive headers.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of being "custom serial", it's a IO model that allows serial or
packet modes, independently of each other (ie you can have a bluetooth
device that does serial over BT rfcomm and packet-based communication
over BLE GATT with the same serial operations that describe both cases).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The linear search to determine that a just downloaded dive was already
downloaded, started from the oldest dive in the logbook. It is, however
more likely that a just downloaded dive is one of the most recently
downloaded. So, just search backwards. Just a trivial performance
improvement.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The file static po2 value, used to set the setpoint data, was not re-initialized
at the parsing of a dive during import from the divecomputer. So, in one import session,
the po2 was transferred from one dive to the next, obviously resulting in weird bugs, due
to possible wrong po2 settings.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Some of these header files are no longer necessary, and will be removed
from libdivecomputer in the near future.
Signed-off-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a rather arbitrary value, intended to create actually valid
pressure values for Uwatec Memomouse users - since we treat 0bar as
invalid pressure value, this simply creates an arbitrary '30bar + delta'
to '30bar' consumption graph (since all the Memomouse devices give us is
the pressure delta that was used during the dive).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of delivering the actual start and end pressure, memomouse
gives you a start pressure that matches the delta between actual
start and end pressure, and an end pressure of zero. Who the heck
knows why it does that, but the information is better than nothing,
so we should accept it.
Fixes#286
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The following pragma is Clang specific:
It produces a warning:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
Only enable it for Clang by checking the __clang__ macro.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Not using lrint(f) when converting double/float to int
creates rounding errors.
This error was detected by TestParse::testParseDM4 failure
on Windows. It was creating rounding inconsistencies
on Linux too, see change in TestDiveDM4.xml.
Enable -Wfloat-conversion for gcc version greater than 4.9.0
Signed-off-by: Jeremie Guichard <djebrest@gmail.com>
Using gcc option "-Wfloat-conversion" is useful to catch
potential conversion errors (where lrint should be used).
rint returns double and still raises the same warning,
this is why this change updates all rint calls to lrint.
In few places, where input type is a float, corresponding
lrinf is used.
Signed-off-by: Jeremie Guichard <djebrest@gmail.com>
When Suunto Vytecs are used in gauge mode they don't record gasmixes.
If a tank pressure sensor is present they nevertheless record the
pressures. This patch handles this situation by assuming the tanks
contain air (and warning the user about this).
[Dirk Hohndel: I had mistakenly pushed out an earlier version of this
commit, so this fixes things up to the final version]
Reported-by: antonnorth@gmail.com
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When Suunto Vytecs are used in gauge mode they don't record gasmixes.
If a tank pressure sensor is present they nevertheless record the
pressures. This patch handles this situation by assuming the tanks
contain air (and warning the user about this).
Reported-by: antonnorth@gmail.com
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We had hardcoded the exact translation of the event numbers. They
haven't changed (although we did have what appears to be a spurious
entry for "non stop time" at the end that libdivecomputer doesn't have
an enum for).
Instead, use an explicit array index initializer array, so that it's
obvious that the two match up (and if the sample event numbers ever
change, we should cope with it gracefully).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
New libdivecomputer versions use DC_SAMPLE_GASMIX to indicate a gas
change (which contains the cylinder index we're changing to) rather than
SAMPLE_EVENT_GASCHANGE*.
Unlike the old GASCHANGE model, and despite the name, DC_SAMPLE_GASMIX
does not actually say what the mix is, it only specifies a cylinder
index. We had already extended SAMPLE_EVENT_GASCHANGE2 to have the
cylinder index in the otherwise unused "flags" field, so this is not all
that different from what we used to do.
And subsurface internally already had the logic that "if we know what
the cylinder index is, take the gas mix from the cylinder data", so
we've already been able to transparently use _either_ the actual gas mix
or the cylinder index to show the event.
But we do want to make it an event rather than some sample data, because
we want to show it as such in the profile. But because we are happy
with just the cylinder index, we'll just translate the DC_SAMPLE_GASMIX
thing to the SAMPLE_EVENT_GASCHANGE2 event, and nothing really changes
for subsurface.
libdivecomputer has made other changes, like indicating the initial
cylinder index with an early DC_SAMPLE_GASMIX report, but we've seen
that before too (in the form of early SAMPLE_EVENT_GASCHANGE events), so
that doesn't really end up changing anything for us either.
HOWEVER, one thing that is worth noticing: do *not* apply this patch and
then use an old libdivecomputer library that sends both the
DC_SAMPLE_GASMIX samples _and_ the deprecated SAMPLE_EVENT_GASCHANGE
events. It will all *work*, but since subsurface will take either,
you'll then get duplicate gas mix events.
It's not like that is in any way fatal, but it might be a bit confusing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of creating the individual parsers, and keeping track of their
arguments, this just uses the "new" dc_parser_new2 function ment for
buffer parsing.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
This removes our own declaration of dc_descriptor_t and all our accesses
to its internals, and switches to use the libdivecomputer functions to
access those instead.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
This renames and cleans up ostc_get_data_descriptor into get_descriptor,
for more generic use.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is for later reuse of that function in other source files.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Linus pointed out that it might be another call site (and looking at his
proposed patch I noticed a logic error in my earlier attempt)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a simple cp2130 userspace driver. Its probably unusable in the
real world but its a great base to build upon.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This rewrites the custom serial code to use the new api which I
implemented in the Subsurface-branch of libdivecomputer.
This is a bit to big patch but I haven't had the time to break it down
into more sensible patches.
This rewrite enables us to support more ftdi based divecomputer
communication and is tested with both a OSTC3, OSTC2N and a Suunto
Vyper, all over the libftdi driver.
The bluetooth code paths are tested to, and should work as before.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We used to clear the 'dc_tank_t' for each dive, but then only clear the
volume field in between each cylinder. That means that if the
libdivecomputer back-end does not touch a field, it might contain the
stale value from the previous tank information.
I'm not sure this is actually much of an issue, since I'd expect
back-ends do seem to initialize the fields fully (at least the EON Steel
back-end does). But it's inconsistent.
Also, the code was actually buggy because of the odd indentation: it
would only ask for new tank information up to 'ntanks' tanks, but
because of the final fixup that was done outside of the conditional, it
would actually update the cylinder begin/end pressure data *beyond*
'ntanks', and just re-use the last libdivecomputer data for the rest of
the cylinders.
Again, in practice, that probably never really happened, but it is a
real bug.
The fixed-up code actually looks better too, imho, and is one line
shorter because of the initialization now being done in one place rather
than two.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In subsurface, we only have one cylinder pressure per sample (well,
technically two: we have a separate o2 pressure for rebreather diving).
Which makes things "interesting" if the dive computer can actually have
multiple pressure sensors, and can report them all concurrently. Like
the Suunto EON Steel.
We used to just take the last one (each sensor reading would just
overwrite any previous ones), and this quick hack just changes the logic
to prefer the "current" cylinder instead.
It's wrong, and it's stupid, but it's the best we can do without major
surgery.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of having fixed numbers and trying to translate them into
strings, a dive computer could just give us the string directly. Like
the new EON Steel backend does.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This uses the extended tank type information to fill in the cylinder use
(OC gas, CC Diluent or CC O2) from libdivecomputer when available.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We have two different models for setting the deviceid associated with a
dive computer: either take the value from the libdivecomputer 'devinfo'
field (from the DC_EVENT_DEVINFO event), or generate the device ID by
just hashing the serial number string.
The one thing we do *not* want to have, is to use both methods, so that
the same device generates different device IDs. Because then we'll
think we have two different dive computers even though they are one and
the same.
Usually, this is not an issue, because libdivecomputer either sends the
DEVINFO event or gives us the serial number string, and we'll always
just pick one or the other.
However, in the case of at least the Suunto EON Steel, I intentionally
did *not* send the DC_EVENT_DEVINFO event, because it gives no useful
information. We used the serial number string to generate a device ID,
and everything was fine.
However, in commit d40cdb4755ee ("Add the devinfo event") in the
libdivecomputer tree, Jeff started generating those DC_EVENT_DEVINFO
events for the EON Steel too, and suddenly subsurface would start using
a device ID based on that instead.
The situation is inherently ambiguous - for the EON Steel, we want to
use the hash of the serial number (because that is what we've
historically done), but other dive computers might want to use the
DEVINFO data (because that is what _those_ backends have historically
done, even if they might also implement the new serial string model).
This commit makes subsurface resolve this ambiguity by simply preferring
whatever previous device ID it has associated with that particular
serial number string. If you have no previous device IDs, it doesn't
matter which one you pick.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
