Re-using IR Decoder Chip

No!

Okay then, how about a purchased IR decoder chip, for example for a NEC protocol? They should be fairly cheap. That should ease the load on the cpu.

Won't you need "the cpu" to translate what's decoded and convert it to serial anyway?

Help me folks.. the was an old cartoonist who used to draw cartoons of complex ways to do simple things?

Oh wait.. I got it I think.. "Rube Goldberg"?

Just Another Joe wrote:

I'm not sure what it is you are trying to accomplish. Decoder chips for specific protocols went out of style about 20 years ago. A NEC decoder is only useful for the NEC protocol and any microprocessor can do the same job as well as handle other protocols.

IR receivers like the [optional] TSOP1100 used in roZetta handle carriers from 33-57kHz and output the demodulated data envelope. The most widely used IR protocols are fairly easy to distinguish and decode - there's little processing involved. And, you really do not need to decode - as long as you can output a unique code that is consistent for the specific sequence of IR (or RF bursts) you can use that to trigger consistent responses.

Less widely used IR and RF protocols (there are thousands) are not so easily handled as far as decoding but nothing you propose changes that.

Maybe an example will help. The snake-oil purveyors (Pay no attention to that fishy looking fellow behind the curtain.) pushing Z-Wave make much ado about it using DES encryption. I don't give a fig about the protocol or about how it might be encrypted. I can capture a transmission and play it back and it will have the same effect every time regardless of the protocol and regardless of any method of encryption. The encryption does nothing other than prevent neighboring systems from controlling your system - it doesn't take DES encryption to do accomplish that.

Okay, perhaps I'm misunderstanding how roZetta will capture IR. I took it that the cpu would 'watch' a particular pin for transitions from the IR indicating ones and zeros until a byte was accumulated, rather like capturing serial bits and bytes. The timing and decoding would need to be adjusted for each IR frequency and protocol.

Now, I've seen IR decoder chips which do the capture, and simply present a byte representing the code to a serial port. That is what I meant by easing the load on the cpu. This would be rather like using a W800RF32 to decode RF and simply present bytes to a serial port. But, if it doesn't provide any real advantage with the IR, that's okay. It was only an idea.

roZetta will capture IR in the same manner as the ocelot captures IR except the TSOP1100 handles a wider range of carriers (33-57kHz) than the TSOP1138 used in the Ocelot (38kHz).

When the Ocelot "learns" an IR code it merely stores an image of the data envelope in memory. When it later receives a code it compares the received data envelope with those it has stored. The elegance of the system is that such brute force methods give results that seem quite a bit more sophisticated than they really are.

roZetta will only handle the X-10 IR protocol plus the extensions that Laser Systems developed a few years ago. roZetta does not attempt to decode other IR protocols (although it will output hex codes for the NEC protocol since it's the same as the X-10 RF protocol). And, the IR and RF receivers use the same input pin so they are mutually exclusive.

The device you mention copied what I did with the BX24-AHT except they did not realize that I was doing some decoding internally and making some logic decisions before outputting the hex codes. The hex code output is inadequate to fully discriminate between various types of X-10 RF codes.

Now, I have tried repeatedly to shift these discussions to the roZetta Yahoo group since it is rather specifically about roZetta. I will not respond further here.