Hi Dirk I am fine, of course, with Linus' patch. I dispute however that I was ever against the threshold unless I misunderstand something here. I also did no changes to any code concerning threshold. My work was focussed on getting the raw data in trying to deal with all uemis oddities.
You and I never discussed a threshold, that must have been someone else. Nevertheless I'll try to get the last master with my lousy internet connection here in Egypt and continue testing. I still suffer from not knowing the code too well and need to still learn a lot. For example while trying to implement the pressure drop approach I found that even changing the base64 string wouldn't to anything to the equipment data nor the sac calculations. I spend 2 hours and didn't find out why because I am still so new to anything that is outside the uemis loader that I start to wonder whether I am useful at all. G. Lerch Montag, 28. September 2015 13:58 +0200 von Dirk Hohndel <d...@hohndel.org>: >On Mon, Sep 28, 2015 at 01:56:24PM +0300, Guido Lerch wrote: >> >> Hi Linus, >> >> I just realized the same, none of my code changes do anything to the >> events > >This has nothing to do with events. Remember how we talked about the fact >that you didn't like it that my original code dropped all the samples that >had a depth smaller than SURFACE_THRESHOLD? The fact that we no longer >doing that is what causes the effect that Linus observed. > >> but I am working on a patch to detect pressure drops that happen >> if you decouple the regulator before the uemis has finished its dive >> which is usually 2-3 minutes after you surface. > >I think that Linus existing solution has some merit independently of what >you are proposing. Yes, detecting such pressure drops helps with an oddity >that the Uemis creates because it keeps storing samples for such a long >time after the end of the dive and that possibly other dive computers >might cause as well. > >But Linus' patch fundamentally changes the way we consider SAC - it only >starts the calculation at the first sample where the diver is under water >and ends at the last sample where the diver is under water. On a computer >with a slow sample rate this might introduce a small inaccuracy (as you >might be missing as much as the first and last minute of your dive), but >for most current dive computers that tend to sample at 30s or faster it's >just a hand full of breaths and the overall result is likely more accurate >as it also misses the initial cooling of the tank. > >> If you have done some fixes already please let me know so we do not >> duplicate efforts. If you haven't it's a good learning for me but will >> take some time as I don't know that part of the code yet. > >Linus' patch is in master - I pushed it earlier. > >/D
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface