2017-04-27 18:24:53 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2013-05-04 20:24:23 +00:00
|
|
|
#ifndef PROFILE_H
|
|
|
|
|
#define PROFILE_H
|
|
|
|
|
|
2016-02-02 02:00:49 +00:00
|
|
|
#include "dive.h"
|
|
|
|
|
|
2013-05-04 20:24:23 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
2014-02-28 04:09:57 +00:00
|
|
|
typedef enum {
|
|
|
|
|
STABLE,
|
|
|
|
|
SLOW,
|
|
|
|
|
MODERATE,
|
|
|
|
|
FAST,
|
|
|
|
|
CRAZY
|
|
|
|
|
} velocity_t;
|
2013-05-04 22:36:40 +00:00
|
|
|
|
2014-01-19 00:21:13 +00:00
|
|
|
struct membuffer;
|
2013-05-04 20:24:23 +00:00
|
|
|
struct divecomputer;
|
|
|
|
|
struct plot_info;
|
2013-05-04 22:36:40 +00:00
|
|
|
struct plot_data {
|
2014-02-28 04:09:57 +00:00
|
|
|
unsigned int in_deco : 1;
|
2016-03-10 15:37:18 +00:00
|
|
|
int sec;
|
Profile support for multiple concurrent pressure sensors
This finally handles multiple cylinder pressures, both overlapping and
consecutive, and it seems to work on the nasty cases I've thrown at it.
Want to just track five different cylinders all at once, without any
pesky gas switch events? Sure, you can do that. It will show five
different gas pressures for your five cylinders, and they will go down
as you breathe down the cylinders.
I obviously don't have any real data for that case, but I do have a test
file with five actual cylinders that all have samples over the whole
course of the dive. The end result looks messy as hell, but what did
you expect?
HOWEVER.
The only way to do this sanely was
- actually make the "struct plot_info" have all the cylinder pressures
(so no "sensor index and pressure" - every cylinder has a pressure for
every plot info entry)
This obviously makes the plot_info much bigger. We used to have
MAX_CYLINDERS be a fairly generous 8, which seems sane. The planning
code made that 8 be 20. That seems questionable. But whatever.
The good news is that the plot-info should hopefully get freed, and
only be allocated one dive at a time, so the fact that it is big and
nasty shouldn't be a scaling issue, though.
- the "populate_pressure_information()" function had to be rewritten
quite a bit. The good news is that it's actually simpler now, although
I would not go so far as to really call it simple. It's still
complicated and suble, but now it explicitly just does one cylinder at
a time.
It *used* to have this insanely complicated "keep track of the pressure
ranges for every cylinder at once". I just couldn't stand that model
and keep my sanity, so it now just tracks one cylinder at a time, and
doesn't have an array of live data, instead the caller will just call
it for each cylinder.
- get rid of some of our hackier stuff, like the code that populates the
plot_info data code with the currently selected cylinder number, and
clears out any other pressures. That obviously does *not* work when you
may not have a single primary cylinder any more.
Now, the above sounds like all good things. Yeah, it mostly is.
BUT.
There's a few big downsides from the above:
- there's no sane way to do this as a series of small changes.
The change to make the plot_info take an array of cylinder pressures
rather than the sensor+pressure model really isn't amenable to "fix up
one use at a time". When you switch over to the new data structure
model, you have to switch over to the new way of populating the
pressure ranges. The two just go hand in hand.
- Some of our code *depended* on the "sensor+pressure" model. I fixed all
the ones I could sanely fix. There was one particular case that I just
couldn't sanely fix, and I didn't care enough about it to do something
insane.
So the only _known_ breakage is the "TankItem" profile widget. That's
the bar at the bottom of the profile that shows which cylinder is in
use right now. You'd think that would be trivial to fix up, and yes it
would be - I could just use the regular model of
firstcyl = explicit_first_cylinder(dive, dc)
.. then iterate over the gas change events to see the others ..
but the problem with the "TankItem" widget is that it does its own
model, and it has thrown away the dive and the dive computer
information. It just doesn't even know. It only knows what cylinders
there are, and the plot_info. And it just used to look at the sensor
number in the plot_info, and be done with that. That number no longer
exists.
- I have tested it, and I think the code is better, but hey, it's a
fairly large patch to some of the more complex code in our code base.
That "interpolate missing pressure fields" code really isn't pretty. It
may be prettier, but..
Anyway, without further ado, here's the patch. No sign-off yet, because I
do think people should look and comment. But I think the patch is fine,
and I'll fix anythign that anybody can find, *except* for that TankItem
thing that I will refuse to touch. That class is ugly. It needs to have
access to the actual dive.
Note how it actually does remove more lines than it adds, and that's
despite added comments etc. The code really is simpler, but there may be
cases in there that need more work.
Known missing pieces that don't currently take advantage of concurrent
cylinder pressure data:
- the momentary SAC rate coloring for dives will need more work
- dive merging (but we expect to generally normally not merge dive
computers, which is the main source of sensor data)
- actually taking advantage of different sensor data from different
dive computers
But most of all: Testing. Lots and lots of testing to find all the
corner cases.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-27 17:17:05 +00:00
|
|
|
/*
|
|
|
|
|
* pressure[x][0] is sensor pressure for cylinder x
|
2017-07-20 21:39:02 +00:00
|
|
|
* pressure[x][1] is interpolated pressure
|
|
|
|
|
*/
|
Profile support for multiple concurrent pressure sensors
This finally handles multiple cylinder pressures, both overlapping and
consecutive, and it seems to work on the nasty cases I've thrown at it.
Want to just track five different cylinders all at once, without any
pesky gas switch events? Sure, you can do that. It will show five
different gas pressures for your five cylinders, and they will go down
as you breathe down the cylinders.
I obviously don't have any real data for that case, but I do have a test
file with five actual cylinders that all have samples over the whole
course of the dive. The end result looks messy as hell, but what did
you expect?
HOWEVER.
The only way to do this sanely was
- actually make the "struct plot_info" have all the cylinder pressures
(so no "sensor index and pressure" - every cylinder has a pressure for
every plot info entry)
This obviously makes the plot_info much bigger. We used to have
MAX_CYLINDERS be a fairly generous 8, which seems sane. The planning
code made that 8 be 20. That seems questionable. But whatever.
The good news is that the plot-info should hopefully get freed, and
only be allocated one dive at a time, so the fact that it is big and
nasty shouldn't be a scaling issue, though.
- the "populate_pressure_information()" function had to be rewritten
quite a bit. The good news is that it's actually simpler now, although
I would not go so far as to really call it simple. It's still
complicated and suble, but now it explicitly just does one cylinder at
a time.
It *used* to have this insanely complicated "keep track of the pressure
ranges for every cylinder at once". I just couldn't stand that model
and keep my sanity, so it now just tracks one cylinder at a time, and
doesn't have an array of live data, instead the caller will just call
it for each cylinder.
- get rid of some of our hackier stuff, like the code that populates the
plot_info data code with the currently selected cylinder number, and
clears out any other pressures. That obviously does *not* work when you
may not have a single primary cylinder any more.
Now, the above sounds like all good things. Yeah, it mostly is.
BUT.
There's a few big downsides from the above:
- there's no sane way to do this as a series of small changes.
The change to make the plot_info take an array of cylinder pressures
rather than the sensor+pressure model really isn't amenable to "fix up
one use at a time". When you switch over to the new data structure
model, you have to switch over to the new way of populating the
pressure ranges. The two just go hand in hand.
- Some of our code *depended* on the "sensor+pressure" model. I fixed all
the ones I could sanely fix. There was one particular case that I just
couldn't sanely fix, and I didn't care enough about it to do something
insane.
So the only _known_ breakage is the "TankItem" profile widget. That's
the bar at the bottom of the profile that shows which cylinder is in
use right now. You'd think that would be trivial to fix up, and yes it
would be - I could just use the regular model of
firstcyl = explicit_first_cylinder(dive, dc)
.. then iterate over the gas change events to see the others ..
but the problem with the "TankItem" widget is that it does its own
model, and it has thrown away the dive and the dive computer
information. It just doesn't even know. It only knows what cylinders
there are, and the plot_info. And it just used to look at the sensor
number in the plot_info, and be done with that. That number no longer
exists.
- I have tested it, and I think the code is better, but hey, it's a
fairly large patch to some of the more complex code in our code base.
That "interpolate missing pressure fields" code really isn't pretty. It
may be prettier, but..
Anyway, without further ado, here's the patch. No sign-off yet, because I
do think people should look and comment. But I think the patch is fine,
and I'll fix anythign that anybody can find, *except* for that TankItem
thing that I will refuse to touch. That class is ugly. It needs to have
access to the actual dive.
Note how it actually does remove more lines than it adds, and that's
despite added comments etc. The code really is simpler, but there may be
cases in there that need more work.
Known missing pieces that don't currently take advantage of concurrent
cylinder pressure data:
- the momentary SAC rate coloring for dives will need more work
- dive merging (but we expect to generally normally not merge dive
computers, which is the main source of sensor data)
- actually taking advantage of different sensor data from different
dive computers
But most of all: Testing. Lots and lots of testing to find all the
corner cases.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-27 17:17:05 +00:00
|
|
|
int pressure[MAX_CYLINDERS][2];
|
2013-05-04 22:36:40 +00:00
|
|
|
int temperature;
|
|
|
|
|
/* Depth info */
|
|
|
|
|
int depth;
|
|
|
|
|
int ceiling;
|
2013-05-30 18:56:00 +00:00
|
|
|
int ceilings[16];
|
2014-09-15 12:09:00 +00:00
|
|
|
int percentages[16];
|
2013-05-04 22:36:40 +00:00
|
|
|
int ndl;
|
2014-07-09 20:13:36 +00:00
|
|
|
int tts;
|
Add support for RBT reported sample value
RBT (Remaining Bottom Time) is a value calculated on the fly by some air
integrated divecomputers, for example Uwatec devices. This value is an
estimation based in some heuristic around time function pressure
gradients. This way, RBT would be the time a diver can spend at actual
depth without running out of gas (taking account of ascent, deco, if
required, and rock bottom gas reserve, if set).
Older Uwatec devices just made the calculus and only stored alarm events
if this time value reached zero, but modern devices store the value each
sample, in minutes.
It seems that Suunto Eon Steel is storing RBT values too, in seconds.
Libdivecomputer has supported RBT for a while, but Subsurface just
printed it to stdout and dropped it.
This adds support for RBT value on subsurface sample structure and shows
it in the profile's info box, right under TTS(calc), if selected, where
these two values can be easily compared by humans.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2015-07-22 15:02:33 +00:00
|
|
|
int rbt;
|
2013-05-04 22:36:40 +00:00
|
|
|
int stoptime;
|
|
|
|
|
int stopdepth;
|
|
|
|
|
int cns;
|
|
|
|
|
int smoothed;
|
2013-10-14 21:48:43 +00:00
|
|
|
int sac;
|
2014-12-12 13:30:13 +00:00
|
|
|
int running_sum;
|
2014-09-15 12:55:20 +00:00
|
|
|
struct gas_pressures pressures;
|
2014-11-18 09:30:24 +00:00
|
|
|
pressure_t o2pressure; // for rebreathers, this is consensus measured po2, or setpoint otherwise. 0 for OC.
|
|
|
|
|
pressure_t o2sensor[3]; //for rebreathers with up to 3 PO2 sensors
|
2015-01-05 07:20:26 +00:00
|
|
|
pressure_t o2setpoint;
|
2013-05-04 22:36:40 +00:00
|
|
|
double mod, ead, end, eadd;
|
|
|
|
|
velocity_t velocity;
|
2013-09-25 00:07:07 +00:00
|
|
|
int speed;
|
2016-04-20 22:55:51 +00:00
|
|
|
// stats over 9 minute window:
|
|
|
|
|
int min, max; // indices into pi->entry[]
|
2013-11-13 18:20:09 +00:00
|
|
|
/* values calculated by us */
|
2014-02-28 04:09:57 +00:00
|
|
|
unsigned int in_deco_calc : 1;
|
2013-11-13 18:20:09 +00:00
|
|
|
int ndl_calc;
|
|
|
|
|
int tts_calc;
|
|
|
|
|
int stoptime_calc;
|
|
|
|
|
int stopdepth_calc;
|
2014-01-01 12:35:16 +00:00
|
|
|
int pressure_time;
|
2014-01-17 22:00:28 +00:00
|
|
|
int heartbeat;
|
|
|
|
|
int bearing;
|
2014-09-15 12:09:00 +00:00
|
|
|
double ambpressure;
|
|
|
|
|
double gfline;
|
2017-05-12 13:36:24 +00:00
|
|
|
double density;
|
2013-05-04 22:36:40 +00:00
|
|
|
};
|
2014-08-24 18:48:22 +00:00
|
|
|
|
|
|
|
|
struct ev_select {
|
|
|
|
|
char *ev_name;
|
|
|
|
|
bool plot_ev;
|
|
|
|
|
};
|
|
|
|
|
|
2015-01-23 19:05:32 +00:00
|
|
|
struct plot_info calculate_max_limits_new(struct dive *dive, struct divecomputer *given_dc);
|
2013-09-25 00:07:07 +00:00
|
|
|
void compare_samples(struct plot_data *e1, struct plot_data *e2, char *buf, int bufsize, int sum);
|
2014-01-14 18:43:58 +00:00
|
|
|
struct plot_data *populate_plot_entries(struct dive *dive, struct divecomputer *dc, struct plot_info *pi);
|
|
|
|
|
struct plot_info *analyze_plot_info(struct plot_info *pi);
|
2017-11-24 13:17:01 +00:00
|
|
|
void create_plot_info_new(struct dive *dive, struct divecomputer *dc, struct plot_info *pi, bool fast, struct deco_state *planner_ds);
|
|
|
|
|
void calculate_deco_information(struct deco_state *ds, struct deco_state *planner_de, struct dive *dive, struct divecomputer *dc, struct plot_info *pi, bool print_mode);
|
2016-03-10 15:37:18 +00:00
|
|
|
struct plot_data *get_plot_details_new(struct plot_info *pi, int time, struct membuffer *);
|
2013-05-04 20:24:23 +00:00
|
|
|
|
2013-05-04 22:20:49 +00:00
|
|
|
/*
|
|
|
|
|
* When showing dive profiles, we scale things to the
|
|
|
|
|
* current dive. However, we don't scale past less than
|
|
|
|
|
* 30 minutes or 90 ft, just so that small dives show
|
|
|
|
|
* up as such unless zoom is enabled.
|
|
|
|
|
* We also need to add 180 seconds at the end so the min/max
|
|
|
|
|
* plots correctly
|
|
|
|
|
*/
|
|
|
|
|
int get_maxtime(struct plot_info *pi);
|
|
|
|
|
|
|
|
|
|
/* get the maximum depth to which we want to plot
|
|
|
|
|
* take into account the additional verical space needed to plot
|
|
|
|
|
* partial pressure graphs */
|
|
|
|
|
int get_maxdepth(struct plot_info *pi);
|
|
|
|
|
|
2013-05-09 03:24:03 +00:00
|
|
|
#define SENSOR_PR 0
|
|
|
|
|
#define INTERPOLATED_PR 1
|
Start cleaning up sensor indexing for multiple sensors
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-21 02:49:45 +00:00
|
|
|
#define SENSOR_PRESSURE(_entry,_idx) (_entry)->pressure[_idx][SENSOR_PR]
|
|
|
|
|
#define INTERPOLATED_PRESSURE(_entry,_idx) (_entry)->pressure[_idx][INTERPOLATED_PR]
|
|
|
|
|
#define GET_PRESSURE(_entry,_idx) (SENSOR_PRESSURE(_entry,_idx) ? SENSOR_PRESSURE(_entry,_idx) : INTERPOLATED_PRESSURE(_entry,_idx))
|
2014-02-28 04:09:57 +00:00
|
|
|
#define SAC_WINDOW 45 /* sliding window in seconds for current SAC calculation */
|
2013-05-09 03:24:03 +00:00
|
|
|
|
2013-05-04 20:24:23 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2014-02-11 18:14:46 +00:00
|
|
|
#endif // PROFILE_H
|
