MCE RC6 IR receivers shortcomings (1 Viewer)

[CyberSimian]

IRSS is fairly easy...

Thank you for the instructions. I will work through them and try the test case. But it may be a few days before I can get around to this.

I don't want to modify my "production" system, but I have a spare partition on the same HTPC that I can use. My production system is MP 1.12. Is that OK to use (I will copy it to the test partition), or would you prefer that I use a more recent release of MP?

-- from CyberSimian in the UK

 

[mm1352000]

But it may be a few days before I can get around to this.

There's absolutely no rush - take your time.

I don't want to modify my "production" system, but I have a spare partition on the same HTPC that I can use. My production system is MP 1.12. Is that OK to use (I will copy it to the test partition), or would you prefer that I use a more recent release of MP?

You don't even really need MP. The only use of MP would be to confirm the effect of buttons. Really all I want to check out is the IRSS log for the button sequence. The log will show the low-level command detail.

 

[CyberSimian]

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.

Preliminaries
I have now performed the tests using IRSS. First some points:

(A) I used MP 1.12, as I wanted to see what effect the various button presses had on MP. The skin in use was the "DefaultWide" skin.

(B) I did several tests, but each test consisted of the following actions:

Starting from the Windows desktop:
(0) Press the START button on the remote control (MP starts and displays the "Home" panel).
(1) Press the GUIDE button (the EPG is displayed).
(2) Press the VOLUME_UP button (the Sony volume is increased).
(3) Press the GUIDE button (the EPG is removed from the screen and the "Home" panel is displayed).
(4) Press the START button (the "Home" panel or alternative "Home" is displayed).
(5) Press the UP, LEFT, LEFT, OK buttons (MP closes and exits to the desktop).

(C) I tested a One-for-All remote that had been setup to send the built-in MCE RC6 signals. I also tested a Logitech Harmony 650 that had been setup to send the pre-defined MCE RC6 signals. Both remotes used "punch through" to enable the VOLUME_UP, VOLUME_DOWN, and VOLUME_MUTE buttons to send the signals for my Sony audio amplifier.

(D) I first tested MP's "Microsoft MCE" tab with extended logging enabled. I then disabled that, enabled IRSS, and repeated the tests. The relevant log file from each test is included in the attached zip file.

Results
one_for_all_mce.log
This is the MP log showing that actions (1), (4), and (5) are received; actions (2) and (3) are missing. Only action (2) should be missing. So the One-for-All does not work correctly.

harmony_650_mce.log
This is the MP log showing that actions (1), (3), (4), and (5) are received; action (2) is missing (as it should be). So the Harmony works correctly.

one_for_all_irss.log
This is the IRSS log file showing signal timings etc.. By monitoring the MP panels, it was apparent that the remote control works correctly, i.e. the error that occurs when using the Microsoft driver does not occur when using IRSS. (I have used the term "Microsoft driver" as a shorthand for "a processing layer or function invocation that is used by both MP and WMC".)

harmony_650_irss.log
This is the IRSS log file showing signal timings etc.. By monitoring the MP panels, it was apparent that the remote control works correctly.

If you need any of the other MP or IRSS log files, let me know and I will upload them.

Other Observations
This was the first time that I have used IRSS, and I found the panel that gave me a choice of installing IRSS as a "service" or an "application" confusing. It did not explain why I might want one choice rather than the other, and seemed somewhat self-contradictory.

The mouse-over help for the "Application" button at the top of the screen displays "Stop", even when it means "Start".

-- from CyberSimian in the UK

 

[mm1352000]

Thanks CyberSimian

Decoding the signals will take awhile. I'll get back to you with what I find soon.

(D) I first tested MP's "Microsoft MCE" tab with extended logging enabled.

Could also be interesting to throw in the HID handler at some point and see if there's a difference.

I found the panel that gave me a choice of installing IRSS as a "service" or an "application" confusing. It did not explain why I might want one choice rather than the other, and seemed somewhat self-contradictory.

Disclaimer: I don't really do any work on IRSS, so I'm unlikely to be able to effect a change.
You mean in the installer itself?
"As a service" means that it always runs in the background, like TV Server. That way it can always be listening for commands even when it appears to not be running.
"As an application" means that it runs like a traditional program. You open it and close it by choice. When closed, commands are not received.

The mouse-over help for the "Application" button at the top of the screen displays "Stop", even when it means "Start".

@azzuro
Can you fix in your fork?

 

[mm1352000]

Hmmm, interesting. I had assumed that the commands for your amp/receiver would be RC-6 too. Actually they look like SIRC (not too much of a surprise for Sony equipment).

 

[azzuro]

Can you fix in your fork?

Done, after many minutes, for search where i must modify lol
but it seems work.
Done on Services & Application.

Corrected on version 1.5.0.116

 

[mm1352000]

Okay, here are the One-For-All IRSS decodes. I have to get ready for work so I'll have to do the Harmony decodes later. Nevertheless, I think you'll be able to see the problem immediately without the Harmony decodes.

I've included literally every received bit. By this I mean that you can see that the first START command is actually transmitted and received 3 times even though you only pressed the button once.

The RC-6 toggle bit is marked "T:", and the MS RC-6 toggle bit is marked "MS:".
Spaces are inserted based on the RC-6/SIRCS protocol bit structure, and for readability.

START
1 110 T:0 1000 0000 0000 1111 MS:1 000 0100 0000 1101
1 110 T:0 1000 0000 0000 1111 MS:1 000 0100 0000 1101
1 110 T:0 1000 0000 0000 1111 MS:1 000 0100 0000 1101

GUIDE
1 110 T:0 1000 0000 0000 1111 MS:0 000 0100 0010 0110
1 110 T:0 1000 0000 0000 1111 MS:0 000 0100 0010 0110

VOLUME UP
0100 1000 0001
0100 1000 0001
0100 1000 0001

GUIDE
1 110 T:0 1000 0000 0000 1111 MS:0 000 0100 0010 0110
1 110 T:0 1000 0000 0000 1111 MS:0 000 0100 0010 0110

START
1 110 T:0 1000 0000 0000 1111 MS:1 000 0100 0000 1101
1 110 T:0 1000 0000 0000 1111 MS:1 000 0100 0000 1101

In short, the second GUIDE command is not actioned because the One-For-All remote doesn't switch the toggle bit after the VOLUME UP command. In my humble opinion this means the remote is non-compliant. The "MS driver" obviously sees the SIRC VOLUME UP command but will treat it as garbage. As such, it will [rightly - in my opinion] expect the next real MS RC-6 command to have a flipped toggle bit...

 

[CyberSimian]

Could also be interesting to throw in the HID handler at some point and see if there's a difference.

I will try that tomorrow.

I had assumed that the commands for your amp/receiver would be RC-6 too.

I had assumed that the Sony IR signals were RC6 (or some other signalling protocol that uses a toggle flag) because of the effect that they have on WMC or MP when transmitted by the One-for-All remote. That seemed to fit in with my hypothesis about toggle codes and debounce processing.

In short, the second GUIDE command is not actioned because the One-For-All remote doesn't switch the toggle bit after the VOLUME UP command.

This is really strange. My working hypothesis was that the One-for-All flipped its internal toggle flag only if it was sending a signal for a toggling protocol. But if the Sony protocol is not a toggling protocol, this result suggests that the One-for-All is flipping its internal toggle flag even when the destination device does not use a toggling protocol.

I have just performed a quick test on my production system. It was the same test sequence as before except I inserted a second VOLUME_UP button-press following the first one. With this sequence, the second press of the GUIDE button now works correctly. This result is consistent with the One-for-All always flipping its internal toggle flag, regardless of the destination device.

It is interesting that IRSS does not suffer from this problem, and is able to interpret the signals correctly. Is this because IRSS does not perform debounce processing? The One-for-All works correctly with WMC with debounce disabled, but that results in spurious effects from contact bounce (so is not a usable solution). I will give IRSS more of a work-out tomorrow, to see if I notice any effects caused by contact bounce.

-- from CyberSimian in the UK

 

[mm1352000]

This is really strange. My working hypothesis was that the One-for-All flipped its internal toggle flag only if it was sending a signal for a toggling protocol. But if the Sony protocol is not a toggling protocol, this result suggests that the One-for-All is flipping its internal toggle flag even when the destination device does not use a toggling protocol.

Yeah, correct - what the OFA remote is doing doesn't make much sense to me.
As far as I know SIRC (the Sony protocol) does not have a toggle flag. This is the information I'm going by:
http://www.sbprojects.com/knowledge/ir/sirc.php
http://users.telenet.be/davshomepage/sony.htm

I guess a SIRC receiver detects a single continuous button press using this property:

The space between 2 transmitted codes when a button is being pressed is 40mS

In other words: if the space between commands is longer than 40 ms, it's the equivalent of flipping the toggle bit.

I have just performed a quick test...

LOL.

It is interesting that IRSS does not suffer from this problem, and is able to interpret the signals correctly. Is this because IRSS does not perform debounce processing?

It's because IRSS's debounce processing is across all protocols.

In code terms, this is it:

if (!firstPress && _lastRemoteButtonCodeType == codeType && _lastRemoteButtonKeyCode == keyCode)
{
  // process the button press
}

In layman's terms...
Debounce processing only applies for consecutive button presses that came in via a single protocol. In other words, IRSS doesn't ignore the second GUIDE button press (3) because it was preceded by a SIRC command [instead of an MS RC-6 command]. The SIRC command breaks/resets the debounce processor. If IRSS didn't receive or understand the SIRC command (ie. if your amp happened to be located on the opposite side of the room from the PC's MCE-compatible receiver, or IRSS didn't support SIRC), you'd experience exactly the same symptoms as you have with the "MS driver".

 

[mm1352000]

...and for completion, here's the Harmony decodes.

START
1 110 T:0 1000 0000 0000 1111 MS:0 000 0100 0000 1101
1 110 T:0 1000 0000 0000 1111 MS:0 000 0100 0000 1101
1 110 T:0 1000 0000 0000 1111 MS:0 000 0100 0000 1101

GUIDE
1 110 T:0 1000 0000 0000 1111 MS:1 000 0100 0010 0110
1 110 T:0 1000 0000 0000 1111 MS:1 000 0100 0010 0110
1 110 T:0 1000 0000 0000 1111 MS:1 000 0100 0010 0110

VOLUME UP
0100 1000 0001
0100 1000 0001
0100 1000 0001

(...some random pulses/spaces...)
+200, -300, +100, -101600

GUIDE
1 110 T:0 1000 0000 0000 1111 MS:0 000 0100 0010 0110
1 110 T:0 1000 0000 0000 1111 MS:0 000 0100 0010 0110
1 110 T:0 1000 0000 0000 1111 MS:0 000 0100 0010 0110

START
1 110 T:0 1000 0000 0000 1111 MS:1 000 0100 0000 1101
1 110 T:0 1000 0000 0000 1111 MS:1 000 0100 0000 1101

(...some random pulses/spaces...)
+150, -650, +550, -47550

1 110 T:0 1000 0000 0000 1111 MS:1 000 0100 0000 1101

(...some random pulses/spaces...)
+100, -1400, +250, -101600


Aside from the random pulses/spaces, the commands are exactly as expected. The Harmony remote works with "the MS driver" because it flips the MS toggle bit between the 2 GUIDE commands.