I've noticed that many people use a 1 ms time interval to determine the stable state of a button press or release. Recently, I came across a thread https://forum.allaboutcircuits.com/threads/debouncing-a-switch-in-software-using-a-pic16f72.100339/where members were discussing the use of 1 ms timer intervals for this purpose. However, I'm aware that the debounce time of a button depends on the type of button. For instance, consider this push button, which has a maximum debounce period of 50 ms.

I'm interested about why people choose to take only 10, 20, or 25 samples within every 1 ms intervals. It seems like a relatively small number of samples given the potential debounce period.

 

I would do it with two samples 50ms apart.

 

I would do it with two samples 50ms apart.

Two samples" means taking two consecutive readings of the button's state, and these samples are obtained with a 50-millisecond time gap between them.

So It's possible to take readings at intervals shorter than the debounce period. That's why some choose to sample the button's state at 5ms, 10ms, 20ms, or even as quickly as 1ms time interval

 

Two samples" means taking two consecutive readings of the button's state, and these samples are obtained with a 50-millisecond time gap between them.

So It's possible to take readings at intervals shorter than the debounce period. That's why some choose to sample the button's state at 5ms, 10ms, 20ms, or even as quickly as 1ms time interval

There is no useful information obtained by sampling at 1ms intervals.

 

There is no useful information obtained by sampling at 1ms intervals.

It may seem puzzling why some individuals use 1ms intervals for button state sampling if it doesn't give useful information. Even I gave refrance link where forum member @JohnInTX suggesting post 3 in a thread discussion.

 

Unless you are really concerned about response time to a mechanical switch change, a 10-20ms sample period should be more than sufficient.

 

It may seem puzzling why some individuals use 1ms intervals for button state sampling if it doesn't give useful information. Even I gave refrance link where forum member @JohnInTX suggesting post 3 in a thread discussion.

I've used chip based debounce in machines where there is high EMI/RFI to protect from pin related ESD failures.
https://www.analog.com/en/technical...nd-relays-to-the-real-world-in-real-time.html
https://www.analog.com/en/technical-articles/switch-bounce-and-other-dirty-little-secrets.html

IMO it makes more sense to resample out of the expected bounce time zone of tens of milliseconds for a typical mechanical switch contact.

 

I've noticed that many people use a 1 ms time interval to determine the stable state of a button press or release. Recently, I came across a thread https://forum.allaboutcircuits.com/threads/debouncing-a-switch-in-software-using-a-pic16f72.100339/where members were discussing the use of 1 ms timer intervals for this purpose. However, I'm aware that the debounce time of a button depends on the type of button. For instance, consider this push button, which has a maximum debounce period of 50 ms.

I'm interested about why people choose to take only 10, 20, or 25 samples within every 1 ms intervals. It seems like a relatively small number of samples given the potential debounce period.

As you say, not all switch debounce periods are the same, so it should not be surprising that not all approaches to software debouncing are the same.

The thread you pointed to discussed the impact of the debounce window being longer than the sampling period.

You have two competing effects that have to be considered -- being sure that you catch every legitimate switch transition while also being sure that you don't falsely conclude that a switch transitioned when it was actually just a bounce. The first sets a minimum sampling rate that you MUST have, while the second sets a maximum sampling rate that it is USEFUL to have. You can't sample any slower than the minimum and meet your goals, but you can sample faster than that maximum useful rate and still meet your goals, but it can make the software more complex than it needs to be.

A lot of it comes down to whether you already have a timer running for something else that you can piggyback your debounce code onto. If so, then it may be worth the added complexity.

 

My understanding is that this bouncing effect occurs due to the button's mechanical characteristics. It can happen when pressing, releasing, or quickly pressing and releasing the button.

One question that often arises is, Does bounce occur when a button is continuously held down for long time?

 

My understanding is that this bouncing effect occurs due to the button's mechanical characteristics. It can happen when pressing, releasing, or quickly pressing and releasing the button.

One question that often arises is, Does bounce occur when a button is continuously held down for long time?

No.

 

If you are scanning the buttons then a 1ms scan interval might be appropriate.
I would have used interrupts to get the initial trigger and then check it 20-50ms later.

 

My understanding is that this bouncing effect occurs due to the button's mechanical characteristics. It can happen when pressing, releasing, or quickly pressing and releasing the button.

One question that often arises is, Does bounce occur when a button is continuously held down for long time?

Bounce will happen when the button is pressed, but then it should stay in a stable state while it remains pressed (unless the button is flaky or not held down firmly enough), but it will bounce again when the button is released.

Switch bounce is basically a phenomenon that happens when the switch contacts are very, very close together but not quite in contact. There are a number of ways to describe what is happening, some more accurate than others, but perhaps the easiest to visualize is that the switch contacts are never truly stationary. They are constantly moving back and forth, even if only from thermal motion, let alone physical motion of the actuator. So when they are real close, this tiny motion is enough cause them to touch, and then untouch, and then touch, and then untouch, and keep doing this until they are either firmly in contact or firmly separated.

 

I've noticed that many people use a 1 ms time interval to determine the stable state of a button press or release. Recently, I came across a thread https://forum.allaboutcircuits.com/threads/debouncing-a-switch-in-software-using-a-pic16f72.100339/where members were discussing the use of 1 ms timer intervals for this purpose. However, I'm aware that the debounce time of a button depends on the type of button. For instance, consider this push button, which has a maximum debounce period of 50 ms.

I'm interested about why people choose to take only 10, 20, or 25 samples within every 1 ms intervals. It seems like a relatively small number of samples given the potential debounce period.

The idea is to wait long enough for the contacts to stabilize (stop bouncing) before reading the switch state.
50ms is a good wait period for a reasonably good switch. But even 50ms can be too short if reading a poorly made (cheap) switch.

 

For more than two decades now, I have been using the same debouncing routine I wrote, with an interval of 25 ms. Always worked flawlessly.

To be sure, for a long time I tested my designs using a keypad implemented with the worst switches I could get locally.

Since it is not a blocking routine, I did not care much of making it shorter, albeit in some occasions it went down to 10 ms.

 

If you are scanning the buttons then a 1ms scan interval might be appropriate.
I would have used interrupts to get the initial trigger and then check it 20-50ms later.

Do you utilizes a blocking or non-blocking routine to obtain a stable state ?

 

Do you utilizes a blocking or non-blocking routine to obtain a stable state ?

It depends on the complexity of the application whether I use blocking or non-blocking event checking. It has nothing to do with detecting a stable state.

 

It depends on the complexity of the application whether I use blocking or non-blocking event checking. It has nothing to do with detecting a stable state.

Consider applications where multiple buttons are used, such as a TV remote, calculator, or a password-based locker. In these cases, software-based solutions for reading button inputs can be implemented.

Using interrupt-driven input handling is a common and effective software-based solution to read button inputs without blocking the CPU when no input is detected. It allows the system to respond to button presses immediately and efficiently, making it a suitable approach for various applications

 

Consider applications where multiple buttons are used, such as a TV remote, calculator, or a password-based locker. In these cases, software-based solutions for reading button inputs can be implemented.

Using interrupt-driven input handling is a common and effective software-based solution to read button inputs without blocking the CPU when no input is detected. It allows the system to respond to button presses immediately and efficiently, making it a suitable approach for various applications

Thanks. Good to know.

 

Consider applications where multiple buttons are used, such as a TV remote, calculator, or a password-based locker. In these cases, software-based solutions for reading button inputs can be implemented.

Using interrupt-driven input handling is a common and effective software-based solution to read button inputs without blocking the CPU when no input is detected. It allows the system to respond to button presses immediately and efficiently, making it a suitable approach for various applications

What does this have to do with your question?

Sounds like a ChatGPT-generated response.

 

What does this have to do with your question?

Sounds like a ChatGPT-generated response.

Not really, these are some common examples that we see in our daily life

Thanks. Good to know.

I'm a bit confused by your differing opinions. In post 4, you mentioned that sampling at a 1 ms interval might not be a useful approach. However, in post 11, you suggested it could be appropriate. When I asked about your code preference blocking none blocking, you mentioned it depends on the application. So, I provided some real-world examples we use daily.

I was expecting clarification from your side. I am not demanding but it would be helpful to understand if you could provide a real example to illustrate your point.