Clean up Shearwater string handling

[Linus Torvalds]

On Jul 9, 2017 12:06, "Dirk Hohndel" <dirk at hohndel.org> wrote:

Your code is a lot more beautiful and better structured> +     if (state >=
1 && state <= 7) {
> +             static const char *states[8] = {
> +                     "",             // 000 - No state bits, not used
> +                     "normal",       // 001 - only normal
> +                     "critical",     // 010 - only critical
> +                     "critical",     // 011 - both normal and critical
> +                     "warning",      // 100 - only warning
> +                     "warning",      // 101 - normal and warning
> +                     "critical",     // 110 - warning and critical
> +                     "critical",     // 111 - normal, warning and
critical

I know that this is wrong. The state is '0' when the battery is normal.


Look again.

That's a *bitmap* of the states we've seen.

So state 0 becomes *bit* zero, which has value 1.

State 1 (critical) becomes bit 1, so value 2.

If the dive saw pressures with both normal and critical states, at have
both bit zero and bit one set, so 3.

So the only time you see zero is when *no* state bits are set.

Now, I haven't *tested* any of this, since I don't have any pressure data.

I haven't seen warning or critical, yet, but I bet that they meant the
comment quite literally: the top four bits give you values from 0 to 15, 0
is normal, 1 is critical, 2 is warning, rest is unused. Being able to
combine them like bits would be just weird and nonsensical. What on earth
does it mean to be both normal and critical?

.
Those boots come in every sample. So normal and critical means that at saw
different samples - some with normal battery and some with critical.

And that *is* meaningful, and it's interesting data - it may mean that the
battery is on the edge.

Also, the four upper bits may end up having other meaning too. I didn't
want to bother putting in the "no communication" state bits, because I
wonder whether you might get those at the beginning and/or end of dives,
but it might we'll be interesting to see that you lost communication during
the dive for a while. Again, that shouldn't overwrite the other cases, but
exactly *because* this is a bitmap of all the states we've seen, it's quite
reasonable and possible.

So please rethink.

Because you're code was uglier, and it literally threw data away by just
looking at the last sample with transmitter data.

What if the transmitter was critical during the middle of the dive because
it got cold, but then warmed up as you ascended, and was only warning at
the end of the dive? Your code - because it only remembered one value -
couldn't handle that.

The bitmap code handles it very naturally, along with other potential flags.

     Linus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170709/069bd368/attachment.html>