Sensor Failure Handeling

Looking for a best practice on handeling analog sensor failure.

In the event of failure, I’m essentially going to be reading float, which may be valid input for a given sensor.

Anyone have a best practice?

I’ve seen as suggestions: bounds, setting an upper and lower and if the swings swing through the bounds in too rapid of a fashion, invalidate the result.

Another was an array of values, and only treat as valid when the array was full. Any invalid measurement would empty the array.

Neither of these are really ideal, though, as the float could be inbounds, for n times and would all record as valid.

Anyone got any other methods?

post some code and lets take a look ?

Personally I stuff 10 readings into an array, toss the highest and lowest value and average the rest (mainly when using low spec or home made sensors) - industrial grade sensors generally don’t have this kind of issue though

You might consider some signal processing as @shanevanj has suggested. If you are trying to cope with missing readings then an average smoothing mechanism might not be that effective. You could look at a Simple (1D) Kalman Filter - devised by a Nasa rocket scientist and designed to cope with missing sensor inputs or readings significantly out of normal range.

I’m looking for practice when the sensor fails. Not at reading one or two times… but at working entirely.

Let’s look at the most extreme example… the sensor exploded, and took out the pull down.

Now you’ve got a floating pin. And the sensor is on the moon.

What would be best practice for having the sensor report invalid, rather than the voltage read?

The read is an abstract class. Any sensor, of any analog type implements the class, such that this->_ReadSensor(this->_sensorPin) returns the voltage read.

Each sensor then handles the response based on the sensor type.

There isn’t any code to post. That explains the entirety of it.

I like to incorporate this suggestion by @twospoons (take multiple readings at slightly different intervals) Link

Paul’s Example Code:

float Get_PO2(void) // read cylinder pressure
{
    int i;
    float temp =0;
    double acc=0;
    for (i=0;i<64;i++)  // long mutliread to get rid of noise
    {
        acc+=analogRead(Pcyl);
        delay(i);
    }
    acc=acc/64;
    temp= mapfloat(acc,  cyl_inlo,  cyl_inhi, 0, cyl_outhi);

But your failure detection would depend on the output of the individual sensor model when it fails .

This is definitely the top choice, now. Implementation is going to be interesting, though. I wonder what the lowest number of valid inputs possible is, as I’ll be memory constrained.

Out of curiosity, why the delay(i), which would be 0 the first time, n the nth time, rather than a fixed period?

See the link, the reason was later in the post:

I saw that, and that is interesting. But it has sparked (pun) a new question.

Suppose you have multiple sensors, all timed to run every second. Applying this same theory, that could, in an unlucky event, produce the same interference, yes?

Then it would be better, I suppose, to set the timers to fire in a range, and randomly assign the timing?

That may be another question for another day.

Something else to consider:
Once, I thought I had a faulty pressure sensor because I was seeing a large range in pressure readings on a compressed air system.

As it turns out, I was actually (accurately) measuring the transient pressures (surges) from the air compressor’s output. Performing various filtering techniques on the measurements was actually counter-productive.

Once I figured out that the sensor was actually giving me good data, I realized the Air System needed a surge tank. It was a reminder that filtered data = lost data.

Good advice. I log to a flash card. I just don’t display to a person who might panic.

I won’t be able to use the average method as it seems sensor dependent, and I’m looking for something a bit more model agnostic.

But thanks, it is interesting.

In code review, I’d wonder why acc is a double, when analogRead returns an int, though. Ah. Division by 64. Got it.

This from Stack seems to be in line with what I’m looking for, but I assume this is not possible, or would have been a pretty obvious first response, right?

Accepted answer:

“If you enable the pullup only, read the ADC, enable the pulldown only, read the ADC again, and the two readings are very different, you can reasonably conclude the signal is floating without any additional hardware.”

Well, that is somewhat dependent on your hardware setup. In particular the output impedance of the sensor - if its reasonably high you might still pull the readings around on a good sensor. If there’s an amplifier in between then that would tell you if the amp was disconnected but nothing about the sensor. I would be inclined to hardwire a high value resistive pull up (or down) to the sensor, so that any reading was forced out of bounds on failure of the sensor. What that is in practice will depend on sensor failure modes.

The type of sensor you describe would only return 0 if powered. A failed sensor could fail at the power level, and now it would have no return, and thus all you would have is a floating pin.

The problem is “how do you tell if a pin is floating, or actual input.”

And that is not based on sensor. A simple solution, if I wanted hardware, would be a sensor that always gives an address. And if the address isn’t found every run, treat it as disconnected.

Simple.

Not the problem.

Let’s say I order this fantastical hardware. It is a German made piece of engineering marvel.

Immediately upon placing the order, the manufacture, in Germany, places it in a box to ship. But I run up stairs, and flash the particle to read it on A5. But I don’t get back zero.

How can this be? That sensor is as missing as it can be. It is in Germany! The particle is in Tennessee. But how can that be? Because this isn’t a sensor hardware problem.

Let me say again: this isn’t a sensor hardware problem.

I’m also not looking for help. I’m looking for information. Please don’t confuse the two.

If you need a diagram, or code, or anything in order to consider how to differentiate a floating pin from valid input, then I’m specifically not looking for information from you.

Sorry if I wasn’t clear.

Even if someone may misunderstand your request but tries to be helpful, this kind of sarcasm will not really incentivise people to invest any more time into pitching ideas that may be hurled back at them in such fashion.

@shanevanj has been very helpful in lots of other threads but seeing that he has now retracted most of his well-meant posts is a statement in itself.

7 Likes

I agree with @ScruffR. Please remain mindful of the fact that the folks chiming in to help here are doing so purely out of goodwill. Let’s not forget the humans behind the keyboards.

7 Likes

If I were concerned about the values from a sensor not being correct, I would think about some simple sensor calibration. In other words, take another I/O and use it to switch on something that influences the sensor in some known way. Read the sensor to see if the “calibrated” value shows up. If so, then turn off the calibration and take your regular measurements.

Depending upon the sensor and what it is sensing, you might be able to determine if the sensor is working correctly by virtue of a known pattern of outputs from the sensor. For example, a critical sensor in modern electronic fuel injection systems in automobiles is the heated O2 (HO2 aka Lambda) sensor. This sensor measures whether the mixture that was burned in the last cylinder firing was rich or lean of the stoichiometric ratio. Since firing of the fuel in each cylinder is cyclical, the sensor outputs pulses. The height of the “resting” state of the sensor (between pulses from engine firing) can be used to determine if the sensor is operating correctly.

If calibrating the sensor between readings is not practical, perhaps redundant sensors is the answer. This may be expensive, depending upon the cost of the sensors, but it may be cheaper than the consequences of trusting a sensor that malfunctions.

I’m not sure calibrating will work, but thanks for reply.

Here is the thought experiment. Suppose I’m flying multiengine R/C planes and I need to know how much fuel I have left.

Right now, with my mock up, and no pressure transducer connected, my LCD alternates “1/4 tank” and “reserve.”

But that is due to float. The transducer isn’t connected.

If this were an actual thing I were to implement, my flight time guess would be better. Because I can’t solve this problem… in the way I want to solve it.

Which is only analog sensors, only particle.io boards, on my desk.

Because the ultimate goal is not build a reader for a pressure transducer, but to build a reader class for any analog sensor I connect.