Is there any use for a multi protocol IR receiver/ transmitter? (2 Viewers)

[mm1352000]

I guess I should also mention the USB-UIRT.
http://www.usbuirt.com/

Those two - MCE-compatible and USB-UIRT - seem to be the most commonly mentioned transceivers on our forum.

 

[myscha]

For receiving, each button-press is passed to software as a generic series of times (durations of pulses and spaces), plus the carrier frequency. From this, the software must decide which button was pressed. In other words, the end-user software is responsible for protocol support..

The lib I use takes a quite different approach as it's intended to be used on small embedded systems with only one microcontroller. All the IR en-/decoding is done on the microcontroller and only 6 Bytes of data must be exchanged. My host application maps those bytes to a keyboard key or to key sequences. The host application developer doesn't need to have any idea about the underlying IR protocols. But to support new protocols the firmware of the device must be updated.

The specifications answer this in the "Wake From Remote" section. In short: yes for S1 and S3. S4 and S5 are optional.

Do you know any receiver that allows waking up from S4 or S5?

Does it include a timer that wakes the PC at a given time from any state?

I'm not sure if I understand you correctly. What I can say is that the end-user must press a specific button on the remote which generates a specific code/command which the receiver recognises. Again, the "Wake From Remote" section explains the details.

The idea behind that comes from my former mainboards as most of them weren't able to wake on the integrated RTC. So I implemented an RTC in the device and now I don't have to rely on the mainboard any more.

 

[mm1352000]

But to support new protocols the firmware of the device must be updated.

Yes, this makes sense. As you say, it's the opposite approach. Depending on the application, some people may consider this to be a strength while other people may consider it to be a weakness.

All the IR en-/decoding is done on the microcontroller and only 6 Bytes of data must be exchanged. My application maps those bytes to a keyboard key or to key sequences. The application developer doesn't need to have any idea about the underlying IR protocols.

So for transmitting, how does the application developer specify the protocol to use?

Do you know any receiver that allows waking up from S4 or S5?

I'm not particularly familiar with the various implementations, so I have to say no... but I assume there may be some.

 

[azzuro]

maybe, you can provide an plugin for IRSS, for support your board. at least for the IR receiving/transmiting, also already compatible with MP1 & MP2

https://forum.team-mediaportal.com/...-unoficial-testing-version-no-support.119847/
the last source repo is here : https://github.com/Azzuro/IR-Server-Suite ( i hope to have it on the official repo soon )

 

[HTPCSourcer]

Do you know any receiver that allows waking up from S4 or S5?

All solutions that I am aware of are plugging into the power switch line.

 

[Stéphane Lenclud]

Can the the MCE device wake the PC from all power states?

• Most MCE devices simply plug in a USB port, they could be able to wake up from S5 when paired with a motherboard which supports USB standby power and wake-on-USB. (I never tested that)
• Some MCE devices are using CIR ports instead of USB, for those you will need such a port on your motherboard obviously and I believe you can wake up from S5 then. (I never tested that)
• Very few MCE devices can wake up your PC from S5 no matter what motherboard you are using. Those devices intercept your motherboard power switch and obviously need access to standby power one way or another. (Been using three different such devices: SoundGraph iMon, Simerec PCS-MCE, Inteset PC-IRS5-01 )

Does it include a timer that wakes the PC at a given time from any state?

Most don't, except maybe SoundGraph iMon but that's an old legacy hardware anyway.

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 is indeed loads of MCE devices out there but when it comes to being capable to wake up from S5 no matter your motherboard the only reliable and readily available solution I know of is that Inteset PC-IRS5-01.

 

[HTPCSourcer]

when it comes to being capable to wake up from S5 not matter your motherboard the only reliable and readily available solution I know of is that Inteset PC-IRS5-01.

Indeed, I now remember your other posting about this device. So in essence, there is a technical (and affordable) solution, which for ~$45 comes as a complete kit without the need for soldering and/or programming.

To said $45 one would need to add taxes and shipping costs. While the latter can be shared if ordering a larger number (I would volunteer to organize it), the other cost elements are unavoidable:

Device € 25,--
VAT € 4,75
Import € 1,20
Shipping inbound € 2,-- (for ca. 10 pc)
Shipping outbound € 3,50 (per pc.)
---------------------------
TOTAL € 36,--

These costs are rather on the high side as VAT/import costs are not necessarily applying. However, if one orders a large number of receivers, customs will most likely kick in and apply duties. Otherwise one has to pay inbound shipping costs of ca. 14 €, hence the orer of magnitude is probably correct.

Myscha, how would you rate the cost of your solution in comparison to this estimated number?

 

[Stéphane Lenclud]

I payed €39,38 for Inteset PC-IRS5-01 with extension kit.

 

[CyberSimian]

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

See further discussion on that in the following thread.

 

[myscha]

Myscha, how would you rate the cost of your solution in comparison to this estimated number?

I'm sorry, but unfortunately I have only a very slow internet connecton for the next couple of days. I'll calculate and respond here when I'm back.