Is there such a device?

[Guy Lavoie]

I was wondering about something to resolve IR input issues: is there a device that can recognize different native IR codesets and output a serial data string to indicate which one was received. I'm asking about real code recognition, not learning and matching like we do with the Ocelot and other devices. In essence, I'm looking for something like the X10 MR26A, which recognizes the native X10 rf protocol and sends serial data, but in this case I'd like it to recognize several IR device types instead, such as Sony, Panasonic, etc.

 

[electron]

what about this?

http://www.happy-beginnings.de/IR/

I would definitely love something like that as well.

 

[smee]

What do things like the USB-UIRT send to the PC? I'm sure that it is sending some sort of raw data to the PC (and not doing the comparisons within its hardware).

It shouldn't be very difficult to build one. It all depends on what you want it to send (data bytes vs timing info, for example). If you restrict it to a single data format (Sony, RC5, etc.), it may be easiest to have it return codes.

 

[Guy Lavoie]

The problem with that type of unit is that it doesn't attempt to recognize anything. It just spits out numbers about the signal envelope timing (which might vary slightly from one button press to the next) and the device receiving the serial data must then attempt to recognize it based on how "close" the envelope timing is in relation to known or learned codes. That's how the Ocelot does it too...and is what I'm trying to avoid. An intelligent receiver would be able to figure out that this is NEC-1, NEC-2, or Sony protocol and which device & code number is being sent, just like those Pronto code generation utilities do, but in reverse.

 

[smee]

If you are willing to work with only a single protocol, BASCOM-AVR supports a GETRC5 command which will receive and interpret RC5 (returning a 14-bit number). You can then send that through the serial port (or change it to whatever you want). If you want to use a different protocol (or recognize more than one), then that's more work. But you should be able to do it from the timing info.

I assume that you want to connect this device to something like the Ocelot, which doesn't have the processing power of a PC to handle decoding the timing?

 

[Guy Lavoie]

smee, that's the issue: being able to recognize intelligently among several protocols. It seems to me that it should be possible to identify the protocol among the several "well known" ones that most equipment manufacturers use. For example it could go like this: If, after the long lead-in pulse, you get 12 bits and then a long off time, this must be Sony protocol. Decode the device and key code and send maybe 3 bytes (1=sony, device code, key code). If instead the code data keeps coming in and pauses after 32 bits, then this must be NEC-1. Look for the mirror pattern in the first two bytes and also in the last two bytes. If they appear valid, send (2=NEC-1, device code, key code). If instead the data keeps coming in but stops after 48 bits, then it must be NEC-2 code. Look for one of the several known data validation schemes in the bit pattern and send (3=NEC-2, device code, key code). Get the idea?

 

[smee]

Take a look at the Irman from Evation. It connects to a serial port.

When it receives an IR signal, it sends 6 bytes out through the serial port. These 6 bytes do NOT correspond to address and key information from the remote. They say "These 6 bytes are pseudorandom, but constant for every specific key on a remote."

Since the 6 bytes do not correspond to protocol information, you will need to do comparisons with known values in a table (or similar).

The Irman has been one of the favored IR receivers in the HTPC community.

 

[Guy Lavoie]

That device looks a lot better. It appears that it generates the "random" bit pattern of the 6 bytes it sends based on the timing that it sees from the signal envelope. This is ok for a table lookup (where you create a table of the codes you want to be able to recognize by learning them) but makes predefining what code sets you want to look for harder, since two otherwise "adjacent" codes might give two completely different byte patterns. This would make a standalone (non-PC) device harder to use.

Has anyone here ever used this device? How reliable and tolerant is it in giving out the same bit pattern for a given remote button?

Too bad it costs almost as much to ship it as its unit cost. Now we know how HA hobbyists in Europe feel!

 

[JohnBullard]

Guy,

Have you contacted Jon Armstrong. He seems to know everything about IR?

Just a thought about an additional resource.

 

[Guy Lavoie]

For sure, if I have any questions about actual protocols used by different products, Jon's name immediately comes to mind. He knows this subject inside out! I didn't think about asking him about the hardware however, and that sounds like a good idea now that you mention it! Do you know his email address, or where I can reach him easily?

 

[JohnBullard]

Guy,

I don't feel comfortable posting Jon's email address without his permission, but,

on the ADI forums, search for member number 69.

 

[Guy Lavoie]

Now, why didn't that come to mind? Thanks John, I just looked it up. In fact I'll refer Jon to this thread so he can see what has already been discussed. I'll add any new information he provides, unless he just does so himself right here.