aboutsummaryrefslogtreecommitdiffstats
path: root/core/libdivecomputer.c
AgeCommit message (Collapse)Author
2017-09-28Save Subsurface version to libdivecomputer logfileGravatar Miika Turkia
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
2017-09-20DC download: fix 'no new dives' messageGravatar Dirk Hohndel
Stupidly, commit 731d9dc9bdf ("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>
2017-09-17DC download: tell user when no new dives were foundGravatar Dirk Hohndel
Otherwise it almost looks like something went wrong with the download. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-08-21Improve error message when opening dive computer failsGravatar Dirk Hohndel
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>
2017-07-25Make sample pressure helper functions available to everybodyGravatar Linus Torvalds
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>
2017-07-25Try to sanely download multiple concurrent cylinder pressuresGravatar Linus Torvalds
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>
2017-07-21Start cleaning up sensor indexing for multiple sensorsGravatar Linus Torvalds
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>
2017-07-20Unify sample pressure and o2pressure as pressure[2] arrayGravatar Linus Torvalds
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>
2017-07-17Resolve type confusionGravatar Dirk Hohndel
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>
2017-07-09Tell user if we reached a dive that was already thereGravatar Dirk Hohndel
This way it's more obvious why no dives were downloaded. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-09More meaningful device info displayGravatar Dirk Hohndel
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>
2017-07-09Revert "Add support for tank sensor battery for Perdix AI"Gravatar Dirk Hohndel
This reverts commit ed43b5dcedd150235cdc1ac5e5aedecb62f1c657 ("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>
2017-07-09QML UI: add dev_info data to AppLogGravatar Dirk Hohndel
This should make it easier to tell how far we get downloading data from dive computers. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-08If we detect a different model than expected, use itGravatar Dirk Hohndel
This is useful if the underlying code in libdivecomputer can reliably detect specific hardware models. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-07Add support for tank sensor battery for Perdix AIGravatar Dirk Hohndel
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>
2017-06-27Update Subsurface-branch of libdivecomputer checkGravatar Dirk Hohndel
We now require the Subsurface-branch, and at least version 2 of the Subsurface API of libdivecomputer. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-06-27Switch over to SSRF_CUSTOM_IO v2Gravatar Linus Torvalds
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>
2017-06-22Warn when not compiling against the matching libdc versionGravatar Dirk Hohndel
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-06-22Convert to new libdivecomputer custom IO modelGravatar Linus Torvalds
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>
2017-05-29FTDI support: add minimal debugging outputGravatar Dirk Hohndel
Copied the libdivecomputer macros for convenience. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-05-29More optimal searchGravatar Jan Mulder
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>
2017-04-29Add SPDX header to core C filesGravatar Dirk Hohndel
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-04-24Do not carry po2 setpoint data over dive boundariesGravatar Jan Mulder
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>
2017-04-13Cleanup some unnecessary include statementsGravatar Jef Driesen
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>
2017-03-30Shift fake tank pressures up by 30barGravatar Dirk Hohndel
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>
2017-03-29Accept 0 as valid endpressure for Uwatec devicesGravatar Dirk Hohndel
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>
2017-03-12Only enable -Wmissing-field-initializers for ClangGravatar Lubomir I. Ivanov
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>
2017-03-11Merge branch 'master' of https://github.com/dje29/subsurfaceGravatar Dirk Hohndel
2017-03-11divemode > dive modeGravatar Martin Měřinský
2017-03-09Fix potential double/float to int rounding errorsGravatar Jeremie Guichard
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>
2017-03-08Change calls to rint into lrint avoiding conversion warningsGravatar Jeremie Guichard
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>
2017-02-03Correct: Handle more tanks than gasmixesGravatar Robert Helling
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>
2017-02-02Handle more tanks than gasmixesGravatar Robert C. Helling
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>
2017-01-17Make event string translation when downloading from libdivecomputer more obviousGravatar Linus Torvalds
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>
2017-01-16Add support for libdivecomputer using DC_SAMPLE_GASMIXGravatar Linus Torvalds
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>
2017-01-12ostctools_import: Switch to using dc_parser_new2Gravatar Anton Lundin
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>
2017-01-12Stop accessing the internals of dc_descriptor_tGravatar Anton Lundin
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>
2016-12-28Rename ostc_get_data_descriptor to get_descriptorGravatar Anton Lundin
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>
2016-12-28Lift ostc_get_data_descriptor out from ostctools.cGravatar Anton Lundin
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>
2016-09-22Revert "Add a simple cp2130 libusb driver"Gravatar Dirk Hohndel
This reverts commit 93ef223a3131db838abc7c390ddce3fae8be5f7c.
2016-09-20Second attempt to fix crashGravatar Dirk Hohndel
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>
2016-09-20Prevent possible NULL pointer dereferenceGravatar Dirk Hohndel
Not sure if this will fix the crash for Henrik, but it's worth a try. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2016-09-18Add a simple cp2130 libusb driverGravatar Anton Lundin
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>
2016-09-17Rewrite libdivecomputer custom serial codeGravatar Anton Lundin
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>
2016-08-29Make sure DC_FIELD_TANK starts from a clean slate for each cylinderGravatar Linus Torvalds
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>
2016-08-29Hacky workaround for multiple gas pressures per sampleGravatar Linus Torvalds
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>
2016-07-21Add support for SAMPLE_EVENT_STRING event typeGravatar Linus Torvalds
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>
2016-07-21Get the cylinder use data from libdivecomputer if providedGravatar Linus Torvalds
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>
2016-06-20Avoid unused argument warningsGravatar Dirk Hohndel
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2016-06-20Preferentially use existing device ID when setting serial numberGravatar Linus Torvalds
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>