Instead of adding all gases read from a dive computer as part of a dive
log as 'OC-gas', add gases as 'diluent' if the dive has a dive mode of
'CCR'. This creates consistency with the ppO2 for CCR dives being
tracked as sensor readings or a fixed setpoint, and not as the ppO2 of
the current gas ad depth.
A follow up question from this is whether gas use in the cylinders list
on the Equipment tab should be user editable. This seems to be
inconsistent at the moment, with gas constituent percentages downloaded
from the dive computer being editable, but gas use not.
Signed-off-by: Michael Keller <github@ike.ch>
The FP_IS_SAME macro uses a relative precision to compare
floating points. This fails when comparing to 0. Therefore,
use an absolute precision in this case. Implement as an
inline function.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
One would think that calling free() on a dive structure, as the code
did in some places, would lead to a memory leak.
(Insert rant about C memory management.)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
It appears to send a first sample with a water temperature of 0 C. If the next
sample contains a more likely water temperature, overwrite the first one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
libdivecomputer tries to be super careful in what it tells us. It only offers a
density value if that is something that the dive computer explicitly supports,
otherwise it just offers back a flag. We need to then update the density value
ourselves.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The only things in display.h were profile related, so the
split between these two files is not comprehensible.
In fact profile.h includes display.h, because it needs the
struct defined therein. Let's just merge these two files.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In order to not break existing behavior, we still store fingerprints on disk, but
we first check the data in the in-memory table, and we remember the fingerprint data
in the fingerprint table as well (which is then saved as part of the dive log data).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Most divecomputers download data dive by dive - so we get reasonably
frequent updates during the download (as new dives are found and posted
in the progress text area). But some (like the G2) download all of the
new dives at once and only then start parsing them. As a result the
download can look like it is hung.
As a compromise this shows updates on the data received in 10kB
increments. Which for most cases should never be shown and therefore not
make the user experience any worse - but for cases like the G2 will make
a huge difference.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This tries to make our fingerprinting code work better, by avoiding
using the "deviceid" field that has always been unreliable because we've
calculated it multiple different ways, and even for the same version of
subsurface, it ends up changing in the middle (ie we calculate one value
initially, then re-calculate it when we have a proper serial number
string).
So instead, the fingerprinting code will look up and save the
fingerprint file using purely "stable" information that is available
early during the download:
- the device model name (which is a string with vendor and product name
separated by a space)
- the DC_EVENT_DEVINFO 32-bit 'serial' number (which is not necessarily
a real serial number at all, but hopefully at least a unique number
for the particular product)
but because the model name is not necessarily a good filename (think
slashes and other possibly invalid characters), we hash that model name
and use the resulting hex number in the fingerprint file name.
This way the fingerprint file is unambiguous at load and save time, and
depends purely on libdivecomputer data.
But because we also need to verify that we have the actual _dive_
associated with that fingerprint, we also need to save the final
deviceid and diveid when saving the fingerprint file, so that when we
load it again we can look up the dive and verify that we have it before
we use the fingerprint data.
To do that, the fingerprint file itself contains not just the
fingerprint data from libdivecomputer, but the last 8 bytes of the file
are the (subsurface) deviceid and the diveid of the dive that is
associated with the fingerprint.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When we save the divecomputer data, we never actually save the serial
value as a field. We used to rely on saving the very dodgy 'deviceid',
and then look up the serial number from there. And that never really
worked reliably, but we didn't really notice, because we never really
_used_ the serial number anywhere.
The only place the serial number is actually reliably displayed is in
the "Extra data" tab, which contains the key value pairs, and that's
where the original dive download code got the serial number from.
So just parse that at load time too, the same way we parsed it at dive
download time.
In fact, do the firmware version the same way, and remove the code from
the downloader, since it too can rely on 'add_extra_data()' just picking
up the information directly.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We have this odd legacy notion of a divecomputer 'device', that was
originally just basically the libdivecomputer 'EVENT_DEVINFO' report
that was associated with each dive. So it had firmware version,
deviceid, and serial number.
It had also gotten extended to do 'nickname' handling, and it was all
confusing, ugly and bad. It was particularly bad because it wasn't
actually a 'per device' thing at all: due to the firmware field, a dive
computer that got a firmware update forced a new 'device'.
To make matters worse, the 'deviceid' was also almost random, because
we've calculated it a couple of different ways, and libdivecomputer
itself has changed how the legacy 32-bit 'serial number' is expressed.
Finally, because of all these issues, we didn't even try to make the
thing unique, so it really ended up being a random snapshot of the state
of the dive computer at the time of a dive, and sometimes we'd pick one,
and sometimes another, since they weren't really well-defined.
So get rid of all this confusion.
The new rules:
- the actual random dive computer state at the time of a dive is kept
in the dive data. So if you want to know the firmware version, it
should be in the 'extra data'
- the only serial number that matters is the string one in the extra
data, because that's the one that actually matches what the dive
computer reports, and isn't some random 32-bit integer with ambiguous
formatting.
- the 'device id' - the thing we match with (together with the model
name, eg "Suunto EON Steel") is purely a hash of the real serial
number.
The device ID that libdivecomputer reports in EVENT_DEVINFO is
ignored, as is the device ID we've saved in the XML or git files. If
we have a serial number, the device ID will be uniquely associated
with that serial number, and if we don't have one, the device ID will
be zero (for 'match anything').
So now 'deviceid' is literally just a shorthand for the serial number
string, and the two are joined at the hip.
- the 'device' managament is _only_ used to track devices that have
serial numbers _and_ nicknames. So no more different device
structures just because one had a nickname and the other didn't etc.
Without a serial number, the device is 'anonymous' and fundamentally
cannot be distinguished from other devices of the same model, so a
nickname is meaningless. And without a nickname, there is no point in
creating a device data structure, since all the data is in the dive
itself and the device structure wouldn't add any value..
These rules mean that we no longer have ambiguous 'device' structures,
and we can never have duplicates that can confuse us.
This does mean that you can't give a nickname to a device that cannot be
uniquely identified with a serial number, but those are happily fairly
rare (and mostly older ones). Dirk said he'd look at what it takes to
give more dive computers proper serial numbers, and I already did it for
the Garmin Descent family yesterday.
(Honesty in advertizing: right now you can't add a nickname to a dive
computer that doesn't already have one, because such a dive computer
will not have a device structure. But that's a UI issue, and I'll sort
that out separately)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Since dive.c is so huge, split out divecomputer-related functions
into divecomputer.[c|h], sample.[c|h] and extradata.[c|h].
This does not give huge compile time improvements, since
struct dive contains a struct divecomputer and therefore
dive.h has to include divecomputer.h. However, it make things
distinctly more clear.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In an effort to reduce the size of dive.h and dive.c, break out
the event related functions. Moreover event-names were handled
by the profile-code, collect that also in the new source files.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In the specuial case of suunto, where we may add a device directly
instead of via dive->dc, add the device to the provided table.
The caller will then pass on the new device to the undo system.
This makes downloading finally really undoable (at least I
hope so). So far, the dives and dive sites were removed, but any
new device remained.
However, when setting the device-id via serial, we now have
to check both, the global and the downloaded list of devices.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Apparently libdc gives us copies of strings. The API is very
scary, because (at least according to my reading of the code),
the key/value pair may be stored in a cache. Thus on free()ing
the string in the cache becomes invalid and we must not access
it twice. Very obscure.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of accessing the global device table directly, add a parameter
to all device-table accessing functions. This makes all places in
the code that access the global device table grep-able, which is
necessary to include the device-table code in the undo system.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Searching the proper device for the divecomputer was done via a
callback. Very hard to follow code. Since we can now access
"struct device" from C, obtain it directly via get_device_for_dc().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was only set but never read. Therefore, remove it. Divecomputer
serial numbers are now handled via a string-based interface.
We can't remove the integer-based firmware number, because that is
still used by the OSTC firmware check in ConfigureDiveComputerDialog.
Let's not risk breaking that.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This dates from 2014 - this should be obsolete: we certainly don't
support such old libdivecomputer versions. Moreover, we bundle our
own anyway.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of just sending this to the user through the progress bar text, also
send things to stderr in verbose mode. That should make it easier to debug
situations where we fail to download from a dive computer.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I think we only have one dive computer that supports GPS data right now:
the Garmin Descent Mk1. It reports the dive coordinates as "GPS1" and
"GPS2" for the entry point and exit point respectively.
Often GPS1 is missing, because the dive computer may not have gotten a
GPS lock before the diver jumped into the water, so when that happens
we'll use GPS2 for the dive site location. But when GPS1 exists, we
should prefer that.
And that's what we already did in logic in dc_get_gps_location(), but
for the initial dive site created at download time, we just picked any
divecomputer reported string that started with "GPS". And since GPS2 is
reported after GPS1 by the Garmin Descent, it would end up overwriting
the entry point that we _should_ have preferred.
Add the same kind of "explicitly prefer GPS1" logic to the initial dive
download case as we already had elsewhere.
Reported-by: @brysconsulting
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
For Android the Qt Bluetooth code seems to work just fine. And for macOS
nothing appears to work right now, but at least the Qt implementation compiles
and links.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The Qt based implementation apparently got broken at some point and now fails
to connect to rfcomm dive computers like the Shearwater Petrel.
This uses the libdivecomputer rfcomm backend. Tested to work with bluez on
Linux as well as with the native Windows implementation.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The libdivecomputer internals changed for USB devices, and now we need
to scan the USB devices before calling libdivecomputer. That's the same
pattern as for USBHID and IRDA, so let's just regularize this all.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Apparently libdivecomputer can return DC_GASMIX_UNKNOWN when
fetching tank info with
dc_parser_get_field(parser, DC_FIELD_TANK, i, &tank);
This caused emission of a warning, which was annoying users.
Disable the warning in that case.
Fixes#2866
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
No point in slurping in all of dive.h for translation units that only
want to do some time manipulation without ever touching a dive.
Don't call the header "time.h", because we don't want to end up in a
confusion with the system header of the same name.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This will be temporarilly used by the planner to mark consumption of
air at the surface. Do this by creating a new function add_cylinder,
which replaces add_to_cylinder_table() and takes care of always adding
a dummy cylinder at the end of the table. Make the original
add_to_cylinder_table() local, so that it cannot be accessed anymore.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This finally allows us to download from not just the first device, but specifically
the device that the user picks.
Passing the object through a void pointer is not nice - but since this traverses
C code other solutions (like passing an index into the list) seemed even worse.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since I learned while trying to implement this that getting sub-second
resolution time in portable C99 is hard (especially for someone who is
used to the comfort of std::chrono and Howard Hinnants date library) the
timer-implemetation from libdivecomputer is now copied to the subsurface
source.
Signed-off-by: Christof Arnosti <charno@charno.ch>
We know that we cannot support native USB, USB HID, IRDA, and USB
storage on Android.
On the flip side, don't try to force the long broken FTDI download.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Implement the libdivecomputer API in Java and create C/JNI translation
layer.
[Dirk Hohndel: whitespace harmonization - yes, some of this is Java,
this still makes it much easier to read for me;
also changed the FTDI conditional compilation to make
sure we can still use that for mobile-on-desktop if
necessary]
Signed-off-by: Christof Arnosti <charno@charno.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of using fixed size arrays, use a new cylinder_table structure.
The code copies the weightsystem code, but is significantly more complex
because cylinders are such an integral part of the core.
Two functions to access the cylinders were added:
get_cylinder() and get_or_create_cylinder()
The former does a simple array access and supposes that the cylinder
exists. The latter is used by the parser(s) and if a cylinder with
the given id does not exist, cylinders up to that id are generated.
One point will make C programmers cringe: the cylinder structure is
passed by value. This is due to the way the table-macros work. A
refactoring of the table macros is planned. It has to be noted that
the size of a cylinder_t is 64 bytes, i.e. 8 long words on a 64-bit
architecture, so passing on the stack is probably not even significantly
slower than passing as reference.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In the previous commit, we just continued downloading dives when
download errors happened, but that also makes problems a lot easier to
miss because now they are possibly just transient reports in the
progress bar that get overwritten by the next dive being downloaded.
So this turns a number of these errors from using 'dev_info()' to use a
new 'download_error()' reporting model, which then uses the generic
subsurface error reporting functionality that is sticky and can handle
multiple errors.
It also adds a few 'dev_info()' calls for actual informational messages
about the state of downloading, although the new ones will probably
mainly end up happening before the progress bar is actually shown. But
it might improve on some of the progress messages.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Eric Charbonnier reported a problem downloading the dives from his
OSTC2, and Jef debugged the libdivecomputer log and says:
"Your ostc has 75 dives, but subsurface downloaded only one, and then
stopped the download. That's because that first dive appears to be
corrupt and fails to parse:
ERROR: Buffer overflow detected! [in /win/subsurface/libdivecomputer/src/hw_ostc_parser.c:981 (hw_ostc_parser_samples_foreach)]
Subsurface (incorrectly) considers that a fatal error and stops the
entire download. From a user point of view, it would be much better to
ignore the problematic dive, and continue downloading the remaining"
Subsurface used to just stop downloading if there were parsing errors,
but Jef further says:
"How parser errors are handled is up to the application. Aborting the
download is probably the worst option here. If a dive fails to parse
(because the dive data is corrupt, the parser contains a bug, etc),
that does not necessary mean the remaining dives can't be downloaded"
so let's change the logic to just continue downloading, and hope other
dives work better.
We might want to do better error reporting, right now the errors tend to
just cause "dev_info()" reports, which just set the progress bar text.
So you'll see it in the progress bar as it happens, but it won't get
really ever noted as an error, and it's easy to miss.
But that error reporting is a separate issue, and this just does the
"continue to the next dive" part.
Reported-by: Eric Charbonnier <eric.charbonnier69@gmail.com>
Suggested-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The fill_default_cylinder() function calculated the MOD based
on the currently displayed dive. This does not seem to make sense:
- When importing dives, why would we care about the altitude and
salinity of the currently displayed dive, possibly from a different
trip.
- The planner is supposed to be thread-safe and should not touch
global variables.
Of course this means that the importing-functions have to fill
out altitude and salinity before creating the default cylinder,
but this is their problem. For a freshly created dive they will
get the default values, which still seems less random than the
values from the displayed dive.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Move the declarations of the "report_error()" and "set_error_cb()"
functions and the "verbose" variable to errorhelper.h.
Thus, error-reporting translation units don't have to import the
big dive.h header file.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The parsers / downloaders parse into a separate table and do
not directly change the divelist. Therefore, they shouldn't
call mark_divelist_changed().
Likewise split_dive_at() doesn't modify the dive list and
therefore shouldn't call this function.
Calling the function has the unwanted side-effect that undoing
the change will not clear the *-symbol in the title of the
main window.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The parse_location() function was used in three places. In two
of them, the declaration was in the translation unit. Instead,
move the declaration into a header file, to avoid duplication
and the possibility of inconsistencies.
The "units.h" header was chosen as this is where location_t
is defined.
Moreover, make the string argument to parse_location() "const
char *", so that it can be used on non-owned buffers.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of setting dive->dive_site directly, call the
add_dive_to_dive_site() and unregister_dive_from_dive_site()
functions. In the parser this turned out to be a bit tricky.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a dive site table to each dive site to keep track of dives
that have been added to a dive site. Add two functions to add
dives to / remove dives from dive sites.
Since dive sites now contain a dive table, the order of includes
had to be changed: "divesite.h" now includes "dive.h" and not
vice-versa. This caused some include churn.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
