Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]
Anton Lundin
glance at acc.umu.se
Wed May 23 07:47:51 PDT 2018
On 23 May, 2018 - Anton Lundin wrote:
> On 23 May, 2018 - Jef Driesen wrote:
>
> > On 2018-05-23 14:58, Davide DB wrote:
> > >On Wed, May 23, 2018, 12:08 Willem Ferguson
> > ><willemferguson at zoology.up.ac.za>
> > >wrote:
> > >>If this is the case, then the problem should in principle be solvable
> > >>and it possibly means that the coding in the dive log is slightly
> > >>different from that of the standard Petrel and the Fischer
> > >>Petrel 2. The
> > >>most knowledgeable person to approach is Jef Driesen but he would need
> > >>some specific information from your download. A first approach is to
> > >>inspect the .bin dumpfile generated for debug in Subsurface. Then use
> > >>his dctool executable (If I remember correctly it can do Bluetooth and
> > >>it is extremely flexible) and see if you can trace the pO2 values.
> > >>
> > >>I am not sure this is what you may want to hear, but assume that
> > >>(if you
> > >>want the problem solved) you need to take the initiative. You may
> > >>possibly be the only person in this circle which has a divecan
> > >>Petrel so
> > >>you are in the best position to address the problem.
> > >>
> > >
> > >While I do not pretend anything (of course), regarding your
> > >questions I can
> > >assure you that I made everything I could as end user. I gave
> > >- Shearwater desktop screenshots
> > >- Shearwater xml exported logs
> > >- Subsurface xml logs
> > >- Subsurface bin dumps
> > >- dctool dump files
> > >
> > >My only fault was not filing a bug report on Github to resume
> > >everything in
> > >one place.
> > >I even asked on the list if someone else was using a Shearwater
> > >Petrel ECCR
> > >controller and, maybe experiencing the same behavior. No reply. So
> > >I don't
> > >know if it's my specific unit or not.
> > >BTW I recently updated Petrel firmware to the latest version without
> > >results. While it's possible I'm the only Shearwater ccr user on
> > >this list,
> > >we are speaking of the most common eccr controller on the market
> > >nowadays.
> > >It's used on countless rebreathers not an obscure dive computer
> > >implementation.
> > >
> > >Everything started months ago when I discovered that pO2 samples
> > >reported
> > >by Subsurface were completely different (and wrong) from
> > >Shearwater desktop.
> > >There was a long email thread in which AFAIK no solution was found: my
> > >Petrel is strange.
> > >Maybe I missed something and Jef or Anton modified something. I
> > >don't know
> > >but at some point pO2 samples disappeared from Subsurface hence I
> > >opened
> > >this thread but I'm failing to understand what "default
> > >calibration" means
> > >and why in my logbook I find the same device listed with random
> > >number of
> > >sensors.
> > >I asked again today because because even a "guy you must die!"
> > >reply it's
> > >ok but I got no replies at all.
> >
> > Sorry for the lack of response, but for the last few weeks, I was
> > just too busy with non-libdivecomputer related things.
> >
> > Anyway, the problem is as follows. The shearwater devices record two
> > different things:
> >
> > 1. The average/voted ppO2.
> >
> > 2. The value from each O2 sensor. Unfortunately this value is not
> > the ppO2 value, but the raw millivolt measurement from the sensor.
> > In order to convert this value to a ppO2 value, we need to take into
> > account the calibration values.
> >
> > Last time I checked, shearwater desktop only shows the average/voted
> > ppO2 (#1). It doesn't show the individual ppO2 from each sensor (#2)
> > at all (e.g. no millivolt values nor the converted ppO2).
> >
> > Now, originally libdivecomputer only reported the average/vote ppO2.
> > Later on we figured out how the sensor calibration worked, and this
> > was replaced with the ppO2 value from the individual sensors. But
> > afterwards we also discovered that some devices (like the one from
> > Davide) don't seem to store the calibration values correctly, and
> > leave them at their default values (2100). I have no idea why this
> > happens. Anyway, because applying those calibration values produces
> > incorrect ppO2 values, I added some code to detect this case and
> > disable the ppO2 from the sensors. Since the average/voted ppO2 was
> > already disabled earlier, that also means you won't get any ppO2
> > values at all anymore.
> >
> > For those bogus default calibration values, there is not much we can
> > do about that. Without the (correct) calibration values, we simply
> > can't calculate the ppO2 values. So unless the calibration values
> > are for some reason stored elsewhere, and we just don't know about
> > this, we're simply stuck here. Shearwater desktop doesn't show this
> > info, so it's difficult to tell what's going on.
> >
> > The only part that we can do something about, is restoring the
> > average/voted ppO2 again. That's already on my todo list. But right
> > now the libdivecomputer api doesn't have a way to indicate the type
> > of the ppO2 value (e.g. average/voted or from an individual sensor),
> > so that would cause confusing. So this will require some (backwards
> > incompatible) changes, and that's why it's not done yet.
>
> The simple solution is to just emit the average/voted ppO2 when we can't
> find the calibration values.
>
> Its a graceful degradation of functionality, and way better than not
> showing any ppO2 at all.
>
>
> It should be simple to write.
Something simple like:
diff --git i/src/shearwater_predator_parser.c w/src/shearwater_predator_parser.c
index dda042c..e5194e8 100644
--- i/src/shearwater_predator_parser.c
+++ w/src/shearwater_predator_parser.c
@@ -669,19 +669,19 @@ shearwater_predator_parser_samples_foreach (dc_parser_t *abstract, dc_sample_cal
if ((status & OC) == 0) {
// PPO2
if ((status & PPO2_EXTERNAL) == 0) {
-#ifdef SENSOR_AVERAGE
- sample.ppo2 = data[offset + 6] / 100.0;
- if (callback) callback (DC_SAMPLE_PPO2, sample, userdata);
-#else
- sample.ppo2 = data[offset + 12] * parser->calibration[0];
- if (callback && (parser->calibrated & 0x01)) callback (DC_SAMPLE_PPO2, sample, userdata);
-
- sample.ppo2 = data[offset + 14] * parser->calibration[1];
- if (callback && (parser->calibrated & 0x02)) callback (DC_SAMPLE_PPO2, sample, userdata);
-
- sample.ppo2 = data[offset + 15] * parser->calibration[2];
- if (callback && (parser->calibrated & 0x04)) callback (DC_SAMPLE_PPO2, sample, userdata);
-#endif
+ if (!parser->calibrated & 0x07) {
+ sample.ppo2 = data[offset + 6] / 100.0;
+ if (callback) callback (DC_SAMPLE_PPO2, sample, userdata);
+ } else {
+ sample.ppo2 = data[offset + 12] * parser->calibration[0];
+ if (callback && (parser->calibrated & 0x01)) callback (DC_SAMPLE_PPO2, sample, userdata);
+
+ sample.ppo2 = data[offset + 14] * parser->calibration[1];
+ if (callback && (parser->calibrated & 0x02)) callback (DC_SAMPLE_PPO2, sample, userdata);
+
+ sample.ppo2 = data[offset + 15] * parser->calibration[2];
+ if (callback && (parser->calibrated & 0x04)) callback (DC_SAMPLE_PPO2, sample, userdata);
+ }
}
// Setpoint
Should be enough.
//Anton
--
Anton Lundin +46702-161604
More information about the subsurface
mailing list