<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 10 May 2017 at 14:07, Jef Driesen <span dir="ltr"><<a href="mailto:jef@libdivecomputer.org" target="_blank">jef@libdivecomputer.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 2017-05-10 11:33, Anton Lundin wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
On 10 May, 2017 - Jef Driesen wrote:<br>
</span><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>
</blockquote>
<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>
</span></blockquote>
<br>
I have data from several Petrels, but I have no idea how they were being used. Is it possible to detect this somehow based on the data itself?<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>
</blockquote>
<br></span>
After looking at the data, I had the impression that the setpoint value is "unused" because it seems to just contain some "dummy" value (for example the last used value, or some default value).<br>
<br>
I'll illustrate with an example dive from Steve's Petrel (*). This dive has a fixed setpoint of 0.70 on every sample, but the ppo2 values range from 0.32 to 1.74! </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
(*) I can send you the data if you want to take a look. I don't know if Steve is okay with sending his dives to a public mailinglist, so I didn't attach it to this email.<br>
<br>
To me that doesn't look like the dive computer is even trying to keep the ppo2 close to the setpoint. At least not to the setpoint value that's stored in the sample. Hence my question whether this value is relevant or not?</blockquote><div><br></div><div>I have seen similar things on data from mCCRs, fixed setpoint and variable sensor data, the setpoint of 0.7 seems to be some sort of default value on shearwaters DCs.</div><div>When the DC is used only as a visual reference of the measured ppO2 the resulting data structure is logical.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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 that<br>
relevant.<br>
</blockquote>
<br></span>
The part where you add 1024 to the calibration value is actually worse then the original version where you only did that if the value is smaller than 1000. It works (although not perfect) for the Predator, but it breaks for the Petrel because it doesn't need any correction at all. The variant with the if < 1000 works for the Petrel because the values are always greater than 1000, and also for some Predators, but not all because sometimes the values are greater than 1000 too. So if you want to do it correctly, then you would need to check on the model as I did in the third patch. If you want, I can move that code from the third patch to the second one.<br>
<br>
The SENSOR_AVERAGE is maybe a good idea to keep around. Might come in handy once we have a way to communicate the type of value (sensor vs average/voted).<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>
<a href="https://www.shearwater.com/wp-content/uploads/2016/07/O2-Offsets-Public-Notice-RevA.pdf" rel="noreferrer" target="_blank">https://www.shearwater.com/wp-<wbr>content/uploads/2016/07/O2-Off<wbr>sets-Public-Notice-RevA.pdf</a><br>
</blockquote>
<br></span>
The info in the comments is indeed useful knowledge, but since we're not using the adc values, it's pretty pointless to store them in the parser struct. It's just a waste of space there. I know it's only a few bytes, but I see no good reason to clutter the code with unused stuff.<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>
</blockquote>
<br></span>
What would be the advantage of that? That would mean yet some other field to store the scaling factor, or doing some "if (model == PREDATOR)" when calculating the ppo2. Now it's just done once in advance, making the conversion from millivolt to ppO2 independent of the model. I'm even tempted to pre-multiply the value with the 100000.0 factor too, to get rid of an extra<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
Jef</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>_________________<br>
subsurface mailing list<br>
<a href="mailto:subsurface@subsurface-divelog.org" target="_blank">subsurface@subsurface-divelog.<wbr>org</a><br>
<a href="http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface" rel="noreferrer" target="_blank">http://lists.subsurface-divelo<wbr>g.org/cgi-bin/mailman/listinfo<wbr>/subsurface</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>// Jocke</div></div>
</div></div>