-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for control of switch bouncing. #187
Comments
Thanks! I remember recording some switches here while originally implementing the feature. Looking at the traces in the Logic Analyzer, some recordings looked very different from others. So it's indeed not trivial to model bouncing correctly. Luckily for us, for most use cases - it doesn't make a lot of difference. Seems like the duration is the most important parameter. |
Yes, duration is most important. But some effort should be placed on not making the bounces rhythmic - that is to say the width and separation of the bounces should not be regular, lest a sampling frequency be deceived. My current concept only for a hardware bounce simulator with parametric control (duration of closing and opening bounce) uses a LFSR to develop a random bit stream - either computed or using a device like the MM5837N Digital Noise Source IC, which is just an integrated LFSR. Or I will use white noise from a transistor leveled up to logic voltages. The inputs to the AVR have some hysteresis, so it is not necessary to model beyond random 0s and 1s. Seems like whatever you are doing now for 1 ms could be repeated N times, or perhaps reflected and repeated, reflected in time or tipped upside down 4 variations. Without knowing the least about what goes into the devices that we enjoy in the wokwi, it is hard to say this is easy or not. Of course so far, you have made everything look easy, like what you've done is impossible. <- said in French amposseeble! a7 |
I can confirm debounce code works in the simulator for the pushbutton and it sufficiently messes up switch reliability if not used- very realistic. |
Yes. The bouncing is fairly short (1-2 ms I think) and is useful to have. As is the ability to use the "bounce" attribute to turn off denouncing. Nice if it is something else you are working on and just want a switch or pushbutton with no real-world complications. I do have switches that bounce for a greater time, I reiterate my wish to have this be an adjustable attribute. Stress testing denounce code for them would be helped by being able to dial up the bounce in the sim. a7 |
The current bounce algorithm is based on "The Art of electronics" by Horowitz & Hill (second edition, page 506):
The actual algorithm is implemented as follows:
I'd love to hear thoughts about how to improve this (while keeping it as simple as possible). I haven't done the math, but it seems like the mean bouncing time is around 0.55ms, and the max time is 2.2ms. |
It seems simple. The "bounce" attribute is interpreted as the number of milliseconds it will take the switch to settle. The actual duration or number of bounces is not important as long as there is. Bouncing.
Like that. Just bounce the contacts for a specified number of milliseconds. Not sure the above code will compile ;-) but I hope the intent is clear . a7 |
That makes sense. As different switches behave differently and may alter based on the circuit they are in. I agree the key criteria is "bounce is present" vs "something is done to deal with bounce" Personally, I'm not concerned with how accurate the bounce is presented, just that it exists. Similar to resistors not testing if they are the correct value, providing DVOM readings, etc. Perhaps simply adding these tidbits to an introduction or Getting Started doc is sufficient. Also- if anyone has better debounce code, I am happy to standardize and settle on it. That is one of my goals of Tutorials- reusable and solid code. |
Closing as custom bouncing can now be achieved using custom chips |
I was caught off guard but thrilled to find the wokwi pushbutton object
by attribute.
Could we get something like
{ "bounce": "0" } // perfect non-bouncing switch
{ "bounce": "12"} // crappy cheap Arcade switch bounces for 12 milliseconds
No mention of "bounce" attribute takes the default, bounces for the documented 1 ms.
I think millisecond resolution on the duration is sufficient.
I could argue that 1 ms is a bit optimistic and lobby to change that, but I am not going to. Just make it something we can adjust.
This is useful for simulation of real world switches, and for torture testing debounce algorithms, like "what does this code do with 100 ms of bouncing" kinda thing.
Naive me thinks it's just a number in the implementation of the model bouncing, so.
TIA
alto777
The text was updated successfully, but these errors were encountered: