So your table matches the Motorola code set I identified because that is the data you selected from the internet, not because of any data captured from your remotes.

So if you made a mistake in which Motorola code set you selected from the internet, your remotes might be sending the other common Motorola code set.


The remote sends a bunch of bursts of IR where the various durations of the on and off halves of each burst encode the information. There are many different protocols for encoding information in bursts. The code set we discussed has an 8 bit function number, a 4 bit device number, and a 4 bit check nibble. But Irman might not understand how those 16 bits are encoded into timing so it may convert the raw timing info into hex numbers in some totally bogus manner.


Misunderstood that also on first read. The remotes are in NJ? Irman and the LIRC hardware you bought is where? You are back in the Boston area?


The 1738 you mean is this one?
[Link: vishay.com]

That demodulates the incomming signal at 38Khz. That is probably a good choice.

I think the G.I. protocol in the code set you think you have is modulated at 38.7Khz. I think the G.I.4DTV protocol used by the other likely code set is modulated at 37.3Khz.

I'm not sure I understand figure 1 in the data sheet for the 1738, but it seems to indicate you would be in good shape anywhere from 36Khz through 40Khz with the 38Khz part.

All those other specs in the data sheet (minimum of 10 cycles per burst and minimum gaps under various conditions) are satified by both those G.I. protocols.

I read through that data sheet a few times looking for where it says whether the output signal is active high or active low. I think some of the things it says imply active low (output normally high and goes low when a properly modulated signal is detected). But I'm not sure. Can you tell?

For CaptureIR I use a part that is not demodulated (passes the raw signal to the PC) and is active high. But I think CaptureIR would also work with a demodulated input and it would be a trivial code change to reverse the input polarity.

Using a part that doesn't demodulate places a much higher demand on the CPU and it reduces the effective range, but it allows you to analyse a much wider range of IR protocols (typical protocols as well as unmodulated protocols and those modulated at strange frequencies).

Since you have a specific protocol in mind and it is modulated near 38Khz, that was a good choice of IR receiver.

The captureIR design just requires that you connect the output of an IR receiver to pin 9 of the PC printer port.

Of course the IR receiver also needs power. The official captureIR design takes power from pin 1 of the printer port, but that doesn't have enough power for the IR receiver I used (I assume not for your IR receiver either). I had some old USB cables so I cut one apart to take the 5v power from the PC's USB port. Your LIRC design regulates power from an RS232 control pin in the PC serial port.


That 1A (from internet sources) was the fully decoded function number in the signal. My decodeIR.dll (freeware used by captureIR and many other programs) takes raw IR timing and fully decodes it to the correct protocol name, device number and function number. Cruder designs such as Irman and LIRC examine the signal and try to condense the raw timing into data by generic methods that function without any built-in knowledge of the possible IR protocols.

If a generic design were robust it would be better. If a protocol is used that I haven't manually examined and coded into DecodeIR, then DecodeIR falls flat, where a generic design might work. But in fact generic designs aren't robust. I've covered most of the common protocols (including those two Motorola uses) in DecodeIR and it works across more signals than LIRC handles, which apparently is a lot more than Irman handles.