The HwOS devices logs ppo2 sensor values even in Auto / Fixed SP mode, but they log them as reading zero, if there are no sensors there.
This skips us reporting those zero values.
Signed-off-by: Anton Lundin glance@acc.umu.se ---
This shows one of the flaws with re-using the DC_SAMPLE_PPO2 value.
Should we report unconnected sensors? how should a application actually handle them?
Maybee we should look at the ppO2 value too, but for now this POC only looked at the mV values.
src/hw_ostc_parser.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/src/hw_ostc_parser.c b/src/hw_ostc_parser.c index 6db9d27..954f6f7 100644 --- a/src/hw_ostc_parser.c +++ b/src/hw_ostc_parser.c @@ -885,6 +885,9 @@ hw_ostc_parser_samples_foreach (dc_parser_t *abstract, dc_sample_callback_t call value = data[offset + j]; } else { value = data[offset + j * 3]; + // Skip zero mV sensors, as they are most likely unconnected + if (array_uint16_le (data + offset + j * 3 + 1) == 0) + continue; } sample.ppo2 = value / 100.0; if (callback) callback (DC_SAMPLE_PPO2, sample, userdata);
On 2015-08-31 23:06, Anton Lundin wrote:
The HwOS devices logs ppo2 sensor values even in Auto / Fixed SP mode, but they log them as reading zero, if there are no sensors there.
Am I right that in this particular case all three ppo2 values are zero (e.g. no sensors at all)? I remember seeing that in some of the original OSTC memory dumps. Then it makes indeed sense to omit the ppo2 values. But if there is one or more non-zero values, I don't think we should omit just the zero ones.
Jef
On 03 September, 2015 - Jef Driesen wrote:
On 2015-08-31 23:06, Anton Lundin wrote:
The HwOS devices logs ppo2 sensor values even in Auto / Fixed SP mode, but they log them as reading zero, if there are no sensors there.
Am I right that in this particular case all three ppo2 values are zero (e.g. no sensors at all)? I remember seeing that in some of the original OSTC memory dumps. Then it makes indeed sense to omit the ppo2 values. But if there is one or more non-zero values, I don't think we should omit just the zero ones.
In the Auto / Fixed SP mode all three values are zero, and stays zero during the hole dive.
This fix isn't bug-free, eg if a sensor gets disconnected during a dive, we should report zero for that, but it feels like the lesser evil than the current code.
I dropped a mail to HW suggesting to just not log any sensors in Auto / Fixed SP mode which would kinda make sense. Right now the HwOS based devices logs ppo2 in all CCR modes.
//Anton
On 2015-09-03 20:01, Anton Lundin wrote:
On 03 September, 2015 - Jef Driesen wrote:
On 2015-08-31 23:06, Anton Lundin wrote:
The HwOS devices logs ppo2 sensor values even in Auto / Fixed SP mode, but they log them as reading zero, if there are no sensors there.
Am I right that in this particular case all three ppo2 values are zero (e.g. no sensors at all)? I remember seeing that in some of the original OSTC memory dumps. Then it makes indeed sense to omit the ppo2 values. But if there is one or more non-zero values, I don't think we should omit just the zero ones.
In the Auto / Fixed SP mode all three values are zero, and stays zero during the hole dive.
This fix isn't bug-free, eg if a sensor gets disconnected during a dive, we should report zero for that, but it feels like the lesser evil than the current code.
What I meant was something like the attached patch: If all three values are zero, there are probably no sensors, and we ignore all three ppo2 samples. But if there is at least one non-zero value, we report all three values.
I dropped a mail to HW suggesting to just not log any sensors in Auto / Fixed SP mode which would kinda make sense. Right now the HwOS based devices logs ppo2 in all CCR modes.
That's sounds like the right solution to me. But even if this gets fixed in a future firmware, we'll still need a fix on our side for all past dives.
Jef
On 2015-09-04 08:28, Jef Driesen wrote:
What I meant was something like the attached patch: If all three values are zero, there are probably no sensors, and we ignore all three ppo2 samples. But if there is at least one non-zero value, we report all three values.
Now with the patch attached!
Jef
On 04 September, 2015 - Jef Driesen wrote:
On 2015-09-04 08:28, Jef Driesen wrote:
What I meant was something like the attached patch: If all three values are zero, there are probably no sensors, and we ignore all three ppo2 samples. But if there is at least one non-zero value, we report all three values.
Now with the patch attached!
Yea, this one is a bit better than the quite blunt one i suggested, but still it behaves weirdly in the case you would have one cell who is unconnected (floating connection?) in the beginning and gets connected a couple of samples in. Then the sensors would be re-numbered.
This would be solved with having sensor id's =)
//Anton
On 2015-09-09 14:12, Anton Lundin wrote:
On 04 September, 2015 - Jef Driesen wrote:
On 2015-09-04 08:28, Jef Driesen wrote:
What I meant was something like the attached patch: If all three values are zero, there are probably no sensors, and we ignore all three ppo2 samples. But if there is at least one non-zero value, we report all three values.
Now with the patch attached!
Yea, this one is a bit better than the quite blunt one i suggested, but still it behaves weirdly in the case you would have one cell who is unconnected (floating connection?) in the beginning and gets connected a couple of samples in. Then the sensors would be re-numbered.
This would be solved with having sensor id's =)
I'm probably misunderstanding, but my patch should avoid the renumbering problem. Assume we have 3 sensors, and one of them is disconnected, then we get something like this:
ppO2: 0 Y Z (Sensor 1 disconnected) ppO2: X 0 Z (Sensor 2 disconnected) ppO2: X Y 0 (Sensor 3 disconnected)
if it gets reconnected again later:
ppO2: X Y Z (All sensors connected)
Thus the order is always preserved. The i-th sample value is always from the i-th sensor. Thus although there is no explicit sensor id, it's implicit in the sample index. Only when all three sensors are disconnected, we drop the ppO2 sample completely.
Am I missing something else?
Jef
On 09 September, 2015 - Jef Driesen wrote:
On 2015-09-09 14:12, Anton Lundin wrote:
On 04 September, 2015 - Jef Driesen wrote:
On 2015-09-04 08:28, Jef Driesen wrote:
What I meant was something like the attached patch: If all three values are zero, there are probably no sensors, and we ignore all three ppo2 samples. But if there is at least one non-zero value, we report all three values.
Now with the patch attached!
Yea, this one is a bit better than the quite blunt one i suggested, but still it behaves weirdly in the case you would have one cell who is unconnected (floating connection?) in the beginning and gets connected a couple of samples in. Then the sensors would be re-numbered.
This would be solved with having sensor id's =)
I'm probably misunderstanding, but my patch should avoid the renumbering problem. Assume we have 3 sensors, and one of them is disconnected, then we get something like this:
ppO2: 0 Y Z (Sensor 1 disconnected) ppO2: X 0 Z (Sensor 2 disconnected) ppO2: X Y 0 (Sensor 3 disconnected)
if it gets reconnected again later:
ppO2: X Y Z (All sensors connected)
Thus the order is always preserved. The i-th sample value is always from the i-th sensor. Thus although there is no explicit sensor id, it's implicit in the sample index. Only when all three sensors are disconnected, we drop the ppO2 sample completely.
Am I missing something else?
Was just me missreading the patch.
Go with this one.
//Anton
-
Anton Lundin -
Jef Driesen