aboutsummaryrefslogtreecommitdiffstats
path: root/core/libdivecomputer.c
AgeCommit message (Collapse)Author
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>
2016-05-31Don't ignore surface events from libdivecomputerGravatar Linus Torvalds
There are cases where we actually want to keep them, as exemplified by this situation from Richard Yorke: "I have just come across a situation when ignoring the surface marker is a disadvantage. I have just had a problem with my BC feed seeping, slowly filling my BC and as I control my buoyancy on the bottom using the air in my drysuit, I did not notice, so that when I came to ascend the expanding air in my BC caused a loss of control. Fortunately not from a great depth and no untoward consequences. However, the Subsurface profile only shows me rising to 4m and descending to 5.5m for my safety stop. However I actually broke the surface and descented to 5.5 but the frequency of recording depth was not fast enough to show this as it was so brief" so remove the code that ignores the surface events entirely. I think we'll have to come up with some smarter filtering model for showing them, but that is predicated on getting these events to come through in the first place. Reported-by: Richard Yorke <yorke.richard@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2016-04-04Move subsurface-core to core and qt-mobile to mobile-widgetsGravatar Dirk Hohndel
Having subsurface-core as a directory name really messes with autocomplete and is obviously redundant. Simmilarly, qt-mobile caused an autocomplete conflict and also was inconsistent with the desktop-widget name for the directory containing the "other" UI. And while cleaning up the resulting change in the path name for include files, I decided to clean up those even more to make them consistent overall. This could have been handled in more commits, but since this requires a make clean before the build, it seemed more sensible to do it all in one. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>