MCE RC6 IR receivers shortcomings (1 Viewer)

CyberSimian

Test Group
  • Team MediaPortal
  • June 10, 2013
    2,851
    1,772
    Southampton
    Home Country
    United Kingdom United Kingdom
    Obviously there are loads of MCE receivers out there, so there's no need to develop another one, I think. Does it have shortcomings? Maybe something could be improved.
    There are two shortcomings common to existing MCE RC6 IR receivers:

    (1) On wake from sleep or wake from hibernation, a USB-connected MCE RC6 IR receiver sometimes malfunctions, and Windows displays a message to the effect that "a USB device has stopped working". The malfunction evidently occurs at some point during the wake-up process, as the receiver is able to initiate the wake-up process without problem.

    This problem seems to affect quite a few users, but not necessarily all users (so it may be dependent on the exact sequence of wake-up processing resulting from the specific hardware and software present in the HTPC). Certainly, I experienced this problem during the five years that I used WMC, and I have continued to experience it now that I use MP. In my case, it occurs on average perhaps once per week, but it is erratic. The solution that I use is simply to unplug the IR receiver, wait 10 seconds, and then replug it.

    (2) The MCE RC6 signalling protocol uses "toggle codes", whereby there is an extra bit flag that toggles between 0 and 1 on successive button-presses (this may not be an exact description, but it is something like this). So two consecutive presses of the same button actually give two different button codes. This technique helps to eliminate the effects of contact bounce occurring in the remote control. The problem is that the Microsoft driver implements debounce processing incorrectly, with the result that some button-presses are ignored in certain sequences of button-presses. This is described in excruciating detail in this post:

    http://www.thegreenbutton.tv/forums/viewtopic.php?p=55303#p55303

    There is a registry setting that can disable Windows debounce processing. That eliminates the problem that causes some button-presses to be ignored, but introduces the problem of some single button-presses being interpreted as two or three button-presses (caused by contact bounce in the remote).

    Recently I have been using the Ortek/Hama remote control (with its own dedicated IR receiver). This remote is not an RC6 remote, and does not suffer from either of the shortcomings described above, so I am probably going to use it long term (albeit with the Ortek/Hama definitions programmed into a universal remote control). I also have a Logitech 650, and that does implement toggle codes correctly, so does not suffer from shortcoming (2). However, it still requires a conventional MCE RC6 IR receiver, and so does suffer from shortcoming (1).

    -- from CyberSimian in the UK
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    The problem is that the Microsoft driver implements debounce processing incorrectly...
    Which driver are you referring to?
    If you look at IRSS's MCE-compatible transceiver support implementation, you'll see it receives space and pulse durations. It has to interpret those from first principles in order to figure out what they represent, including interpretation of commands, toggle bits and repeat handling. I would have assumed that WMC would have equivalent code. Therefore if there is indeed a problem with incorrect processing, I would have assumed the fault lay within WMC and is not inherent to the MCE transceiver or any of its drivers.
     

    CyberSimian

    Test Group
  • Team MediaPortal
  • June 10, 2013
    2,851
    1,772
    Southampton
    Home Country
    United Kingdom United Kingdom
    Which driver are you referring to?
    The one that Windows installs by default: the driver for the "Microsoft eHome Infrared Transceiver". I don't have access to the source code (of course!), so the presence of incorrect debounce processing in the driver is only a surmise on my part.

    If you look at IRSS's MCE-compatible transceiver support implementation
    I have not used IRSS, so I don't know what it does. If it has a replacement for the "Microsoft eHome Infrared Transceiver" driver, perhaps it implements debounce correctly? However, both WMC and MP (when using the default driver for the "Microsoft eHome Infrared Transceiver") exhibit the problem with incorrect debounce. That suggests that the problem is in the driver, and not in code specific to WMC.

    -- from CyberSimian in the UK
     

    Stéphane Lenclud

    Retired Team Member
  • Premium Supporter
  • April 29, 2013
    2,576
    1,294
    Home Country
    Germany Germany
    (2) The MCE RC6 signalling protocol uses "toggle codes", whereby there is an extra bit flag that toggles between 0 and 1 on successive button-presses (this may not be an exact description, but it is something like this). So two consecutive presses of the same button actually give two different button codes. This technique helps to eliminate the effects of contact bounce occurring in the remote control. The problem is that the Microsoft driver implements debounce processing incorrectly, with the result that some button-presses are ignored in certain sequences of button-presses. This is described in excruciating detail in this post:

    http://www.thegreenbutton.tv/forums/viewtopic.php?p=55303#p55303

    I came across that problem myself. It could be a weakness from the driver but it's only an issue when using some universal remotes, hardware or apps.
    To me it seems some universal remotes are sending incomplete signals leaving the driver in the wrong state resulting in the next signal being ignored.
    I did get such incomplete signals from various android apps remotes and from button I taught to a Philips Prestigo remote.
    Teaching again the button to your remote can fix the problem, you need to make sure you press the button on your original remote for the "right" duration while recording it.

    Interestingly my Harmony 950, and I assume most Harmony remote can sanitize such incomplete signals. So if you teach such a broken signal to your Harmony it won't suffer the same side effect when using it and I see you've noticed that too:
    I also have a Logitech 650, and that does implement toggle codes correctly, so does not suffer from shortcoming (2)
    .
     

    CyberSimian

    Test Group
  • Team MediaPortal
  • June 10, 2013
    2,851
    1,772
    Southampton
    Home Country
    United Kingdom United Kingdom
    To me it seems some universal remotes are sending incomplete signals leaving the driver in the wrong state resulting in the next signal being ignored.
    I believe that there are two problems here:

    (1) Most universal remote controls do not emulate separate remotes correctly (I say "most" because so far I have found only one brand that works correctly, namely Logitech Harmony). When a universal remote is setup to operate two or more devices that use toggle codes, the remote needs the maintain a separate toggle flag for each device. The Logitechs presumably do this (because they work correctly). Other universal remotes (such as those made by One-for-All or Universal Remote) maintain a single toggle flag that is then used for all devices. As a result, those universal remotes sometimes send signals with the wrong setting for the toggle flag.

    This is easily demonstrated when the VOLUME UP/DOWN and MUTE buttons are setup to control an audio amplifier that uses toggle codes, while the remaining buttons are setup to control WMC or MP. Using the universal remote causes the problem to occur, whereas using the separate remotes avoids the problem occurring (so the universal remote is not correctly emulating the separate remotes).

    (2) The Microsoft driver does not implement debounce processing correctly. In the post that I referenced above I included some pseudo code for what I think the Microsoft driver has implemented, and what I think it should have implemented (there is one line that is different!).

    Note that the problem of button-presses being ignored occurs only when both factors are present in a user's system. If only one factor is present, no problem is apparent. I suspect that this is why most users do not encounter this problem.

    -- from CyberSimian in the UK
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    I can certainly understand with your description of the first problem regarding toggle bits, multiple devices and universal remotes.

    At the risk of going off-topic, I still can't wrap my head around the second problem. I think you may be saying that toggle bits should be treated as global to all "devices". In other words, for a given protocol that includes a toggle bit (RC-5, RC-6 etc.), each button press should flip the toggle bit regardless of the system address (target device). For that to work out, all devices would have to receive all commands (in order to track the toggle bit). Your algorithm implies as much when you say:
    if new_button is not for Media Center /* for some other device? */

    With the greatest respect, I don't agree with the idea/assumption that all devices will receive all commands generated by the remote. That might happen coincidentally in some situations. For example, when equipment is co-located. However when one device is across the room from another, it's not practically feasible. A given device should be able to operate correctly when it receives all the commands that are intended for it. If it happens to receive some or all commands that are intended for other devices, that's pure coincidence. Those commands shouldn't affect processing in any way. They should simply be discarded and ignored.

    In other words, my thinking is:
    1. As you said, a universal remote should maintain a separate toggle bit for each protocol it supports.
    2. If a remote supports a protocol that specifies a toggle bit as well as device targeting (eg. RC-5, RC-6), the remote should maintain a separate toggle bit for each device or device class. This would apply to any remote which is capable of controlling multiple devices.
     

    CyberSimian

    Test Group
  • Team MediaPortal
  • June 10, 2013
    2,851
    1,772
    Southampton
    Home Country
    United Kingdom United Kingdom
    A given device should be able to operate correctly when it receives all the commands that are intended for it. If it happens to receive some or all commands that are intended for other devices, that's pure coincidence. Those commands shouldn't affect processing in any way.
    Yes, that is exactly right. But that is not what the Microsoft driver is doing. Commands intended for other RC6 devices (such as my Sony amplifier) do affect WMC and MP (because the debounce processing performed by the Microsoft driver is incorrect). It is a subtle error, so perhaps it is not surprising that the authors of the Microsoft driver got it wrong.

    The test case that I described in my GreenButton post reproduces the error every time (assuming that you have appropriate hardware). If you use that test case, and work through the two pseudo code samples that I gave, the subtle error should become apparent. (The test case and pseudo code provide a more precise demonstration of the error than trying to describe the error in words.)

    -- from CyberSimian in the UK
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    @CyberSimian
    Perhaps we should open a new thread for these posts...

    Yes, that is exactly right. But that is not what the Microsoft driver is doing. Commands intended for other RC6 devices (such as my Sony amplifier) do affect WMC and MP (because the debounce processing performed by the Microsoft driver is incorrect). It is a subtle error, so perhaps it is not surprising that the authors of the Microsoft driver got it wrong.
    Theoretically the problem could be in one of two places:
    1. The receiver's command processing.
    2. The remote control's command generation (specifically: toggle bit handling).
    How is it that you're so sure that the receiver is at fault?
    Personally I can't think of any way to categorically prove that the problem source is one or other without checking what commands the remote is producing [at the protocol/bit level].

    The test case that I described in my GreenButton post reproduces the error every time (assuming that you have appropriate hardware). If you use that test case and work through the two pseudo code samples that I gave, the subtle error should become apparent.
    Unfortunately for me I don't have the appropriate hardware so I can't test.

    It's a very clever piece of logic... :notworthy:
    ...but it makes at least two implicit assumptions that ought to be clearly stated and/or explained:
    1. Which commands does each receiver receive?
    2. How is the remote manipulating the toggle bits?
    Certain combinations of these two variables can lead to contradictory conclusions about the source of the problem. ;)

    If you still have the ability to reproduce this problem, I'd be interested to see IRSS debug-level log files corresponding with the test case. This would enable us to confirm or reject the hypothesis you outlined in your GB post.

    P.S. I assume you're aware that RC-6 has a standard toggle bit which [apparently] is fixed-value for Microsoft RC-6 commands, and that Microsoft RC-6 commands have a separate non-standard toggle bit. This adds to the complication and expands the set of possible explanations for the problem.
     

    CyberSimian

    Test Group
  • Team MediaPortal
  • June 10, 2013
    2,851
    1,772
    Southampton
    Home Country
    United Kingdom United Kingdom
    Perhaps we should open a new thread for these posts...
    Agreed. (Apologies to the thread starter for this diversion.) Could someone who has the necessary authorisation please move all of the relevent posts to a new thread? Thank you.

    How is it that you're so sure that the receiver is at fault?
    I first looked at this problem back in 2011 (when I was using WMC), so I am trying to remember the reasons why I came to the conclusions that I did. The crux of the test case is this sequence of button presses:

    (1) Press GUIDE button (sends signal for WMC/MP).
    (2) Press VOLUME_UP button (sends signal for Sony amplifier).
    (3) Press GUIDE button (sends signal for WMC/MP).

    This is what happens:

    (A) If the individual device-specific remote controls are used, this sequence works correctly.
    (B) If a Harmony universal remote control is used, this sequence works correctly.
    (C) If a One-for-All (or other) universal remote control is used, this sequence does not work correctly; action (3) is ignored.

    Comparing (A) with (C) indicates that the One-for-All universal remote control is not correctly emulating the individual device-specific remote controls. This ultimately lead to my conclusions about the toggle flag.

    However, one can invert the test case, and perform this sequence of button presses:

    (1) Press VOLUME_UP button (sends signal for Sony amplifier).
    (2) Press GUIDE button (sends signal for WMC/MP).
    (3) Press VOLUME_UP button (sends signal for Sony amplifier).

    If the error resides solely in the remote control, action (3) would again be ignored. But it is not. With my Sony amplifier, action (3) is executed normally. This result lead me to conclude that there is an error in the Microsoft driver (because the corresponding microcode in the Sony amplifier does not exhibit the same problem).

    The final piece of the puzzle was the effect of changing the Windows registry setting to disable debounce processing. With debounce disabled, action (3) in the original test sequence was now executed correctly when using the One-for-All universal remote control. However, the side effect was the introduction of spurious actions due to contact bounce in the remote. Example: pressing and releasing the DOWN button when in the EPG would cause the focus to move down two or three lines; with debounce enabled, the focus moves down one line only.

    If you still have the ability to reproduce this problem, I'd be interested to see IRSS debug-level log files corresponding with the test case. This would enable us to confirm or reject the hypothesis you outlined in your GB post.
    Yes, I still have all of the relevant hardware, and can reproduce the error on demand. However, I have not so far ventured into the world of IRSS, so it might take me a while to figure out how to set things up. :unsure:

    Finally, let me re-iterate that I have not seen any source code for the Microsoft driver, or looked at data traces for the IR signalling, so my conclusions are based on the tests that I have performed, and the outcomes resulting. My hypothesis is (so far) consistent with the test results :cool:, but that does not mean that my hypothesis is correct. :D

    -- from CyberSimian in the UK
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    This is what happens...
    So the implication of this is either:
    1. Harmony remote and receiver processing is correct; One-for-All and other universal remotes are not manipulating the toggle bit(s) correctly. OR...
    2. One-for-All and other universal remote processing is correct; receiver processing is wrong... but so is the Harmony remote, because a correctly implemented remote control should give the same [erroneous] result.
    The first option seems more likely to me.

    However, one can invert the test case, and perform this sequence of button presses...
    If the error resides solely in the remote control, action (3) would again be ignored.
    Not necessarily. The result depends on how the amp receiver does its processing.

    The final piece of the puzzle was the effect of changing the Windows registry setting to disable debounce processing. With debounce disabled, action (3) in the original test sequence was now executed correctly when using the One-for-All universal remote control. However, the side effect was the introduction of spurious actions due to contact bounce in the remote.
    The clear implication from the change in behaviour is that disabling de-bounce processing means that the receiver will ignore the toggle bit state. With that change, commands that would otherwise have been ignored because the toggle bit hadn't changed would now be actioned. That's the source of the spurious actions, and the reason why step 3 produces an action.

    To me this is further evidence that the One-for-All remote is not tracking and manipulating the RC-6 and MS RC-6 toggle bits correctly. It's just so easy for the remote to get it wrong given MS's non-standard RC-6 toggle bit implementation.

    However, I have not so far ventured into the world of IRSS, so it might take me a while to figure out how to set things up. :unsure:
    IRSS is fairly easy.
    1. Install the latest version attached to the first post here:
    https://forum.team-mediaportal.com/...-unoficial-testing-version-no-support.119847/
    During installation, make sure you tick the option to install the MP Control plugin.
    2. Open MediaPortal Configuration.
    3. Go the "remotes & input devices" section and ensure all handlers are disabled.
    4. Go to the "plugins" section and enable the MP Control plugin.
    5. Close MediaPortal Configuration.
    6. Open IRSS Input Service configuration.
    7. Click "advanced" up the top.
    8. Ensure log verbosity is set to debug and click OK.
    9. Find "Microsoft MCE" in the "device plugins" list and ensure "receive" is ticked.
    10. Up the top, click "stop" then "start" to restart the service and apply the changes.

    Now you should be able to reproduce the problem.
    IRSS log files can be found in c:\ProgramData\IR Server Suite\Logs.
     

    Users who are viewing this thread

    Top Bottom