Skip to content
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

Closed
alto777 opened this issue Sep 21, 2021 · 8 comments
Closed

Request for control of switch bouncing. #187

alto777 opened this issue Sep 21, 2021 · 8 comments
Labels
enhancement New feature or request open for vote Vote at https://wokwi.com/features

Comments

@alto777
Copy link

alto777 commented Sep 21, 2021

I was caught off guard but thrilled to find the wokwi pushbutton object

  • models bouncing
  • OR NOT!

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

@urish urish added enhancement New feature or request open for vote Vote at https://wokwi.com/features labels Sep 21, 2021
@urish
Copy link
Contributor

urish commented Sep 21, 2021

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.

@alto777
Copy link
Author

alto777 commented Sep 21, 2021

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

@DiskDoctor
Copy link

I can confirm debounce code works in the simulator for the pushbutton and it sufficiently messes up switch reliability if not used- very realistic.

@alto777
Copy link
Author

alto777 commented Dec 22, 2021

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

@urish
Copy link
Contributor

urish commented Dec 25, 2021

The current bounce algorithm is based on "The Art of electronics" by Horowitz & Hill (second edition, page 506):

When the switch is closed, the two contacts actually separate and reconnect, typically 10 to 100 times over a period of about 1ms.

The actual algorithm is implemented as follows:

iterations ← random number between 1 and 100
toggle_count ← iterations * 2 - 1
min_bounce ← 66ns
max_bounce ← 2.2ms / toggle_count
repeat toggle_count times:
  delay_time ← random number between min_bounce and max_bounce
  wait(delay_time)
  toggle pin

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.

@alto777
Copy link
Author

alto777 commented Dec 27, 2021

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.

pound sign define min_bounce 50 ns
pound sign define max_bounce 5 us

duration_of_bouncing ← get "bounce" attribute of this switch

if duration_of_bouncing is not  zero 
	while it is within the duration of bouncing
		toggle pin
		delay_time ← random number between min_bounce and max_bounce
		wait(delay_time)

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

@DiskDoctor
Copy link

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.

@urish
Copy link
Contributor

urish commented Mar 28, 2023

Closing as custom bouncing can now be achieved using custom chips

@urish urish closed this as completed Mar 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request open for vote Vote at https://wokwi.com/features
Projects
None yet
Development

No branches or pull requests

3 participants