Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Debounce a Contact (2014)

ganssle.com

Post reply on HN
Print view View original

61–70 of 82 posts

Re: How to Debounce a Contact (2014)

#61

Post by myself248 »

theamk wrote: post #44
somat wrote: post #16

Earlier quoted context omitted.

nobody cares enough to actually do it. but what would it take to have near instantaneous channel changes again?, prestarting a second stream in the background? And realistically the linear array of channels is also dead so it really does not matter. so I guess the modern equivalent is having a snappy UI. A horrible idea, as if our current tv features were not already bad enough. the modern equivalent to quick channel…

a workaround for IP-based TVs may be some sort of splash/loading screen that shows recent-ish screenshot of the channel very quickly. It'd still take a long time for picture to start moving, but at least user will see something and could switch away quickly if they don't care about content at all. Of course this will be non-trivial on server side - constantly decode each channel's stream, take a snapshot every few se…

It could simply be the most recent I-frame from the other stream in question. That would require neither decoding nor encoding on the server's part, merely buffering, and I suspect transport-stream libraries have very optimized functions for finding I-frames.

Furthermore, once a user starts flipping channels, since most flipping is just prev/next, you could start proactively sending them the frames for the adjacent channels of where they are, and reduce the show-delay to nearly nothing at all. When they calm down and haven't flipped for a while, stop this to save bandwidth.

Re: How to Debounce a Contact (2014)

#62

Post by nomel »

knodi123 wrote: post #43
the__alchemist wrote: post #26

I've been using the perhaps-too-simple: - Button triggers interrupt - Interrupt starts a timer - Next time interrupt fires, take no action if the timer is running. (Or use a state variable of some sort) Of note, this won't work well if the bounce interval is close to the expected actuation speed, or if the timeout interval isn't near this region.

> this won't work well if the bounce interval is close to the expected actuation speed lol, or you could do what my TV does- say "to hell with user experience" and use an interrupt timer anyway. If I hold down my volume-up button (The physical one on the TV!), I get a quick and fluid increase. But if I hammer the button 4 times per second, the volume still only goes up 1 ticke per second.

Loosely related, my HiSense TV has a wifi remote that apparently sends separate key up and down events to the TV. If the wifi happens to go down while you're holding the volume up button, it never sees the "key up" so will just hold whatever button indefinitely, including the volume button, which is how I discovered it.

Re: How to Debounce a Contact (2014)

#63

Post by HeyLaughingBoy »

kragen wrote: post #41
Cumpiler69 wrote: post #39

Earlier quoted context omitted.

>Plenty of embedded microcontrollers in the 70s Weren't those just PC computers and less microcontrollers?

No, though chips like the 80186 did blur the line. But what I mean is that different companies sold things like 8051s with BASIC in ROM. Parallax had a very popular product in this category based on a PIC, you've probably heard of it: the BASIC Stamp.

Intel 8052AH-BASIC. I loved the manual for that chip! Written with a sense of irreverence that was very unlike Intel.

Re: How to Debounce a Contact (2014)

#64

Post by nomel »

the__alchemist wrote: post #26

I've been using the perhaps-too-simple: - Button triggers interrupt - Interrupt starts a timer - Next time interrupt fires, take no action if the timer is running. (Or use a state variable of some sort) Of note, this won't work well if the bounce interval is close to the expected actuation speed, or if the timeout interval isn't near this region.

This is functionally identical to the capacitive approach. Pressing the button charges the cap whose voltage decays when released (starts the timer). If the button is pressed before it decays below the "release" threshold (timer expires), the cap is recharged (timer restarted).

Re: How to Debounce a Contact (2014)

#65

Post by AdamH12113 »

theamk wrote: post #49
geerlingguy wrote: post #4

This is one of the best treatises on debounce, I've read it a number of times and probably will again. One of the best things I've done to help with really bad debounce is spend time testing a number of buttons to find the designs that have, at the hardware/contact level, much less bounce. Some buttons wind up with tens of ms of bounce, and it's hard to correct for it and meet expectations all in software.

Just don't implement SR debouncer, OK? And don't use MC140* series chips, those don't work with 3.3V used by modern micros. And when he says: > Never run the cap directly to the input on a microprocessor, or to pretty much any I/O device. Few of these have any input hysteresis. that's not true today, most small MCU made in 2005 or later (such as AVR and STM8 series) have input hysteresis, so feel free to connect cap…

What's wrong with the SR latch debouncer?

Re: How to Debounce a Contact (2014)

#66

Post by stackskipton »

myself248 wrote: post #59
1970-01-01 wrote: post #46

Earlier quoted context omitted.

What's truly been lost is the speed 20 years ago was when I could flip through all (40ish) analogue CATV channels * in under 20 seconds * and could tell you what shows were going on with each channel. Yes, it only took around 500ms to filter and decide if each station broadcast was on commercial, news, sports, nature, or something else worth watching. To this day, with all the CDNs and YouTube evolutions, we still ha…

Seriously. Analog stuff was wild. You could have telephones in adjacent rooms, call one from the other, and your voice would come out the telephone (having traveled electrically all the way across town and back) before the sound came down the hall. Analog cellphones were like that too -- ludicrously low latency. Being able to interrupt each other without the delay-dance of "no, you go ahead" *pause* was huge. Digital…

>Digital cellular networks just enshittified that one day in about 2002 and apparently most folks just didn't care?

People cared, your comment made me remember comments my parents made about this problem. However, digital cell signals fixed a ton of congestion issues that analog was having and lowered the price so much people could actually afford to have cell phones.

Re: How to Debounce a Contact (2014)

#67

Post by kderbe »

1970-01-01 wrote: post #46
HPsquared wrote: post #37

Earlier quoted context omitted.

It used to be fun and rewarding to flip through channels on analogue equipment. No buffering, no delay, just press, flash to the next channel.

What's truly been lost is the speed 20 years ago was when I could flip through all (40ish) analogue CATV channels * in under 20 seconds * and could tell you what shows were going on with each channel. Yes, it only took around 500ms to filter and decide if each station broadcast was on commercial, news, sports, nature, or something else worth watching. To this day, with all the CDNs and YouTube evolutions, we still ha…

Puffer channel changes are near-instant. https://puffer.stanford.edu/

Re: How to Debounce a Contact (2014)

#68

Post by marcosdumay »

HPsquared wrote: post #37
khafra wrote: post #6

> One vendor told me reliability simply isn't important as users will subconsciously hit the button again and again till the channel changes. Orthogonally to the point of this excellent article, I found it striking how this was probably true, once--and then TVs got smart enough that it took seconds to change channels, instead of milliseconds. And then it was no longer possible for input failures to be corrected subco…

It used to be fun and rewarding to flip through channels on analogue equipment. No buffering, no delay, just press, flash to the next channel.

Well, that one was lost for a really reasonable increase in video quality, reception reliability, and number of channels.

Re: How to Debounce a Contact (2014)

#69

Post by GuB-42 »

khafra wrote: post #6

> One vendor told me reliability simply isn't important as users will subconsciously hit the button again and again till the channel changes. Orthogonally to the point of this excellent article, I found it striking how this was probably true, once--and then TVs got smart enough that it took seconds to change channels, instead of milliseconds. And then it was no longer possible for input failures to be corrected subco…

I have thought about that for a while and I wonder if it has to do with how memory becomes bigger more than it becomes faster. For example, compared to 30 years ago, PCs have about 1000x times more RAM, but it is only about 100x faster with about 10x less latency. It is a general trend for all sorts of devices and types of storage.

It means that for instance, storing an entire frame of video is nothing today, but in the analog times, it was hard, it means you simply didn't have enough storage for high latency. Now, you can comfortably save several frames of video, which is nice since more data means better compression, better error correction, etc... at the cost of more latency. Had memory be expensive and speed plentiful, a more direct pathway would have been cheaper, and latency naturally lower.

Re: How to Debounce a Contact (2014)

#70

Post by theamk »

Certified wrote: post #58
theamk wrote: post #50

Earlier quoted context omitted.

that seems like a real overkill - it's a full-blown RS232 receiver _and_ transmitter, including two DC-DC converters (with inductor and capacitor) that you don't even use... Also, "R_IN absolute max voltage" is +/- 25V, so I really would not use this in 24V system. If you want slow and reliable input for industrial automation, it seems much safer to make one yourself - an input resistor, hefty diode/zener, voltage di…

Thanks for pointing that out. I realized I called out the wrong chip. I was actually trying to call out the Max6818.

That's a neat chip, especial max6816/max6817 version in SOT23 package!

but yeah, very expensive for what it does. If my MCU was really short on interrupts, I'd go with I2C bus expander with 5v-tolerant inputs and INT output - sure, it needs explicit protection for 24V operation, but it also only needs 3 pins and 1 interrupt.

Post reply on HN