On Wed, 23 May 2018 at 16:22, Jef Driesen <[email protected]> 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. > Jef Thank you Jef. Everything is much clear now. Now i understand why pO2 samples disappeared. The current version of Shearwater desktop shows average pO2 and individual mV values (see attachment). I forgot that for the wrong pO2 samples I filed an Github issue on december 2017. Sorry I did not reply at some point because Anton and Robert replied on Xmas day and I missed the email :) Anton solution would be great. https://github.com/Subsurface-divelog/subsurface/issues/971 -- Davide https://vimeo.com/bocio/videos
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
