Key debounce

[Voodle]

The remote control has bad key bounce. This is easy to fix in software. Please Beyonwiz can you address this in the next firmware.

[IanSav]

Hi Voodle,

The remote control has bad key bounce. This is easy to fix in software. Please Beyonwiz can you address this in the next firmware.

This is not a commonly reported problem. I suggest that you check that there isn't a problem with your specific remote control. If the Beyonwiz is a recent purchase then try out your remote control at the store or perhaps borrow a store remote to test on your unit. This is certainly not an issue that need be addressed with firmware changes.

Regards,
Ian.

[adoxa]

My T2 remote is suffering from this - most keys often generate a second press. I was going to ask where best to address it in code, but maybe it's just a bad remote?

[MrQuade]

Have you tried fresh batteries? Old ones will often result in strange denounce like behaviour.

It could be dirty battery contacts or a bad remote too. See these links:
viewtopic.php?f=50&t=10464
http://beyonwiz.com.au/forum/viewtopic.php?f=42&t=9972

[adoxa]

A couple of weeks ago, the remote had stopped working - press a key and both the TV & STB buttons light up, without any action taken - so I swapped the batteries with the TV remote, which got it working again. Tried new batteries and that seemed better; put the old batteries back in and that doubled a couple of times, then settled down. Weird.

[IanSav]

Hi Adoxa,

I avoid using the T2/T4 remote as much as possible. I also note the key bounce issue when using the T2 and T4 remote controls. Very fresh batteries help but I am not made of batteries or money to keep buying them. I mostly use a T3 remote control which doesn't appear to suffer with this issue.

If you conclude that this is a case of key bounce then I would be interested to see if a driver patch could improve the reliability of the T2 and T4 remote controls.

Regards,
Ian.

[stevebow]

Have you tried fresh batteries? Old ones will often result in strange denounce like behaviour.

This was my experience too with the original T4 remote. It appeared to be a case of key bounce, even when the batteries had life in them, but a fresh set of batteries fixed this. It could be the remote's microcontroller playing up as the batteries run down, who knows. In any case, I have been using a Logitech Harmony for over a year now and it is an order of magnitude better than the original, none of the issues the original has.

[adoxa]

Yeah, the old batteries quickly bounced again, but the new batteries are so far okay. When it starts happening again, I'll see about a software solution.

[prl]

... In any case, I have been using a Logitech Harmony for over a year now and it is an order of magnitude better than the original [T4 remote]

Starting with the Logitechs not having the look and feel of a shoe box...

But also, the next-to-useless key backlighting chews through the batteries. I mean, backlighting that only comes on after you've pressed a button!

[adoxa]

EXIT bounced before 24 hours was up on the new batteries, so here's a patch, with a binary attached for the T2. After a little usage, I'm still getting some bouncing, so it might be better to increase the time and catch more bounces, at the expense of missing some legitimate presses.

[peteru]

That debounce patch does not appear to take in to account how the NEC IR protocol works or how the device drivers implement the translation of the NEC IR protocol into Linux events.

To get you on the right track:

NEC IR protocol only sends key down events or repeat flag events. The key down events can not arrive any faster than about once every 70ms. The repeat events should arrive about once every 110ms. The key up events are synthesised by the driver. When a new key down event arrives for a different key code, a key up event for the old key code is sent first. Otherwise, the driver uses an inactivity timeout to synthesise a key up event. This timeout is about 145ms for initial key press and about 455ms for repeats.

The remote control itself already debounces the keys with 70ms granularity, just because of the protocol limitations. i.e. You can not transmit a valid code any faster than about once every 70ms. The driver also provides some debounce protection and will ignore the same key down signal for 380ms. Any time after that, it should turn the repeat flag on for the bouncy key.

Looking at the patch (and ignoring the discrepancy between the code logic there and in the driver) a debounce delay of 170ms should not have any effect. It's possible that any results you may be seeing are due to scheduling latency, which may blow out the delay in the Python code execution past the 380ms driver debounce interval. Or there could be a bug somewhere (driver, kernel, enigma) - that's always a possibility. The commit log is not very informative about the exact nature of the problem, so it's hard to determine if the fix is appropriate.

Quite a bit of time was spent a few years ago on changing the driver to ensure rapid remote response. I think we managed to shave off about 1/2 second for quick jabs at the remote. I know quite a few users (including myself) would be rather annoyed if their box would stop responding to rapid remote key bashing. It's quite normal to have two or three presses of the same key in quick succession.

I think the best way forward would be to create an issue in the bug tracker for this problem and provide some data on what you are seeing. Include timing on events. Once the symptoms are understood, I can look in the driver and see if I can piece the puzzle together. I've got a number of T2 and T4 remotes here and while I don't like them very much, I've never seen key bounce problems with them. The worst I've seen is the backlight not turning off, but that has not affected their operation. The development T4 remote in particular gets a fair workout - it's been running on the same Eneloops for a few months now.

[IanB]

The bounce key problem with flat batteries is caused by the remotes processor shutting down as the battery voltage dips to low on load as an Ir command drives the output Led. With the processor shut down, the battery voltage recovers, the processor restarts, sees a key press, sends another Ir command to the output Led causing the battery voltage to again dip to low, rinse, repeat. As the battery gets flatter the repeat rate decreases as the battery voltage recovery time increases.

[adoxa]

I added this before the bounce test, defining that out:

struct timeval elapsed;
if (!timerisset(&prev_ev.time)) prev_ev.time = ev.time;
timersub(&ev.time, &prev_ev.time, &elapsed);
static const char* events[] = { "break", "make", "repeat", "???" };
eDebug("[eRCInputEventDriver] event +%ld.%06ld %u %s",
elapsed.tv_sec, elapsed.tv_usec, ev.code, ev.value >= 3 ? events[3] : events[ev.value]);

I tested with the Single-EPG, first some steady DOWNs (just showing after the '+', with additional blanks between presses):

0.680339 108 make
0.195677 108 break

0.657793 108 make
0.457191 108 break

0.434276 108 make
0.195727 108 break

That's fairly typical - most around 196ms, with a few at 457. Then I go UP, which occasionally exhibits the bounce:

0.760880 103 make
0.458063 103 break

0.535432 103 make
0.112415 103 break
0.000032 103 make
0.457122 103 break

4.999659 103 make
0.087828 103 break
0.000025 103 make
0.457479 103 break

6.033211 103 make
0.457788 103 break

Fast DOWN, for comparison:

2.849156 108 make
0.195850 108 break

0.064347 108 make
0.195651 108 break

0.054014 108 make
0.195985 108 break

With my previous timing tests, the quickest legitimate break was about 168ms, iirc, whilst the slowest bounced break was about 176. EXIT is highly prone to bouncing, so testing that in Live TV, using the double-flash on the remote to notice when bounce occurs:

0.801615 174 make
0.195385 174 break
0.036748 174 make
0.457251 174 break

4.243496 174 make
0.166750 174 break
0.000023 174 make
0.457734 174 break

So there's one that exceeds my test; there was even one at 202ms. I was going to increase my test to 180ms, but now it doesn't look like it will help.

Is the driver source available? Would I be able to have the T2 recognise a different remote?

How long are the batteries supposed to last? The supplied ones only lasted about two months; other remotes have lasted years.

[MrQuade]

Has anyone given a battery voltage booster a try with the T4 remote yet?

If the problem is related to a sagging voltage, and not necessarily due to how much energy is left in the battery, then perhaps something like the Batteroo is worth a shot.

I hadn't actually realised that the Batteroos had finally finished their Indigogo pre-orders and were now selling to the public. I know that most of the life-extending claims made by these guys are sketchy, but the products do actually work to reliably boost battery voltage by all the accounts that I have read.

Seeing as Alkaline batteries start at the nominal 1.5 V and quickly fall off, then fade away to 0.8V over the course of their life, and NiMH batteries like the Eneloops normally operate at a stable but reduced voltage until exhausted, I figure there may be some merit in ensuring that the T4 remote gets a good solid 1.5V over the course of the battery's life instead.

At $10 for a pack of 4 of these things, and being re-usable, it makes them a relatively cheap option to try out. Certainly cheaper than resorting to something like Lithium batteries to try to maintain a stable 1.5 V anyway!

I am not saying that low-drain NiMH batteries like the Eneloops are a bad option at all, just that some people seem to be having mixed results, and the fact that brand new batteries seem to work temporarily, then a voltage booster seems like a valid option to try.

I'd try myself, but I don't use the T4 remote as a daily-driver, and have had no bad experiences with it as of yet.

[peteru]

For me the T4 remote works just fine for months at a time when I use Eneloops. I have not measured the in-circuit voltage when the remote starts going flaky, but if I remember I'll do that next time.

Save your money and instead of buying Bateroos, buy a new pack of batteries.

I think it's about time I introduced Dave:

[MrQuade]

Yes, I follow his channel, and I did mention that the battery life extension claims of the Batteroo were sketchy in my post. It was actually one of his videos from earlier this year that reminded me about the Batteroo, as I had not realised they'd actually gotten it out to the general public.

However, even Dave says that the voltage boosting feature of the product works as advertised, and that was the relevant property that I was talking about. It's definitely not a product for all applications, but I do believe that it does have some niche uses.

You may end up running your batteries down faster using this product, but I suspect that you'd have consistent performance throughout the life of the batteries.

[prl]

There's a summary of Dave's claims about the Batteroo in its Wikipedia entry, along with information about other testing. The reaction seems mixed.

[MrQuade]

The thrust of it is as follows.

Batteroo claim that they unlock extra capacity from the battery when it inevitably drops below a viable voltage level. This is the sketchy part of their claim.

In a low-drain application, alkaline batteries start at about 1.5 V, quickly fall off to 1.4 V, then more or less linearly fade off to around 1.1V over its useful life before beginning to drop off faster again.

Many devices will already continue to work to some degree right up until the battery is completely pooped. Take a simple incandescent torch for example. As the batteries get old, the globe will dim gradually until it is completely useless. An AA is supposed to have a viable amount of energy right up until it hits about 0.8V.

Other devices won't work below a certain voltage and will just cut out after a certain point.

The problem with Batteroo, is that because it holds the output voltage of the battery/Batteroo circuit at 1.5V the whole time, it is pulling energy out of the battery faster, so it actually drains the battery quicker. In the tests that you see in Youtube, they demonstrate that the battery runs out sooner, but the device generally performs at a higher power for the lifetime for the battery.

Take the toy train example from Dave. The Batteroo boosted train runs 10% faster and at a constant speed for the whole run time of the battery. The non-boosted version of the test shows the train run 10% slower initially, and it does slow down further a bit as the battery runs down, however, it runs for a good 40% longer duration and travels significantly further than in the Batteroo boosted test.

The Batteroo is also spectacularly bad for devices like smoke detectors that rely on the gradual voltage reduction to detect when the battery is about to run out and thus "chirp" out its alarm before the battery dies. This is also part of the reason why you don't want to use rechargeables in a smoke detector, aside from the additional problem of self-discharge that you get from typical rechargeables.

This is why the Batteroo is not suited to every application. IT depends if you want the battrery powered device to work "better" for a shorter period, or it is actually beneficial to operate at lower performance for a longer time (I am sure that most people would want the toy train to run for longer and further as opposed to have it run 10% quicker).

In the case of the T4 remote , I am suggesting that having a consistent voltage supplied to the remote may help the wiggy behaviour that people are seeing as the batteries wear down. I am actually fairly keen to see PeterU's results to know at what point the battery voltage starts becoming a problem. I am guessing that it would be around the 1.15V mark. That would be below the normal operating level of a NiMH cell (which more or less stays at 1.2V then basically brick walls to completely dead at 1.1V), and about 2/3rds of the way into the lifetime of an alkaline, which is a fair way off being completely dead.

I don't think that testing with a calibrated bench supply would be valid either, as there would be a certain amount of momentary voltage sag present when the T4 remote loads the battery with both the backlight and the IR emitter.

I think this may be one of the corner cases where a voltage booster is useful.

[IanB]

As I previously posted the problem with the T4 remote and flat batteries is the processor resetting as the voltage dips to low as the output led attempts to deliver it's pulses of light and draws full load current.

The fundamental design flaw is the lack of sufficient processor power supply capacitance (zero) to maintain it's operations during the transient full load current. Ideally the processor should continue functioning as the available output led brightness diminishes to zero.

A Batteroo is not going to help. It will probably make it worse as it tries to increase the current draw to maintain the higher output voltage from a flat battery that already cannot deliver enough current to maintain operation.

Theory :-

A chemical battery can be expressed as a circuit with a voltage source in series with a resistor. When new the voltage source will be over 1.5 volts and the series resistance less than 1 ohm. As the battery is used the voltage source reduces to about 1.3 volts. The series resistance increase dramatically at the end of life, eventually to over 100's of ohms.

E.g. A device needs a minimum of 1.0 volts to operate and needs to draw 10 milliamps to do it's thing. At what equivalent series resistance will a battery no longer be able to provide sufficient power to run the device.

Assume the internal voltage source is now at 1.3 volts, thus we can only lose 0.3 volts across the series resistance when 10 milliamps is flowing. Solving using ohms law, R=V/I, we get 0.3V/0.01A=30 ohms.

Thus for this example device when the battery chemicals are sufficiently consumed such that the equivalent internal resistance is more than 30 ohms that device stops. For another device that only needs to draw 1 milliamp, the equivalent internal resistance can rise to 300 ohms. The equivalent internal resistance is in no way linear with remaining battery capacity typically only rising rapidly as more than 90% of the chemicals are consumed. Thus heavy demand devices may stop at 92%,while low demand devices may limp along until 95%.


Bottom line, don't be a cheapskate, use new batteries when the remote first starts to exhibit flat battery behaviour.

[MrQuade]

Bottom line, don't be a cheapskate, use new batteries when the remote first starts to exhibit flat battery behaviour.

Or buy a better remote

[peteru]

The T4 remote I use every day has now had the same batteries installed for about 3 months. It gets a fair amount of use most days - enough for the key tops to show signs of wear.

Installed is a pair of matched Eneloops, with measured discharge capacities of 812mAh and 814mAh. The current in-circuit voltage under load is 2.56V (or about 1.28V per cell) and it still operates reliably.

Then again, I've had the same alkaline batteries in the T3 remote for several years and it's still going.

[sonicblue]

Was having this issue on the T2 and found with a harmony 650 an inter-key delay setting of 200ms did the trick. My "number of repeats" setting is currently 0 as well.

[MrQuade]

Was having this issue on the T2 and found with a harmony 650 an inter-key delay setting of 200ms did the trick. My "number of repeats" setting is currently 0 as well.

I'm not sure how the 650 reacts, but on my Ultimate and Elite Harmony, a repeat setting of 0 adds a significant lag to the button presses. If you set repeats to 1, the keys respond a lot faster.