On Thu, 21 Jun 2018 at 22:57, Anton Lundin <gla...@acc.umu.se> wrote:
> On 21 June, 2018 - Dirk Hohndel wrote: > > > I am reasonably certain that we can rectify this. > > > > Please make a copy of your dive data (simply export them to an XML > > file), open that XML file, and then re-download from the Shearwater. > > In the Download dialog check the two boxes (sorry, English text, I'm > > sure you can figure out the Italian version): > > "Force download of all dives" > > "Always prefer downloaded dives" > > > > With these options checked it should keep all of your other data like > > notes, buddies, etc, but replace the downloaded data with the new > > version which we assume will be corrected with the fix in place. > > > > So this should be reasonably easy to recover from. > Great Dirk! This completely change everything. I always thought it would have delete everything. I will try ASAP. Thanks > > > A CCR dive without pO2 samples is like a cake with no sugar. If I > > > still have them on my Petrel (I never investigated how many profiles > > > it stores) I should import everything from scratch into Subsurface and > > > compile everything again. Not a nice perspective for the future. Right > > > now I'm diving two/three times per week so the count will increase > > > rapidly. I've tons of notes, wrecks positions, all dives have GPS > > > locations... > > > > See above - you should be able to do this without having to manually > > re-edit all of this work! > > I would rather describe it as without the pretty icing on the cake. > Every thing else about the profile is correct. Time, depth, temp and so > on. The pO2 is just affecting your deco and the monitoring of your > rebreather performance. Thats my view on it. > I respect your point but I run my unit completely manual from the beginning so pO2 matters to me. It's a way to monitor my progress and see how the Shearwater Buhlmann behaves with the pO2 when I do not use ratio deco. > If someone can extract this as one or two sample dives that show the > > problem and add words that make enough sense to me, I'll reach out > > to Shearwater again to see if they have suggestions. I know I sent them > > one of the earliest exchanges on this topic but neither they nor I really > > understood the problem and it got dropped > > The calibration constants stored in the dive header are the default > value of 2100, and not the actual calibration constant. > > First, that caused us to incorrectly convert the mV values from the > sensors into po2 values, and the later code did just skip exposing any > po2 values at all. > > Now we fall back to the averaged/voted po2 value stored in a different > position in the samples. > > > > Moreover other questions remained unanswered; In one year my unique > > > Petrel was identified as 3 different devices with random number of > > > sensors. My logbook is a mess and nobody knows the reason. > > > > Also something I can ask about if you give me more information. > > I rarely thing its random. > > The old code exposed 1 value, the averaged/voted one. > > Later, we exposed the individual sensor values. > > Now we will expose the individual sensor values if we can find sane > calibration constants, otherwise the averaged/voted one. We will also > add a row in the "Extra info" pane saying which one it is. > I was referring to my logbook. Looking into my logbook I find 4 different computers (deviceid it's the same): <divecomputer model='Shearwater Petrel 2' deviceid='1a2d46b1' diveid='3db7eb77' dctype='CCR' no_o2sensors='1'> <divecomputer model='Shearwater Petrel 2' deviceid='1a2d46b1' diveid='52d4ba3e' dctype='CCR' no_o2sensors='3'> <divecomputer model='Shearwater Petrel' deviceid='1a2d46b1' diveid='a6e05a10' dctype='CCR'> <divecomputer model='Shearwater Petrel 2' deviceid='1a2d46b1' diveid='3db24900' dctype='CCR'> Where these differences originate from? 1 sensor, 3 sensor, no sensor, Petrel and Petrel 2 Different Subsurface versions with different approach? > > > > Months ago, given your good relationship with Shearwater, I warmly > > > recommended to contact them privately asking info on this nasty > > > behaviour of some devices. > > > > I will look again if there are more emails that I've missed. > > The devices behave just fine. Its just our reverse engineered code who > doesn't work any longer. > > There has bin some email exchanges, (don't remember who talked to them > or when), about how to use the calibration constants and the comment > from Shearwater back then was that this is a internal detail they didn't > want to say anything about it. > The answer might change when someone else asks them, but thats the last > thing I heard. > > I don't have any Shearwater devices nor any contacts at that company. I > just stared at the data long enough and figured out a (what later turned > out to be a faulty) relationship between them. Later Jef figured out > what the real relation ship was which matched the data way better. > (To my defence, my formula matched all the test data I had =) > > Two users affected in a very small Subsurface user base. Who knows how many units expose the default calibration values? Anyway, mine was just a suggestion. No problem at all. I will try Dirk suggestion so I can save my old data. Thanks
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
