Jef,

thanks a lot for your help.

> On 12. Jan 2024, at 09:22, Jef Driesen <j...@libdivecomputer.org> wrote:
> 
> Libdivecomputer reports the sensor number, or DC_SENSOR_NONE if the data is 
> not from a sensor (for example the voted/average ppO2):
> 
> https://github.com/libdivecomputer/libdivecomputer/blob/master/src/divesoft_freedom_parser.c#L911
> https://github.com/libdivecomputer/libdivecomputer/blob/master/src/divesoft_freedom_parser.c#L1023
> 
> You can use this info to distinguish between the different sensors.
> 
> Libdivecomputer does not support reporting whether a sensor was voted out. 
> The freedom dive computers do record this info, so this is something that 
> could be added (although no other dive computers supports this). Currently we 
> only use the sensor state bits to exclude sensors that are not available or 
> not calibrated.

I am still trying to make up my mind about the best way to handle this 
situation. The problem is: There is no straight forward solution to a voting 
logic when you have more than three sensors. You cannot simply say: If the 
spread is too big, throw away the outlier. Yes, you can always try to bring the 
spread of values into a smaller range by deleting the largest or smallest. But 
then there is more than one parameter to quantify the spread (should you tread 
spread of four values more liberally than just of three?, do you look at the 
overall spread (larges minus smallest) or pairwise distances? average 
distance?). In any case, since there are so many choices, we would almost 
certainly do something different that the dive computer itself. The jury is 
still out on how bad this is.

On the other hand, I think, the best way to report what the Liberty thinks what 
is going on, would be an event that is emitted when one of the sensor bits 
changes (in any direction). From what I see from the promotional videos on 
youtube (I have never seen the actual unit in real life nor have I seen an 
actual log file so far, only reports about those), the computer seems to raise 
an alarm for the diver to decide what to do (including bringing back a sensor 
into the game that was disabled before). Do you think this is the right path?

I am not really familiar with the inner workings of libdivecomputer, so for me 
to produce a patch has some learning curve (plus I might end up to do the wrong 
thing or the right thing in a wrong way). But if you want, I can give it a try.

Best
Robert

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Reply via email to