2017-04-27 18:18:03 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2018-05-22 07:07:42 +00:00
|
|
|
#include "ssrf.h"
|
2013-01-09 20:07:09 +00:00
|
|
|
#include "dive.h"
|
2018-05-11 15:25:41 +00:00
|
|
|
#include "subsurface-string.h"
|
2020-09-19 11:30:56 +00:00
|
|
|
#include "qthelper.h" // for copy_qstring
|
2013-01-09 20:07:09 +00:00
|
|
|
#include "device.h"
|
2020-09-13 17:08:41 +00:00
|
|
|
#include "errorhelper.h" // for verbose flag
|
2020-09-29 22:01:24 +00:00
|
|
|
#include "selection.h"
|
2020-09-13 17:08:41 +00:00
|
|
|
#include "core/settings/qPrefDiveComputer.h"
|
2013-01-09 20:07:09 +00:00
|
|
|
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
/*
|
|
|
|
|
* Good fake dive profiles are hard.
|
|
|
|
|
*
|
|
|
|
|
* "depthtime" is the integral of the dive depth over
|
|
|
|
|
* time ("area" of the dive profile). We want that
|
|
|
|
|
* area to match the average depth (avg_d*max_t).
|
|
|
|
|
*
|
|
|
|
|
* To do that, we generate a 6-point profile:
|
|
|
|
|
*
|
|
|
|
|
* (0, 0)
|
|
|
|
|
* (t1, max_d)
|
2014-01-08 13:46:27 +00:00
|
|
|
* (t2, max_d)
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
* (t3, d)
|
2014-01-08 13:46:27 +00:00
|
|
|
* (t4, d)
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
* (max_t, 0)
|
|
|
|
|
*
|
|
|
|
|
* with the same ascent/descent rates between the
|
|
|
|
|
* different depths.
|
|
|
|
|
*
|
|
|
|
|
* NOTE: avg_d, max_d and max_t are given constants.
|
|
|
|
|
* The rest we can/should play around with to get a
|
|
|
|
|
* good-looking profile.
|
|
|
|
|
*
|
|
|
|
|
* That six-point profile gives a total area of:
|
|
|
|
|
*
|
|
|
|
|
* (max_d*max_t) - (max_d*t1) - (max_d-d)*(t4-t3)
|
|
|
|
|
*
|
|
|
|
|
* And the "same ascent/descent rates" requirement
|
|
|
|
|
* gives us (time per depth must be same):
|
|
|
|
|
*
|
|
|
|
|
* t1 / max_d = (t3-t2) / (max_d-d)
|
|
|
|
|
* t1 / max_d = (max_t-t4) / d
|
|
|
|
|
*
|
|
|
|
|
* We also obviously require:
|
|
|
|
|
*
|
|
|
|
|
* 0 <= t1 <= t2 <= t3 <= t4 <= max_t
|
|
|
|
|
*
|
|
|
|
|
* Let us call 'd_frac = d / max_d', and we get:
|
|
|
|
|
*
|
|
|
|
|
* Total area must match average depth-time:
|
|
|
|
|
*
|
|
|
|
|
* (max_d*max_t) - (max_d*t1) - (max_d-d)*(t4-t3) = avg_d*max_t
|
|
|
|
|
* max_d*(max_t-t1-(1-d_frac)*(t4-t3)) = avg_d*max_t
|
|
|
|
|
* max_t-t1-(1-d_frac)*(t4-t3) = avg_d*max_t/max_d
|
|
|
|
|
* t1+(1-d_frac)*(t4-t3) = max_t*(1-avg_d/max_d)
|
|
|
|
|
*
|
|
|
|
|
* and descent slope must match ascent slopes:
|
|
|
|
|
*
|
|
|
|
|
* t1 / max_d = (t3-t2) / (max_d*(1-d_frac))
|
|
|
|
|
* t1 = (t3-t2)/(1-d_frac)
|
|
|
|
|
*
|
|
|
|
|
* and
|
|
|
|
|
*
|
|
|
|
|
* t1 / max_d = (max_t-t4) / (max_d*d_frac)
|
|
|
|
|
* t1 = (max_t-t4)/d_frac
|
|
|
|
|
*
|
|
|
|
|
* In general, we have more free variables than we have constraints,
|
|
|
|
|
* but we can aim for certain basics, like a good ascent slope.
|
|
|
|
|
*/
|
|
|
|
|
static int fill_samples(struct sample *s, int max_d, int avg_d, int max_t, double slope, double d_frac)
|
|
|
|
|
{
|
2014-02-28 04:09:57 +00:00
|
|
|
double t_frac = max_t * (1 - avg_d / (double)max_d);
|
2017-03-09 16:07:30 +00:00
|
|
|
int t1 = lrint(max_d / slope);
|
|
|
|
|
int t4 = lrint(max_t - t1 * d_frac);
|
|
|
|
|
int t3 = lrint(t4 - (t_frac - t1) / (1 - d_frac));
|
|
|
|
|
int t2 = lrint(t3 - t1 * (1 - d_frac));
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
|
|
|
|
|
if (t1 < 0 || t1 > t2 || t2 > t3 || t3 > t4 || t4 > max_t)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2014-02-28 04:09:57 +00:00
|
|
|
s[1].time.seconds = t1;
|
|
|
|
|
s[1].depth.mm = max_d;
|
|
|
|
|
s[2].time.seconds = t2;
|
|
|
|
|
s[2].depth.mm = max_d;
|
|
|
|
|
s[3].time.seconds = t3;
|
2017-03-09 16:07:30 +00:00
|
|
|
s[3].depth.mm = lrint(max_d * d_frac);
|
2014-02-28 04:09:57 +00:00
|
|
|
s[4].time.seconds = t4;
|
2017-03-09 16:07:30 +00:00
|
|
|
s[4].depth.mm = lrint(max_d * d_frac);
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-08 13:46:27 +00:00
|
|
|
/* we have no average depth; instead of making up a random average depth
|
2015-11-15 18:15:40 +00:00
|
|
|
* we should assume either a PADI rectangular profile (for short and/or
|
2014-01-08 13:46:27 +00:00
|
|
|
* shallow dives) or more reasonably a six point profile with a 3 minute
|
|
|
|
|
* safety stop at 5m */
|
|
|
|
|
static void fill_samples_no_avg(struct sample *s, int max_d, int max_t, double slope)
|
|
|
|
|
{
|
|
|
|
|
// shallow or short dives are just trapecoids based on the given slope
|
|
|
|
|
if (max_d < 10000 || max_t < 600) {
|
2017-03-09 16:07:30 +00:00
|
|
|
s[1].time.seconds = lrint(max_d / slope);
|
2014-02-28 04:09:57 +00:00
|
|
|
s[1].depth.mm = max_d;
|
2017-03-09 16:07:30 +00:00
|
|
|
s[2].time.seconds = max_t - lrint(max_d / slope);
|
2014-02-28 04:09:57 +00:00
|
|
|
s[2].depth.mm = max_d;
|
2014-01-08 13:46:27 +00:00
|
|
|
} else {
|
2017-03-09 16:07:30 +00:00
|
|
|
s[1].time.seconds = lrint(max_d / slope);
|
2014-01-08 13:46:27 +00:00
|
|
|
s[1].depth.mm = max_d;
|
2017-03-09 16:07:30 +00:00
|
|
|
s[2].time.seconds = max_t - lrint(max_d / slope) - 180;
|
2014-01-08 13:46:27 +00:00
|
|
|
s[2].depth.mm = max_d;
|
2017-03-09 16:07:30 +00:00
|
|
|
s[3].time.seconds = max_t - lrint(5000 / slope) - 180;
|
2014-01-08 13:46:27 +00:00
|
|
|
s[3].depth.mm = 5000;
|
2017-03-09 16:07:30 +00:00
|
|
|
s[4].time.seconds = max_t - lrint(5000 / slope);
|
2014-01-08 13:46:27 +00:00
|
|
|
s[4].depth.mm = 5000;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-13 17:08:41 +00:00
|
|
|
extern "C" void fake_dc(struct divecomputer *dc)
|
2013-06-10 16:35:27 +00:00
|
|
|
{
|
2018-05-05 17:26:48 +00:00
|
|
|
alloc_samples(dc, 6);
|
|
|
|
|
struct sample *fake = dc->sample;
|
2017-11-05 14:58:24 +00:00
|
|
|
int i;
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
|
2018-05-05 17:26:48 +00:00
|
|
|
dc->samples = 6;
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
|
|
|
|
|
/* The dive has no samples, so create a few fake ones */
|
|
|
|
|
int max_t = dc->duration.seconds;
|
|
|
|
|
int max_d = dc->maxdepth.mm;
|
|
|
|
|
int avg_d = dc->meandepth.mm;
|
|
|
|
|
|
2018-05-05 17:26:48 +00:00
|
|
|
memset(fake, 0, 6 * sizeof(struct sample));
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
fake[5].time.seconds = max_t;
|
2017-11-05 14:58:24 +00:00
|
|
|
for (i = 0; i < 6; i++) {
|
2018-05-05 17:26:48 +00:00
|
|
|
fake[i].bearing.degrees = -1;
|
|
|
|
|
fake[i].ndl.seconds = -1;
|
|
|
|
|
}
|
|
|
|
|
if (!max_t || !max_d) {
|
|
|
|
|
dc->samples = 0;
|
|
|
|
|
return;
|
2017-11-05 14:58:24 +00:00
|
|
|
}
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
|
2018-05-07 09:14:57 +00:00
|
|
|
/* Set last manually entered time to the total dive length */
|
|
|
|
|
dc->last_manual_time = dc->duration;
|
|
|
|
|
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
/*
|
|
|
|
|
* We want to fake the profile so that the average
|
2015-11-15 18:15:40 +00:00
|
|
|
* depth ends up correct. However, in the absence of
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
* a reasonable average, let's just make something
|
|
|
|
|
* up. Note that 'avg_d == max_d' is _not_ a reasonable
|
|
|
|
|
* average.
|
2014-01-08 13:46:27 +00:00
|
|
|
* We explicitly treat avg_d == 0 differently */
|
|
|
|
|
if (avg_d == 0) {
|
|
|
|
|
/* we try for a sane slope, but bow to the insanity of
|
|
|
|
|
* the user supplied data */
|
2018-05-05 14:34:50 +00:00
|
|
|
fill_samples_no_avg(fake, max_d, max_t, MAX(2.0 * max_d / max_t, (double)prefs.ascratelast6m));
|
2014-01-16 04:50:56 +00:00
|
|
|
if (fake[3].time.seconds == 0) { // just a 4 point profile
|
2018-05-05 17:26:48 +00:00
|
|
|
dc->samples = 4;
|
2014-01-08 13:46:27 +00:00
|
|
|
fake[3].time.seconds = max_t;
|
|
|
|
|
}
|
2018-05-05 17:26:48 +00:00
|
|
|
return;
|
2014-01-08 13:46:27 +00:00
|
|
|
}
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
if (avg_d < max_d / 10 || avg_d >= max_d) {
|
2014-02-28 04:09:57 +00:00
|
|
|
avg_d = (max_d + 10000) / 3;
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
if (avg_d > max_d)
|
|
|
|
|
avg_d = max_d * 2 / 3;
|
2013-06-10 16:35:27 +00:00
|
|
|
}
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
if (!avg_d)
|
|
|
|
|
avg_d = 1;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Ok, first we try a basic profile with a specific ascent
|
|
|
|
|
* rate (5 meters per minute) and d_frac (1/3).
|
|
|
|
|
*/
|
2018-05-05 14:34:50 +00:00
|
|
|
if (fill_samples(fake, max_d, avg_d, max_t, (double)prefs.ascratelast6m, 0.33))
|
2018-05-05 17:26:48 +00:00
|
|
|
return;
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Ok, assume that didn't work because we cannot make the
|
|
|
|
|
* average come out right because it was a quick deep dive
|
|
|
|
|
* followed by a much shallower region
|
|
|
|
|
*/
|
|
|
|
|
if (fill_samples(fake, max_d, avg_d, max_t, 10000.0 / 60, 0.10))
|
2018-05-05 17:26:48 +00:00
|
|
|
return;
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Uhhuh. That didn't work. We'd need to find a good combination that
|
|
|
|
|
* satisfies our constraints. Currently, we don't, we just give insane
|
|
|
|
|
* slopes.
|
|
|
|
|
*/
|
|
|
|
|
if (fill_samples(fake, max_d, avg_d, max_t, 10000.0, 0.01))
|
2018-05-05 17:26:48 +00:00
|
|
|
return;
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
|
|
|
|
|
/* Even that didn't work? Give up, there's something wrong */
|
2013-06-10 16:35:27 +00:00
|
|
|
}
|
2016-06-21 04:07:36 +00:00
|
|
|
|
2020-10-03 09:18:42 +00:00
|
|
|
struct device_table device_table;
|
2020-09-13 17:08:41 +00:00
|
|
|
|
2020-10-03 09:18:42 +00:00
|
|
|
bool device::operator==(const device &a) const
|
2020-09-13 17:08:41 +00:00
|
|
|
{
|
|
|
|
|
return model == a.model &&
|
|
|
|
|
deviceId == a.deviceId &&
|
|
|
|
|
firmware == a.firmware &&
|
|
|
|
|
serialNumber == a.serialNumber &&
|
|
|
|
|
nickName == a.nickName;
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-03 09:18:42 +00:00
|
|
|
bool device::operator!=(const device &a) const
|
2020-09-13 17:08:41 +00:00
|
|
|
{
|
|
|
|
|
return !(*this == a);
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-03 09:18:42 +00:00
|
|
|
bool device::operator<(const device &a) const
|
2020-09-13 17:08:41 +00:00
|
|
|
{
|
2020-10-10 10:50:58 +00:00
|
|
|
return std::tie(deviceId, model) < std::tie(a.deviceId, a.model);
|
2020-09-13 17:08:41 +00:00
|
|
|
}
|
|
|
|
|
|
2020-10-03 09:18:42 +00:00
|
|
|
static const device *getDCExact(const QVector<device> &dcs, const divecomputer *dc)
|
2020-09-13 17:08:41 +00:00
|
|
|
{
|
2020-10-03 09:18:42 +00:00
|
|
|
auto it = std::lower_bound(dcs.begin(), dcs.end(), device{dc->model, dc->deviceid, {}, {}, {}});
|
2020-09-14 15:09:42 +00:00
|
|
|
return it != dcs.end() && it->model == dc->model && it->deviceId == dc->deviceid ? &*it : NULL;
|
2020-09-13 17:08:41 +00:00
|
|
|
}
|
|
|
|
|
|
2020-09-19 11:30:56 +00:00
|
|
|
/*
|
|
|
|
|
* When setting the device ID, we also fill in the
|
|
|
|
|
* serial number and firmware version data
|
|
|
|
|
*/
|
|
|
|
|
extern "C" void set_dc_deviceid(struct divecomputer *dc, unsigned int deviceid)
|
|
|
|
|
{
|
|
|
|
|
if (!deviceid)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
dc->deviceid = deviceid;
|
|
|
|
|
|
|
|
|
|
// Serial and firmware can only be deduced if we know the model
|
|
|
|
|
if (!dc->model)
|
|
|
|
|
return;
|
|
|
|
|
|
2020-10-03 09:18:42 +00:00
|
|
|
const device *node = getDCExact(device_table.devices, dc);
|
2020-09-19 11:30:56 +00:00
|
|
|
if (!node)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (!node->serialNumber.isEmpty() && empty_string(dc->serial))
|
|
|
|
|
dc->serial = copy_qstring(node->serialNumber);
|
|
|
|
|
if (!node->firmware.isEmpty() && empty_string(dc->fw_version))
|
|
|
|
|
dc->fw_version = copy_qstring(node->firmware);
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-03 09:18:42 +00:00
|
|
|
void device::showchanges(const QString &n, const QString &s, const QString &f) const
|
2020-09-13 17:08:41 +00:00
|
|
|
{
|
|
|
|
|
if (nickName != n && !n.isEmpty())
|
|
|
|
|
qDebug("new nickname %s for DC model %s deviceId 0x%x", qPrintable(n), qPrintable(model), deviceId);
|
|
|
|
|
if (serialNumber != s && !s.isEmpty())
|
|
|
|
|
qDebug("new serial number %s for DC model %s deviceId 0x%x", qPrintable(s), qPrintable(model), deviceId);
|
|
|
|
|
if (firmware != f && !f.isEmpty())
|
|
|
|
|
qDebug("new firmware version %s for DC model %s deviceId 0x%x", qPrintable(f), qPrintable(model), deviceId);
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-03 09:18:42 +00:00
|
|
|
static void addDC(QVector<device> &dcs, const QString &m, uint32_t d, const QString &n, const QString &s, const QString &f)
|
2020-09-13 17:08:41 +00:00
|
|
|
{
|
|
|
|
|
if (m.isEmpty() || d == 0)
|
|
|
|
|
return;
|
2020-10-03 09:18:42 +00:00
|
|
|
auto it = std::lower_bound(dcs.begin(), dcs.end(), device{m, d, {}, {}, {}});
|
2020-09-13 17:08:41 +00:00
|
|
|
if (it != dcs.end() && it->model == m && it->deviceId == d) {
|
|
|
|
|
// debugging: show changes
|
|
|
|
|
if (verbose)
|
|
|
|
|
it->showchanges(n, s, f);
|
|
|
|
|
// Update any non-existent fields from the old entry
|
|
|
|
|
if (!n.isEmpty())
|
|
|
|
|
it->nickName = n;
|
|
|
|
|
if (!s.isEmpty())
|
|
|
|
|
it->serialNumber = s;
|
|
|
|
|
if (!f.isEmpty())
|
|
|
|
|
it->firmware = f;
|
|
|
|
|
} else {
|
2020-10-03 09:18:42 +00:00
|
|
|
dcs.insert(it, device{m, d, s, f, n});
|
2020-09-13 17:08:41 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
extern "C" void create_device_node(const char *model, uint32_t deviceid, const char *serial, const char *firmware, const char *nickname)
|
|
|
|
|
{
|
2020-10-03 09:18:42 +00:00
|
|
|
addDC(device_table.devices, model, deviceid, nickname, serial, firmware);
|
2020-09-13 17:08:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
extern "C" void clear_device_nodes()
|
|
|
|
|
{
|
2020-10-03 09:18:42 +00:00
|
|
|
device_table.devices.clear();
|
2020-09-13 17:08:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
extern "C" void call_for_each_dc (void *f, void (*callback)(void *, const char *, uint32_t, const char *, const char *, const char *),
|
|
|
|
|
bool select_only)
|
|
|
|
|
{
|
2020-10-10 10:50:58 +00:00
|
|
|
for (const device &node : device_table.devices) {
|
2020-09-13 17:08:41 +00:00
|
|
|
bool found = false;
|
|
|
|
|
if (select_only) {
|
2020-09-29 22:01:24 +00:00
|
|
|
for (dive *d: getDiveSelection()) {
|
2020-09-13 17:08:41 +00:00
|
|
|
struct divecomputer *dc;
|
|
|
|
|
for_each_dc (d, dc) {
|
|
|
|
|
if (dc->deviceid == node.deviceId) {
|
|
|
|
|
found = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (found)
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
found = true;
|
|
|
|
|
}
|
|
|
|
|
if (found)
|
|
|
|
|
callback(f, qPrintable(node.model), node.deviceId, qPrintable(node.nickName),
|
|
|
|
|
qPrintable(node.serialNumber), qPrintable(node.firmware));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
extern "C" int is_default_dive_computer_device(const char *name)
|
|
|
|
|
{
|
|
|
|
|
return qPrefDiveComputer::device() == name;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
extern "C" void set_dc_nickname(struct dive *dive)
|
|
|
|
|
{
|
|
|
|
|
if (!dive)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
struct divecomputer *dc;
|
|
|
|
|
|
|
|
|
|
for_each_dc (dive, dc) {
|
|
|
|
|
if (!empty_string(dc->model) && dc->deviceid &&
|
2020-10-03 09:18:42 +00:00
|
|
|
!getDCExact(device_table.devices, dc)) {
|
2020-09-13 17:08:41 +00:00
|
|
|
// we don't have this one, yet
|
2020-10-13 18:39:49 +00:00
|
|
|
auto it = std::find_if(device_table.devices.begin(), device_table.devices.end(),
|
|
|
|
|
[dc] (const device &dev)
|
|
|
|
|
{ return !strcasecmp(qPrintable(dev.model), dc->model); });
|
|
|
|
|
if (it != device_table.devices.end()) {
|
2020-09-13 17:08:41 +00:00
|
|
|
// we already have this model but a different deviceid
|
|
|
|
|
QString simpleNick(dc->model);
|
|
|
|
|
if (dc->deviceid == 0)
|
|
|
|
|
simpleNick.append(" (unknown deviceid)");
|
|
|
|
|
else
|
|
|
|
|
simpleNick.append(" (").append(QString::number(dc->deviceid, 16)).append(")");
|
2020-10-03 09:18:42 +00:00
|
|
|
addDC(device_table.devices, dc->model, dc->deviceid, simpleNick, {}, {});
|
2020-09-13 17:08:41 +00:00
|
|
|
} else {
|
2020-10-03 09:18:42 +00:00
|
|
|
addDC(device_table.devices, dc->model, dc->deviceid, {}, {}, {});
|
2020-09-13 17:08:41 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
QString get_dc_nickname(const struct divecomputer *dc)
|
|
|
|
|
{
|
2020-10-03 09:18:42 +00:00
|
|
|
const device *existNode = getDCExact(device_table.devices, dc);
|
2020-09-13 17:08:41 +00:00
|
|
|
|
|
|
|
|
if (existNode && !existNode->nickName.isEmpty())
|
|
|
|
|
return existNode->nickName;
|
|
|
|
|
else
|
|
|
|
|
return dc->model;
|
|
|
|
|
}
|
