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 > ><[email protected]> > >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. //Anton -- Anton Lundin +46702-161604 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
