Debouncing / Filter for Accel / Brake-Wire switches

I don't have any experience with triggering of accel switches or break-wires for in-flight timers, but for those of you who have already done this, what type of filtering are you using on your inputs to protect against noise / nuisance, or fault trips?

Going to use a simple RC and it will be on the input for a PIC18 uproc. I'm thinking probably a few hundred ms would probably adequate. A software debounce routine could also be utilized as well.

DMcCauley said:

I don't have any experience with triggering of accel switches or break-wires for in-flight timers, but for those of you who have already done this, what type of filtering are you using on your inputs to protect against noise / nuisance, or fault trips?

Going to use a simple RC and it will be on the input for a PIC18 uproc. I'm thinking probably a few hundred ms would probably adequate. A software debounce routine could also be utilized as well.

Click to expand...

What you do depends on exactly what data resolution you need, and what method of launch detection you're doing.

Break-wires are pretty simple. Remove the wire and you start your timer. You might want to RC filter the input, but the TC probably need to be only a few tens of milliseconds.

If you are using a mems accelerometer, you should hardware RC filter the imput to ~2 times the sampling period. If you are sampling at 100 Hz, the RC time constant should be ~20 milliseconds to get rid of high frequency noise on the input.

Additionally you need so determine what constitutes a lift-off. It's usually some average G-level for a given time. Some altimeters use delta 1.8 G for 1/2 second. (Can be tested by flipping the unit over.) Others use a higher G threshold and/or a shorter time.

To avoid noise issues most altimeters use an algorithm to determine lift-off from the accelerometer. The simplest method is to require the A/D cound to change to a value above the previous values by a given amount for a certain time level. This simple threshold G level method doesn't work if you have combustion instabilities that give negative acclerations that cause the rocket to vibrate so more sophisticated units look for average values.

You can also require a dual confirmation of an accelerometer by looking at the pressure transducer output, also appropriately filtered. You would make an acceleration level and a pressure decrease a lift-off criteria. That prevents chuffing or dropping the rocket from triggering the timers.

Bob

Thanks.

The acceleration switch i'm using is just that a simple 2G switch tied to a digital input.

I've used a 10nF cap with a 10k pull up resistor in the past to get 100ms of debounce. I've found that is usually good for most applications. However, the easiest is a software debounce. That will allow you to tweak the numbers through experimentation without having to remove and replace components on the board. That, and software tends to be a lot lighter than hardware.

EDIT: Forgot to mention that with the hardware set up above, the ripple in the switch bounce is well below the 0.8V threshold making it suitable for the PIC18. I've used the 18F4520 and 18F4550 a lot but usually always use software debounce for digital inputs. For the analog inputs to the onboard ADC you pretty much have to use hardware filtering for signal conditioning which is usually discussed in the datasheets for whatever accelerometer or pressure sensor you're using. On my recent altimeter card I forgot to put the RC conditioners on the pressure sensor I was using and it was a few hundred kPa off. Once I put in the conditioning filter it was spot on.