<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body >From phone. I am happy for you to show my dives.<div>I am diving a Kiss manual ccr so the computer is only used as a display of the sensors.</div><div>It doesnt do any control, that is up to the computer in my head ;)</div><div>Eg where it goes up to 1.75 it would have been me checking that the cells were not current limited.</div><div>Also as I cave dive the environment dictates ups and down a fair bit.</div><div>I might let the ppo2 wander around rather than always wasteing gas (adding and removing gas constantly) just to be within 1% of a target number like the computer running a solenoid controlling the o2 would.</div><div>Steve</div><br><br><div>-------- Original message --------</div><div>From: Jef Driesen <jef@libdivecomputer.org> </div><div>Date:10/05/2017  21:37  (GMT+09:30) </div><div>To: Anton Lundin <glance@acc.umu.se> </div><div>Cc: Subsurface <subsurface@subsurface-divelog.org> </div><div>Subject: Re: [PATCH] Visualisation of individual oxygen sensor data for CCR   dives </div><div><br></div>On 2017-05-10 11:33, Anton Lundin wrote:<br>> On 10 May, 2017 - Jef Driesen wrote:<br>>> I've implemented the scaling factor now. See attached set of<br>>> patches. It took me a bit longer than expected because there were a<br>>> few cases where the ppO2 still ended up being zero. And that turned<br>>> out to be for dives without external O2 sensors enabled (e.g. fixed<br>>> setpoint mode). But the tricky part was that the external PPO2 bit<br>>> seems to be reversed. According to the documentation [1] external<br>>> PPO2 is 1 and internal PPO2 is 0. But based on the data I have, it<br>>> seems to be the opposite.<br>>> <br>>> BTW, I wonder if we should ignore the setpoint value when external<br>>> O2 sensors are used? Are setpoint still used in such case?<br>> <br>> Do we have any data from a Shearwater running as solenoid controller?<br>> <br>> Ex. On the JJ-CCR's they use a Shearwater Petrel with sensors which<br>> controls the o2 solenoid to try to get the o2 sensor values to match<br>> your configured setpoint.<br><br>I have data from several Petrels, but I have no idea how they were being <br>used. Is it possible to detect this somehow based on the data itself?<br><br>> That said, I think setpoint values are still interesting to see, to<br>> validate how well the controller did manage to try to keep the o2 close<br>> to the setpoint.<br><br>After looking at the data, I had the impression that the setpoint value <br>is "unused" because it seems to just contain some "dummy" value (for <br>example the last used value, or some default value).<br><br>I'll illustrate with an example dive from Steve's Petrel (*). This dive <br>has a fixed setpoint of 0.70 on every sample, but the ppo2 values range <br>from 0.32 to 1.74!<br><br>(*) I can send you the data if you want to take a look. I don't know if <br>Steve is okay with sending his dives to a public mailinglist, so I <br>didn't attach it to this email.<br><br>To me that doesn't look like the dive computer is even trying to keep <br>the ppo2 close to the setpoint. At least not to the setpoint value <br>that's stored in the sample. Hence my question whether this value is <br>relevant or not?<br><br>> Attached is the last iteration I did of the sensors patch. It has some<br>> minor differences from the one you included, but most of them isn't <br>> that<br>> relevant.<br><br>The part where you add 1024 to the calibration value is actually worse <br>then the original version where you only did that if the value is <br>smaller than 1000. It works (although not perfect) for the Predator, but <br>it breaks for the Petrel because it doesn't need any correction at all. <br>The variant with the if < 1000 works for the Petrel because the values <br>are always greater than 1000, and also for some Predators, but not all <br>because sometimes the values are greater than 1000 too. So if you want <br>to do it correctly, then you would need to check on the model as I did <br>in the third patch. If you want, I can move that code from the third <br>patch to the second one.<br><br>The SENSOR_AVERAGE is maybe a good idea to keep around. Might come in <br>handy once we have a way to communicate the type of value (sensor vs <br>average/voted).<br><br>> The only relevant information is that the adc offset value is probably<br>> in 0.025 mV as unit.<br>> Thats party based on the information in<br>> https://www.shearwater.com/wp-content/uploads/2016/07/O2-Offsets-Public-Notice-RevA.pdf<br><br>The info in the comments is indeed useful knowledge, but since we're not <br>using the adc values, it's pretty pointless to store them in the parser <br>struct. It's just a waste of space there. I know it's only a few bytes, <br>but I see no good reason to clutter the code with unused stuff.<br><br>> The only real comment about the code is that I would have liked to see<br>> the calibration factor kept as a int, and just change the unit factor<br>> from .00001 to .000022, between the models.<br><br>What would be the advantage of that? That would mean yet some other <br>field to store the scaling factor, or doing some "if (model == <br>PREDATOR)" when calculating the ppo2. Now it's just done once in <br>advance, making the conversion from millivolt to ppO2 independent of the <br>model. I'm even tempted to pre-multiply the value with the 100000.0 <br>factor too, to get rid of an extra<br><br>Jef<br>_______________________________________________<br>subsurface mailing list<br>subsurface@subsurface-divelog.org<br>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface<br></body>