Some parts of the existing code used the depth at the time of the sample
to calculate the sac rate - it makes much more sense to use the average
depth. But that requires us to loop over the entries and average the
individual sac rates per segment instead of just using the beginning and
end depth of the multi-segment interval we use for smoothing purposes.
This may seem like a subtle detail, but it does in fact matter when we
plot the synthetic tank pressure values that we create when we have no
tank pressure data in the samples.
Another detail we change here is to not artificially start with a forward
looking segment of the full SAC_WINDOW but instead just start with the
first two data points and then simply let the time window grow until it
hits SAC_WINDOW - at which point it becomes a sliding window.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This changes the algorithm that picks the sac color to consider
+/- 1 l/min to be the same color (before the color changed every
time you crossed above or below the average which looked silly with
our synthetic "constant sac" values as those are discrete and oscilate
around the average.
This also changes the order in which things are drawn so so that the
pressure plot goes over the depth profile plot (so the red shading of the
dive no longer changes the color of the tank pressure plot).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Use rgb_t for the sac colors, create a new set_source_rgb_struct function
and use that for the velocity values (in the depth plot) as well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I've seen at least DivingLog do this. If you manually enter beginning and
end pressure for a tank it will either linearize the samples in between or
offer to simulate a dive (with constant SAC rate). At least the first case
is reasonably easy to detect. We throw out those samples and ensure that
we still have valid beginning and end pressure for that dive.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way, when you have a new dive that you just imported from your dive
computer, you can just double-click on the dive and fill out all the
relevant information: location, notes, buddies and cylinder info.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's pretty basic information, and might be hidden behind the dialog
especially on a small screen.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It just pops up the dive info edit box. This way you can be in the dive
info tab, and not have to go to the dive list just to double-click on
the dive.
This thing still needs some polish, but it's now usable.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now that the dive info window is read-only, we need to edit the dives
some other way. We bring up a dive info edit dialog when you
double-click on the dive list entry for that dive.
I do want to have an "edit" button or keyboard shortcut or something
too, though.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We always keep the focus on the dive list, so that the random gtk focus
handling doesn't suddenly randomly make us edit the combo boxes when the
cursor up/down keys start changing them instead of the dive list.
This means that dive location, notes and buddy/divemaster aren't
editable at all any more, but I'll fix that by making a separate dive
edit popup window.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus suggested that instead of using absolute SAC values to base the
color on (which forced us to pre-define which SAC rates are green and
which are red) we should color the tank pressure plot relative to the avg
SAC rate of that dive - which I think makes the coloring much more useful
to spot when on your dive you were doing well and when you were not.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
* 'sacplot' of git://github.com/dirkhh/subsurface:
Color pressure plot according to current SAC rate
Fix minor coding standard issues introduced by my last commit
Similar to color indicating vertical speed in the profile plot we now use
color in the tank pressure plot to indicate current SAC rate.
We use a 45 sec sliding window to make sure we cover at least two breaths
for each current SAC sample to avoid artificial oscillation based on
breathing rhythm for corputers with high sample resolution.
Not sure about the color coding that I'm using right now - it's green-ish
for SAC rates under 15l/min ~= .55cuft/min and turns yellow and red as you
go higher. That seems to work well for me, but for other divers this may
be way off (or at least not as useful). Maybe this should be configurable?
This is a lot more diver specific than the vertical velocity where there
are clear recommendations based on safety considerations on what is good
and bad.
As a side effect, this removes the color coding that showed you whether
you were looking at pressure data from samples (green) vs. interpolated
pressure data (yellow). Not sure if people really want to see that. We
might be able to indicate this differently (I am thinking different line
width or transparency or something along those line)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
At least the Suunto pressure transmitter seems to be pretty
"quantisized", and it will send identical samples for a while until the
pressure changes enough. Then subsurface gives this silly flat line
with a sudden jump downwards, which *could* be you suddenly taking a
deep breath after holding it for a while, but almost certainly it's a
sensor issue.
So just remove successive identical pressure readings. They aren't
interesting, and subsurface will actually do a good job of interpolating
it according to SAC rate instead. And they just make the XML look
worse.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
You can still order them by date by just setting the sort order on the
date column, but normally you'd be more interested in the most recent
dives.
I tried to just scroll down to the last ones automatically instead, but
gtk makes that *really* hard to do. If you do it in the natural place
for it, the scroll bar wll show up later and then cover up the last
entry anyway. So you'd have to do some crazy expose event thing or
something. Which may be the right thing to do eventually anyway, but
not worth the pain right now.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Randomly picked up to 60 characters. But maybe we should just get rid
of the limit entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Lubomir's solution to fill them with a newline doesn't work. Well, it
may work on some versions of gtk, but on mine it just results in an ugly
box for the control character '000a' that tries to show the newline.
So this is a third approach: if we reset the text to empty, first set it
to space (to clear it), and then set it to empty. That seems to work on
at least one version of gtk, and doesn't have the problem with the space
*remaining* when you cut-and-paste something into the combo box.
Let's see if it breaks anything else, but at worst it should be no worse
than the old "set it to space" approach - iow the combo box might
remember the space, but at least not some random data from the previous
dive that it happened to show.
Lovely gtk bugs.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Passing -1 to gtk_combo_box_set_active, seems not to work as the gtk
documentation explains; there might be a bug in the library or some
special case that is not explained.
could be related to:
http://mail.gnome.org/archives/gtk-devel-list/2004-March/msg00170.html
passing \n seems to "trick" the cell renderer to clear the entry
completely. This is a temporary solution.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This changes the save format xml to be a bit more readable: instead of
putting the gasmix first, put the cylinder type (size, workpressure and
description) first, then gasmix, then pressure details.
It makes no difference for machine parsing, but I think it's a lot more
logical for humans that actually look at the xml file. And we really do
want to make the xml file readable by humans.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This makes it consider them to be identical if they are within half a
bar of each other. If you edit the pressures by hand and set them to
the same bar pressure as the samples, they may not be identical to the
last milli-bar, but clearly the manually entered cylinder pressure isn't
significantly different from the sample data, so consider it redundant.
We do want manual overrides of cylinder pressures to take precedence
over sample data (as Dirk so eloquently puts it, some dive computers
really don't have very reliable sample data), but at the same time the
sample data is the one we are expecting to be fairly accurate. The
starting and ending pressure overrides are for when there is no sample
data, or when the sample data is totally wrong for some reason.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some dive computers randomly drop samples. That was no problem unless it
was the LAST sample. We work around that now
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
.. and fix the maxpressure to actually look at *all* the cylinders, so
that if you don't have sample data, but rely onmanually set cylinder
pressures, it now really is the max of all the cylinders.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We no longer look at the start and end pressure for a tank, if the tank
has valid pressure data in its samples (which makes sense). Sadly that
breaks the current pressure interpolation code. With this patch most of
those problems should be fixed.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- make the text a lighter color so it stands out more
- change the heuristic when we print text to include both relative change
in temperature and time since the last text was printed
- print the first temperature we encounter
- allow an ending temperature to be printed if the last printed
temperature was before the 75% mark of the dive
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This grays out the pressure settings in the cylinder editing widget if
the pressure data has been taken from the samples. You can still
manually override the data, but you now need to enable that manual
override explicitly.
This makes the semantics of editing start/end pressures of dives with
pressure sample data a bit more intuitive, I think.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
For graying things out, we want a widget, not a spinbutton. Although
I'm sure we could just cast things back and forth. But let's be
consistent with what we do, and only ever cast from GtkWidget to
GtkSpinButton, and have the same logic as for the "o2" widget that also
needs to be explicitly enabled.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is just in case I end up doing the graying out of implicit pressure
information: I wanted to clean things up a bit first.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
NOTE! When *editing* the cylinder data, the only thing shown is the
non-sample pressure. So the cylinder editing widget will show zero for
start/end pressure for a dive that has pressure saples without any
manually set pressure data.
This is intentional, so that you can clearly see that this is not a set
value. But it may be that we should gray out the spinputton and have an
"edit value" checkbox or something to make it really obvious.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The statistics page calculates air use separately, and also needs to be
fixed up for the split of the pressures into sample-vs-start/end.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Make sure that we calculate air use by using the proper start/end
pressures, with the manually set ones being used preferentially over any
possible sample data.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Keep the sample pressure start/end data separate from the overall
cylinder start/end data - and clean the overall cylinder start/end data
if it matches the samples exactly to avoid the redundancy.
This breaks all the SAC calculations etc, which expect the cylinder
pressures to always be in the cylinder data. I'll fix that up
separately.
The reason for this is that we really want to keep the manually entered
data separate: the pressure plotting doesn't need the confusion, and
considers end-point data (with interpolation) very different from sample
data. Also, we do not want to pollute the xml save-file with data that
is computed.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. although in that case we can only ever show the volume in liters, and
cannot do a conversion to cubic feet even if the user has set imperial
units.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I thought we had fixed this before - but I guess it got broken again
somewhere. We now make sure that the plot_info ends on an entry with
depth 0.
Added test14 to verify the fix.
Also fixed cut'n'paste errors in a few test dive files.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Make statistics.c use snprintf() with weekday(), monthname() instead of
strftime(). The mingw strftime() ends up having lots of problems at
least on Windows unless you set the locale just right, so just avoid the
problem by doing the simple function by hand. We already did that in
other places anyway.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This allows us to install the xslt files in multiple places. Right now
the path defaults to the subsurface xslt install directory, the relative
directory "xslt" and the current working directory.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Open JDiveLog files by translating them to subsurface format using XSLT.
These files are identified by the name of the first element (JDiveLog)
and transform is applied to only these.
The XSLT feature is compiled in only if libxslt is installed. The
transformation files are installed globally in Linux under
/usr/share/subsurface/xslt. Windows and OSX still need appropriate Makefile
changes and testing.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In some situations we could end up with no sample pressure and no
interpolated pressure at time = 0. This is now fixed.
Fix notes in test dive the exposed the issue.
Also change the code in create_plot_info to keep the number of samples and
the number of corresponding pi entries in separate variables. This avoids
future changes from breaking if they assume they can access
dive->sample[nr_samples - 1] (which is a reasonable assumption to make).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The notes now reflect things that were fixed in the last commits.
Also added more test dives to test other boundary cases.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This was exposed by the test dives, but it shows up in small ways with
real dives from some dive computers like the Suunto Vyper Air.
We now insert synthetic plot_info entries that match the gas change event;
to make this look smoother we insert either two events (one for the old
tank, one a second later for the new tank) if there is no sample at the
time of the event, or one additional event (and move the real sample back
by one second) if there is a sample at the time of the event.
This does expose another issue with some dives from Linus' computer where
the pressure in the samples dips below the end pressure noted for the tank
- which creates an odd "yellow up-tick" at the end of using the first tank
in the plot. Maybe we should not insert a synthetic "last of old tank"
event if we have a sample with valid pressure in the last NN seconds
before the gas change?
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we have more than four identical depth readings, the old code would see
those as local maxima and minima and print spurious depth values in the
profile plot.
Yes, in real sample data identical readings won't happen - but in
synthetic data they can and there this looks really bogus.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As much as Linus' dives may be fun to look at, they don't help us test the
app. Writing these test dives I already found a couple of bugs - and I'm
just getting started.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
