# Sensor Failure Handeling

**URL:** <https://community.particle.io/t/sensor-failure-handeling/53679>\
**Category:** General\
**Created:** [December 10, 2019, 3:48pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679 "2019-12-10T15:48:28Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![dkkelso](https://avatars.discourse-cdn.com/v4/letter/d/d26b3c/32.png) [@dkkelso](https://community.particle.io/u/dkkelso)\
**Post date:** [December 10, 2019, 3:48pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/1 "2019-12-10T15:48:28Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![shanevanj](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/shanevanj/32/21186_2.png) [@shanevanj](https://community.particle.io/u/shanevanj)\
**Post date:** [December 10, 2019, 3:54pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/2 "2019-12-10T15:54:28Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\
**Post date:** [December 10, 2019, 4:05pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/3 "2019-12-10T16:05:13Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dkkelso](https://avatars.discourse-cdn.com/v4/letter/d/d26b3c/32.png) [@dkkelso](https://community.particle.io/u/dkkelso)\
**Post date:** [December 10, 2019, 4:23pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/4 "2019-12-10T16:23:39Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![dkkelso](https://avatars.discourse-cdn.com/v4/letter/d/d26b3c/32.png) [@dkkelso](https://community.particle.io/u/dkkelso)\
**Post date:** [December 10, 2019, 4:26pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/5 "2019-12-10T16:26:36Z")

</div>

> [@shanevanj](#):
>
> post some code and lets take a look ?

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.

---

<div class="post-metadata">

**Author:** ![Rftop](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rftop/32/16896_2.png) [@Rftop](https://community.particle.io/u/Rftop)\
**Post date:** [December 10, 2019, 4:36pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/6 "2019-12-10T16:36:16Z")

</div>

I like to incorporate this suggestion by @twospoons (take multiple readings at slightly different intervals) [Link](https://community.particle.io/t/air-pressure-senor-analog-read-fluctuates/48101/17?u=rftop)

Paul’s Example Code:

```cpp
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 .

---

<div class="post-metadata">

**Author:** ![dkkelso](https://avatars.discourse-cdn.com/v4/letter/d/d26b3c/32.png) [@dkkelso](https://community.particle.io/u/dkkelso)\
**Post date:** [December 10, 2019, 4:36pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/7 "2019-12-10T16:36:51Z")

</div>

> [@armor](#):
>
> Simple (1D) Kalman Filter

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.

---

<div class="post-metadata">

**Author:** ![dkkelso](https://avatars.discourse-cdn.com/v4/letter/d/d26b3c/32.png) [@dkkelso](https://community.particle.io/u/dkkelso)\
**Post date:** [December 10, 2019, 4:39pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/8 "2019-12-10T16:39:13Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Rftop](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rftop/32/16896_2.png) [@Rftop](https://community.particle.io/u/Rftop)\
**Post date:** [December 10, 2019, 4:40pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/9 "2019-12-10T16:40:40Z")

</div>

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

> [@Air pressure senor analog read fluctuates](https://community.particle.io/t/air-pressure-senor-analog-read-fluctuates/48101/17):
>
> The variable delay helps avoid issues with single frequency interference, which could get aliased down to DC if you were really unlucky. If this seems excessive its not, as my system depends heavily on accurate pressure readings.  
> I use the mapfloat() function to convert to bar using my calibration values.

---

<div class="post-metadata">

**Author:** ![dkkelso](https://avatars.discourse-cdn.com/v4/letter/d/d26b3c/32.png) [@dkkelso](https://community.particle.io/u/dkkelso)\
**Post date:** [December 10, 2019, 4:46pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/10 "2019-12-10T16:46:24Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Rftop](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rftop/32/16896_2.png) [@Rftop](https://community.particle.io/u/Rftop)\
**Post date:** [December 10, 2019, 4:49pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/11 "2019-12-10T16:49:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dkkelso](https://avatars.discourse-cdn.com/v4/letter/d/d26b3c/32.png) [@dkkelso](https://community.particle.io/u/dkkelso)\
**Post date:** [December 10, 2019, 4:56pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/12 "2019-12-10T16:56:32Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dkkelso](https://avatars.discourse-cdn.com/v4/letter/d/d26b3c/32.png) [@dkkelso](https://community.particle.io/u/dkkelso)\
**Post date:** [December 10, 2019, 9:45pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/13 "2019-12-10T21:45:05Z")

</div>

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?

> <https://electronics.stackexchange.com/questions/99760/circuit-to-detect-floating-signal-line>

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.”

---

<div class="post-metadata">

**Author:** ![twospoons](https://avatars.discourse-cdn.com/v4/letter/t/bbce88/32.png) [@twospoons](https://community.particle.io/u/twospoons)\
**Post date:** [December 10, 2019, 9:56pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/14 "2019-12-10T21:56:50Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dkkelso](https://avatars.discourse-cdn.com/v4/letter/d/d26b3c/32.png) [@dkkelso](https://community.particle.io/u/dkkelso)\
**Post date:** [December 11, 2019, 1:53pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/16 "2019-12-11T13:53:03Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dkkelso](https://avatars.discourse-cdn.com/v4/letter/d/d26b3c/32.png) [@dkkelso](https://community.particle.io/u/dkkelso)\
**Post date:** [December 11, 2019, 3:50pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/18 "2019-12-11T15:50:12Z")

</div>

> [@shanevanj](#):
>
> If you get 0 mA the sensor is missing, broken or off. So failure can be detected.

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.

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [December 11, 2019, 5:09pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/19 "2019-12-11T17:09:56Z")

</div>

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.

> [@Welcome! Using Particle Forums and Forum Etiquette](https://community.particle.io/t/welcome-using-particle-forums-and-forum-etiquette/14):
>
> Welcome to the Particle Forums! We’re excited to have some helpful, interesting and engaging conversations here on the boards. As you get started, please take a minute to look over some guidelines for getting the most out of the forums. First, a few notes on what we expect from community members: Play nice. People are trying to help, so there’s no need for attitude or general rudeness. Politeness will beat terseness every day of the week Give the community a little bit of time to answer your …

---

<div class="post-metadata">

**Author:** ![marekparticle](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/marekparticle/32/22793_2.png) [@marekparticle](https://community.particle.io/u/marekparticle)\
**Post date:** [December 11, 2019, 6:44pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/21 "2019-12-11T18:44:40Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![BobG](https://avatars.discourse-cdn.com/v4/letter/b/ebca7d/32.png) [@BobG](https://community.particle.io/u/BobG)\
**Post date:** [December 17, 2019, 6:52am UTC](https://community.particle.io/t/sensor-failure-handeling/53679/22 "2019-12-17T06:52:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dkkelso](https://avatars.discourse-cdn.com/v4/letter/d/d26b3c/32.png) [@dkkelso](https://community.particle.io/u/dkkelso)\
**Post date:** [December 17, 2019, 1:36pm UTC](https://community.particle.io/t/sensor-failure-handeling/53679/23 "2019-12-17T13:36:21Z")

</div>

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](http://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.

[Next page](https://community.particle.io/t/sensor-failure-handeling/53679.md?page=2)