Possible noise duration

I have a ATTiny powered from a coin cell waiting for press of one of two buttons wired “normally”: internal pull-up and momentary button to ground. It works well on the breadboard. However in the real application the wires to the buttons will be quite long - like 5 cm to button which is classic wall switch (like this one) and 5cm back to the ATTiny. So the total loop will be like 15-20 cm. Close to the ATTiny are wires to a mains powered motor so I am afraid there is potential for considerable noise. I decided to add a simple digital filter to remove noise spikes to avoid “button presses” caused by the noise. The idea is to reject press that does not read LOW continuously for some time. How long should I expect to be enough? I would guess a noise spike should take only a few microseconds so whole millisecond of LOW could be safely considered as real button press. Is it true?

Button presses are pretty slow. And you also have button bounce. So you can use a pretty long time before we humans see a delay. For example, the Bounce2-library (which you can just use for this) has a default of 10ms.

And t reduce noise in the hardware design, keep the signal and the GND to the button close. For example, twist the wires.

I think a 100nF capacitor to ground is a better way to filter out the noise.

There shouldn't be a loop, the two wires to the button should ideally be twisted pair to cancel any magnetic interference.

The wall switch is bulky, its terminals are about 3.5cm apart and nearly 1cm deep (I have overestimated the distance in the OP slightly). There is no way to avoid some loop.

I do not need debouncing (it simply sends wireless signal as long as a button is pressed - no harm comes from bouncing), I only need to avoid false button presses. The wireless command itself is about 50ms long so I don't want additional unnecessary delay. In fact I would like to start sending while the switch is still bouncing but it is sure it is bouncing button, not some random noise.

You don’t get it :wink: Bounce, or actually the software solutions against bounce, are also perfect to reject noise :wink: It also shows that you don’t really need fast at all, humans are dead slow.

So if you want a robust “false positive ignorer”, it makes sense to use a pretty long window. It doesn’t make sense to say you want to send as quick if possible if the input is human via a bulky switch :wink:

You are right, I was overthinking it. My reasoning:
We have a LED light in kitchen - professionally made. After you press the switch it takes eternity (nearly one second) to turn on. More than enough time to think something like "it did not turn on, it is probably broken/I did not press the switch enough". Really annoying and I want to avoid similar flaw. The command itself takes long to send - nearly 50ms - and the receiver may miss a few commands before it respond. I did not want to extend the period more than necessary.
But even 10ms debounce period would add only negligible 20% increase of the time. In the end I decided to use this (to use only minimal amount of memory):

byte localStateOfPins=PINB;
for (byte samples=255; samples; samples--) { //1 sample ~ 2.3us @ 2.4MHz main clock

stateOfPins is a global non-volatile variable; it is interesting that in AVR Studio manipulating the global variable instead of the local variable adds unnecessary STS instruction into the for loop, which makes the loop iteration about 3us (and needs additional 4 bytes of memory).

Still the original question is interesting IMO. How long is a noise able to hold the pin LOW in such setup? I would guess no more than a few microseconds. Surely it depends on the noise source but is some imaginable noise able to hold the pin low for considerably longer time? Such as 100us?

I would also think noise is pretty fast. But like we say in Dutch "meten is weten" (measuring is knowing for sure). And you also need to consider you might sample different spikes in a row.

And did you test if you send the command yourself it is fast? Reminds me of the first gen of LED lights which also tend to take a little to long and you also entered the "did I miss?"-state :stuck_out_tongue:

PS Are you really THAT tight on memory? :o

I am afraid measuring the possible noise reliably is nearly impossible. I will try this and see - no real harm will come from a false trigger. Only shame if it happens often enough to be noticed :wink:

It is not for the LEDs, it is for other device (the delay on LEDs is likely due to the power source lag).

I am using ATTiny13A with 1k of flash. It has too few resources for a fancy debouncing and some useful work at the same time. Since I believe it is not needed I won't take any additional measures.

I tested the switch with a logic analyzer. It bounces 1-2 ms when pressed and does not bounce on release. When pressed and released as quickly as possible it is pressed for over 100ms and released at least 150ms. Any real button press should cause at least two (more likely three) commands to be sent. So I have added a simple noise logging feature: when the first command is sent and the corresponding button is no longer pressed it is considered a noise, counter is incremented and saved to the EEPROM. One day I will read the value to see if any such false trigger happened.

Thanks for help

Sounds like a great job!

ATtiny13 is pretty small indeed. No idea how the whole wireless is doing but sounds like a great solution :slight_smile: