Sensor Failure Handeling

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.


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.


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.


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

@dkkelso, doing a little research on the interweb, there is no single technique for detecting an open or float condition between an analog sensor and the ADC input of the processor. It is very dependent on the sensor characteristics. A common approach is to discharge then pre-charge the ADC input capacitance to gauge if the input is being driven by the sensor or is floating. Using the built-in pull-up/down resistors with values of 40-50K ohms, this can work if the sensor has a larger output impedance but not so well when it is below 100K ohms. Can you share the model of pressure transducer you are using? Is it connected directly to the ADC input or through some conditioning circuit?

Hi. Thanks for the response.

I’m working on an abstract class that will take any sensor. The pressure transducer is just one example.

I don’t like having to write code over and over again, when I can just write it once.

So the transducer is an example. I have 25 more.

I don’t want to have to write code 26 times x n variations when I can just plug and play.

The common method you describe is what I showed from Stack, I believe.

But readAnalog on particle since like 0.53 doesn’t allow pull up or down, and I don’t believe can be overridden.

What I’m getting at is that I’m not certain that the common way is even possible using off the shelf particle firmware.

You are correct though it may be possible to force the pin into “analog” or “alternate function” INPUT mode which may allow the pull resistor to be applied, thus affecting the ADC input caps. Perhaps @rickkas7 has some hands-on knowledge he can chime in with.

I couldn’t get pull-up or pull-down on an analog input to work on a Photon. I’m not sure the STM32F2xx supports doing that. In any case, this code does not work:

// Non-working code, do not use
void setAdcPullDown(pin_t pin) {
	// Read once to initialize

    Hal_Pin_Info* PIN_MAP = HAL_Pin_Map();

    GPIO_TypeDef *gpio_port = PIN_MAP[pin].gpio_peripheral;
    pin_t gpio_pin = PIN_MAP[pin].gpio_pin;

    GPIO_InitTypeDef GPIO_InitStructure = {0};

    GPIO_InitStructure.GPIO_Pin = gpio_pin;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AN;

    GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
    PIN_MAP[pin].pin_mode = AN_INPUT;

    GPIO_Init(gpio_port, &GPIO_InitStructure);

I ordered a debugger and an argon and a breakout adc so I’ll keep playing and see what I can come up with.

If I can pull it off on the breakout, then that’ll be good enough.

If it is that critical to determine that the sensor is functioning, maybe a voltage divider circuit can solve it? So it’s a simple and cheap hardware modification plus very little code to confirm. You’ll have to check my logic:

You’d have to sacrifice another input pin. And it will compress the range of values you can read from the sensor.
If the sensor is connected and working then the confirmation leg of the voltage divider will remain constant (say analog read of 2048), but as soon as the sensor fails and the 2nd leg is broken then the confirmation leg will shoot to 4095. Then you will know that the sensor leg must be floating.
Alternatively, depending on the circuit you may need to sum the confirmation leg and sensor leg which will be constant when working, Regardless, the confirmation leg reading will be near max when the sensor fails.

If you’d only consider software solutions this will not work for you.

This is interesting, thanks. I believe I would need one per sensor connected? So each sensor, of which there may be n sensors, would need n*2 input pins.

Not the end of the world, but limiting. If it becomes necessary, this would also be something I would be willing to do.

If you are certain that your failure mode is going to be open-circuit, you can use this method which leverages the parasitic capacitance of the pin when you suspect a problem:

Write digital HI
Set pin as input
Read digital state

Write digital LO
Set pin as input
Read digital state

Write digital HI
Set pin as input
Read digital state

If you get the values HI, LO, HI, then you have a pretty good idea that the pin is floating.

Please ensure the sensor can handle such an input, or protect it with a resistor or somesuch so you don’t damage it by back-driving it when you falsely suspect an error.

Thinking about this some more, there may be a range of mid-level values of sensor input that will interact badly with the hysteresis of the digital input, so you can substitute analog reads as long as they happen quickly enough and do not pull off too much charge.

I like the simplicity of this methodology a lot. If I damage a sensor or three, it isn’t the end of the world. I’ll just research a replacement thoroughly. And I can weed them out on the bench pretty quickly, most like.

Where this might give me trouble is some of the sensors are 5V. And because of that, I think the breakout ADC is necessary. I’m not sure how writing back to the breakout and then to the sensor is going to go. But I’m going to try it.

And if it fails, I can have two classes, a 3V3 analog and a breakout, and use this for the 3V3, and try something else for the breakout.