subsurface/core/gaspressures.c

486 lines
15 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0
/* gaspressures.c
* ---------------
* This file contains the routines to calculate the gas pressures in the cylinders.
* The functions below support the code in profile.c.
* The high-level function is populate_pressure_information(), called by function
* create_plot_info_new() in profile.c. The other functions below are, in turn,
* called by populate_pressure_information(). The calling sequence is as follows:
*
* populate_pressure_information() -> calc_pressure_time()
* -> fill_missing_tank_pressures() -> fill_missing_segment_pressures()
* -> get_pr_interpolate_data()
*
* The pr_track_t related functions below implement a linked list that is used by
* the majority of the functions below. The linked list covers a part of the dive profile
* for which there are no cylinder pressure data. Each element in the linked list
* represents a segment between two consecutive points on the dive profile.
* pr_track_t is defined in gaspressures.h
*/
#include "ssrf.h"
#include "dive.h"
#include "display.h"
#include "profile.h"
#include "gaspressures.h"
#include "pref.h"
/*
* simple structure to track the beginning and end tank pressure as
* well as the integral of depth over time spent while we have no
* pressure reading from the tank */
typedef struct pr_track_struct pr_track_t;
struct pr_track_struct {
int start;
int end;
int t_start;
int t_end;
int pressure_time;
pr_track_t *next;
};
typedef struct pr_interpolate_struct pr_interpolate_t;
struct pr_interpolate_struct {
int start;
int end;
int pressure_time;
int acc_pressure_time;
};
enum interpolation_strategy {SAC, TIME, CONSTANT};
static pr_track_t *pr_track_alloc(int start, int t_start)
{
pr_track_t *pt = malloc(sizeof(pr_track_t));
pt->start = start;
pt->end = 0;
pt->t_start = pt->t_end = t_start;
pt->pressure_time = 0;
pt->next = NULL;
return pt;
}
/* poor man's linked list */
static pr_track_t *list_last(pr_track_t *list)
{
pr_track_t *tail = list;
if (!tail)
return NULL;
while (tail->next) {
tail = tail->next;
}
return tail;
}
static pr_track_t *list_add(pr_track_t *list, pr_track_t *element)
{
pr_track_t *tail = list_last(list);
if (!tail)
return element;
tail->next = element;
return list;
}
static void list_free(pr_track_t *list)
{
if (!list)
return;
list_free(list->next);
free(list);
}
#ifdef DEBUG_PR_TRACK
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
static void dump_pr_track(int cyl, pr_track_t *track_pr)
{
pr_track_t *list;
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
printf("cyl%d:\n", cyl);
list = track_pr;
while (list) {
printf(" start %d end %d t_start %d:%02d t_end %d:%02d pt %d\n",
mbar_to_PSI(list->start),
mbar_to_PSI(list->end),
FRACTION(list->t_start, 60),
FRACTION(list->t_end, 60),
list->pressure_time);
list = list->next;
}
}
#endif
/*
* This looks at the pressures for one cylinder, and
* calculates any missing beginning/end pressures for
* each segment by taking the over-all SAC-rate into
* account for that cylinder.
*
* NOTE! Many segments have full pressure information
* (both beginning and ending pressure). But if we have
* switched away from a cylinder, we will have the
* beginning pressure for the first segment with a
* missing end pressure. We may then have one or more
* segments without beginning or end pressures, until
* we finally have a segment with an end pressure.
*
* We want to spread out the pressure over these missing
* segments according to how big of a time_pressure area
* they have.
*/
static void fill_missing_segment_pressures(pr_track_t *list, enum interpolation_strategy strategy)
{
double magic;
while (list) {
int start = list->start, end;
pr_track_t *tmp = list;
int pt_sum = 0, pt = 0;
for (;;) {
pt_sum += tmp->pressure_time;
end = tmp->end;
if (end)
break;
end = start;
if (!tmp->next)
break;
tmp = tmp->next;
}
if (!start)
start = end;
/*
* Now 'start' and 'end' contain the pressure values
* for the set of segments described by 'list'..'tmp'.
* pt_sum is the sum of all the pressure-times of the
* segments.
*
* Now dole out the pressures relative to pressure-time.
*/
list->start = start;
tmp->end = end;
switch (strategy) {
case SAC:
for (;;) {
int pressure;
pt += list->pressure_time;
pressure = start;
if (pt_sum)
pressure -= lrint((start - end) * (double)pt / pt_sum);
list->end = pressure;
if (list == tmp)
break;
list = list->next;
list->start = pressure;
}
break;
case TIME:
if (list->t_end && (tmp->t_start - tmp->t_end)) {
magic = (list->t_start - tmp->t_end) / (tmp->t_start - tmp->t_end);
list->end = lrint(start - (start - end) * magic);
} else {
list->end = start;
}
break;
case CONSTANT:
list->end = start;
}
/* Ok, we've done that set of segments */
list = list->next;
}
}
#ifdef DEBUG_PR_INTERPOLATE
void dump_pr_interpolate(int i, pr_interpolate_t interpolate_pr)
{
printf("Interpolate for entry %d: start %d - end %d - pt %d - acc_pt %d\n", i,
interpolate_pr.start, interpolate_pr.end, interpolate_pr.pressure_time, interpolate_pr.acc_pressure_time);
}
#endif
static struct pr_interpolate_struct get_pr_interpolate_data(pr_track_t *segment, struct plot_info *pi, int cur)
{ // cur = index to pi->entry corresponding to t_end of segment;
struct pr_interpolate_struct interpolate;
int i;
struct plot_data *entry;
interpolate.start = segment->start;
interpolate.end = segment->end;
interpolate.acc_pressure_time = 0;
interpolate.pressure_time = 0;
for (i = 0; i < pi->nr; i++) {
entry = pi->entry + i;
if (entry->sec < segment->t_start)
continue;
interpolate.pressure_time += entry->pressure_time;
if (entry->sec >= segment->t_end)
break;
if (i <= cur)
interpolate.acc_pressure_time += entry->pressure_time;
}
return interpolate;
}
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
static void fill_missing_tank_pressures(struct dive *dive, struct plot_info *pi, pr_track_t *track_pr, int cyl)
{
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 i;
struct plot_data *entry;
pr_interpolate_t interpolate = { 0, 0, 0, 0 };
pr_track_t *last_segment = NULL;
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 cur_pr;
enum interpolation_strategy strategy;
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
/* no segment where this cylinder is used */
if (!track_pr)
return;
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
if (dive->cylinder[cyl].cylinder_use == OC_GAS)
strategy = SAC;
else
strategy = TIME;
fill_missing_segment_pressures(track_pr, strategy); // Interpolate the missing tank pressure values ..
cur_pr = track_pr->start; // in the pr_track_t lists of structures
// and keep the starting pressure for each cylinder.
#ifdef DEBUG_PR_TRACK
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
dump_pr_track(cyl, track_pr);
#endif
/* Transfer interpolated cylinder pressures from pr_track strucktures to plotdata
* Go down the list of tank pressures in plot_info. Align them with the start &
* end times of each profile segment represented by a pr_track_t structure. Get
* the accumulated pressure_depths from the pr_track_t structures and then
* interpolate the pressure where these do not exist in the plot_info pressure
* variables. Pressure values are transferred from the pr_track_t structures
* to the plot_info structure, allowing us to plot the tank pressure.
*
* The first two pi structures are "fillers", but in case we don't have a sample
* at time 0 we need to process the second of them here, therefore i=1 */
for (i = 1; i < pi->nr; i++) { // For each point on the profile:
double magic;
pr_track_t *segment;
int pressure;
int *save_pressure, *save_interpolated;
entry = pi->entry + i;
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
save_pressure = &(entry->pressure[cyl][SENSOR_PR]);
save_interpolated = &(entry->pressure[cyl][INTERPOLATED_PR]);
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
pressure = *save_pressure ? *save_pressure : *save_interpolated;
if (pressure) { // If there is a valid pressure value,
last_segment = NULL; // get rid of interpolation data,
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
cur_pr = pressure; // set current pressure
continue; // and skip to next point.
}
// If there is NO valid pressure value..
// Find the pressure segment corresponding to this entry..
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
segment = track_pr;
while (segment && segment->t_end < entry->sec) // Find the track_pr with end time..
segment = segment->next; // ..that matches the plot_info time (entry->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
// After last segment? All done.
if (!segment)
break;
// Before first segment, or between segments.. Go on, no interpolation.
if (segment->t_start > entry->sec)
continue;
if (!segment->pressure_time) { // Empty segment?
*save_pressure = cur_pr; // Just use our current pressure
continue; // and skip to next point.
}
// If there is a valid segment but no tank pressure ..
if (segment == last_segment) {
interpolate.acc_pressure_time += entry->pressure_time;
} else {
// Set up an interpolation structure
interpolate = get_pr_interpolate_data(segment, pi, i);
last_segment = segment;
}
if(dive->cylinder[cyl].cylinder_use == OC_GAS) {
/* if this segment has pressure_time, then calculate a new interpolated pressure */
if (interpolate.pressure_time) {
/* Overall pressure change over total pressure-time for this segment*/
magic = (interpolate.end - interpolate.start) / (double)interpolate.pressure_time;
/* Use that overall pressure change to update the current 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
cur_pr = lrint(interpolate.start + magic * interpolate.acc_pressure_time);
}
} else {
magic = (interpolate.end - interpolate.start) / (segment->t_end - segment->t_start);
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
cur_pr = lrint(segment->start + magic * (entry->sec - segment->t_start));
}
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
*save_interpolated = cur_pr; // and store the interpolated data in plot_info
}
}
/*
* What's the pressure-time between two plot data entries?
* We're calculating the integral of pressure over time by
* adding these up.
*
* The units won't matter as long as everybody agrees about
* them, since they'll cancel out - we use this to calculate
* a constant SAC-rate-equivalent, but we only use it to
* scale pressures, so it ends up being a unitless scaling
* factor.
*/
static inline int calc_pressure_time(struct dive *dive, struct plot_data *a, struct plot_data *b)
{
int time = b->sec - a->sec;
int depth = (a->depth + b->depth) / 2;
if (depth <= SURFACE_THRESHOLD)
return 0;
return depth_to_mbar(depth, dive) * time;
}
#ifdef PRINT_PRESSURES_DEBUG
// A CCR debugging tool that prints the gas pressures in cylinder 0 and in the diluent cylinder, used in populate_pressure_information():
static void debug_print_pressures(struct plot_info *pi)
{
int i;
for (i = 0; i < pi->nr; i++)
printf("%5d |%9d | %9d |\n", i, get_plot_sensor_pressure(pi, i), get_plot_interpolated_pressure(pi, i));
}
#endif
/* This function goes through the list of tank pressures, of structure plot_info for the dive profile where each
* item in the list corresponds to one point (node) of the profile. It finds values for which there are no tank
* pressures (pressure==0). For each missing item (node) of tank pressure it creates a pr_track_alloc structure
* that represents a segment on the dive profile and that contains tank pressures. There is a linked list of
* pr_track_alloc structures for each cylinder. These pr_track_alloc structures ultimately allow for filling
* the missing tank pressure values on the dive profile using the depth_pressure of the dive. To do this, it
* calculates the summed pressure-time value for the duration of the dive and stores these * in the pr_track_alloc
* structures. This function is called by create_plot_info_new() in profile.c
*/
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
void populate_pressure_information(struct dive *dive, struct divecomputer *dc, struct plot_info *pi, int sensor)
{
UNUSED(dc);
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 first, last, cyl;
cylinder_t *cylinder = dive->cylinder + sensor;
pr_track_t *track = NULL;
pr_track_t *current = NULL;
const struct event *ev, *b_ev;
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 missing_pr = 0, dense = 1;
enum divemode_t dmode = dc->divemode;
const double gasfactor[5] = {1.0, 0.0, prefs.pscr_ratio/1000.0, 1.0, 1.0 };
/* if we have no pressure data whatsoever, this is pointless, so let's just return */
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
if (!cylinder->start.mbar && !cylinder->end.mbar &&
!cylinder->sample_start.mbar && !cylinder->sample_end.mbar)
return;
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
/* Get a rough range of where we have any pressures at all */
first = last = -1;
for (int i = 0; i < pi->nr; i++) {
int pressure = get_plot_sensor_pressure(pi, i, sensor);
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
if (!pressure)
continue;
if (first < 0)
first = i;
last = i;
}
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
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
/* No sensor data at all? */
if (first == last)
return;
/*
* Split the range:
* - missing pressure data
* - gas change events to other cylinders
*
* Note that we only look at gas switches if this cylinder
* itself has a gas change event.
*/
cyl = sensor;
ev = NULL;
if (has_gaschange_event(dive, dc, sensor))
ev = get_next_event(dc->events, "gaschange");
b_ev = get_next_event(dc->events, "modechange");
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
for (int i = first; i <= last; i++) {
struct plot_data *entry = pi->entry + i;
int pressure = get_plot_sensor_pressure(pi, i, sensor);
int time = entry->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
while (ev && ev->time.seconds <= time) { // Find 1st gaschange event after
cyl = get_cylinder_index(dive, ev); // the current gas change.
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
if (cyl < 0)
cyl = sensor;
ev = get_next_event(ev->next, "gaschange");
}
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
while (b_ev && b_ev->time.seconds <= time) { // Keep existing divemode, then
dmode = b_ev->value; // find 1st divemode change event after the current
b_ev = get_next_event(b_ev->next, "modechange"); // divemode change.
}
if (current) { // calculate pressure-time, taking into account the dive mode for this specific segment.
entry->pressure_time = (int)(calc_pressure_time(dive, entry - 1, entry) * gasfactor[dmode] + 0.5);
current->pressure_time += entry->pressure_time;
current->t_end = entry->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
if (pressure)
current->end = 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
// We have a final pressure for 'current'
// If a gas switch has occurred, finish the
// current pressure track entry and continue
// until we get back to this cylinder.
if (cyl != sensor) {
current = NULL;
set_plot_pressure_data(pi, i, SENSOR_PR, sensor, 0);
continue;
}
// If we have no pressure information, we will need to
// continue with or without a tracking entry. Mark any
// existing tracking entry as non-dense, and remember
// to fill in interpolated data.
if (current && !pressure) {
missing_pr = 1;
dense = 0;
continue;
}
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
// If we already have a pressure tracking entry, and
// it has not had any missing samples, just continue
// using it - there's nothing to interpolate yet.
if (current && dense)
continue;
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
// We need to start a new tracking entry, either
// because the previous was interrupted by a gas
// switch event, or because the previous one has
// missing entries that need to be interpolated.
// Or maybe we didn't have a previous one at all,
// and this is the first pressure entry.
current = pr_track_alloc(pressure, entry->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
track = list_add(track, current);
dense = 1;
}
if (missing_pr) {
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
fill_missing_tank_pressures(dive, pi, track, sensor);
}
#ifdef PRINT_PRESSURES_DEBUG
debug_print_pressures(pi);
#endif
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
list_free(track);
}