I have a universal remote control (Scientific Atlanta AT8550) that I programmed the CBL mode with 0008 (Motorola set top box). I am trying to read the IR code (or Key code) off the remote and compare it with another remote control (Motorola DRC800). I got the following data (not complete) and the part that throws me off is the value from this table doesn't look like any of the value people are talking about on this forum.

Key Name - IR Code (hex) - checksum - IR Code (decimal)
Power - 0A - 6 - 10
Select/OK - 11 - E - 17
Exit - 12 - D - 18
UP - 34 - 9 - 52
Down - 35 - 8 - 53
Left - 36 - 7 - 54
Right - 37 - 6 - 55

What I am interest in finding out is the IR Code like above (ie. 0A) for the rest of the buttons on the remote control. I am pretty sure the remote controls I have are RC6 (not sure what mode) and I received same code for all buttons when I used Irman.
I am assuming I will need to build my own IR Receiver and write my own programs (C, C++, Java or VB). Any help or pointer would be appreciate!

I was thrown off for a moment by the fact that 0008 is OneForAll's setup code number for the basic Scientific Atlanta set top box. But in fact you were clear: Your set top box is Motorola and your universal remote is Scientific Atlanta.

You decimal IR code numbers match OneForAll setup code 0476, the most common code set for a Motorola set top box. They do not match setup code 0869 (the other common Motorola set) nor do they match 0008 (OneForAll's setup code for Scientific Atlanta).


How did you get the ones you listed? Why doesn't that work for others? But anyway this is a very common Motorola code set and the data is available in many places.


RC6 ??

It certainly isn't the RC6 IR protocol. It is a General Instruments IR protocol.


What for? I still have no idea what you're actually trying to do.

I randomly chose one of the many JP1 upgrades for this code set (from [Link: hifi-remote.com] ) and pasted its list of functions below. A different file might have a slightly different list, but the code set is basically the same across models.


0 ... 0
1 ... 1
2 ... 2
3 ... 3
4 ... 4
5 ... 5
6 ... 6
7 ... 7
8 ... 8
9 ... 9
10 .. POWER
11 .. CH +
12 .. CH -
16 .. Music/Enter
17 .. SELECT
18 .. EXIT
19 .. LAST
21 .. Favorite
25 .. MENU
36 .. Parental Lock
38 .. A
39 .. B
40 .. C
48 .. GUIDE
50 .. Help
51 .. Info
52 .. Up
53 .. Down
54 .. Left
55 .. Right
56 .. Day +
57 .. Day -
58 .. Page +
59 .. Page -

Somehow my last post, last paragraph didn't come up.. Basically, I have a remote (I can not tell who makes it, but the label only has assembled in China - it looks like a game pad)
I am trying to read the code for each button on this game pad, but when I use Irman, I got same code for all of the buttons. And that is when I start looking at remote control stuffs. So what I am trying to grab from this game pad remote are the numbers you listed above (0 ... 59). I am trying to create a table for this game pad. for example
0 ... 0
1 ... 1
2 ... 2
3 ... 3
4 ... 4
5 ... 5
6 ... 6
7 ... 7
8 ... 8
9 ... 9
10 .. POWER
11 .. CH +
12 .. CH -
13 .. VOL +
14 .. VOL -
15 .. Mute
16 .. Music/Enter
17 .. A
18 .. B
...... and so on
(some of the value I just made them up)

And when I am done getting the key code for the buttons on the game pad, and I would like use the game pad for my PC. Hope this makes sense.

As for that RC6 stuffs. I really don't know if I was right, but few post I read on google :P were saying Irman doesn't work with RC6(?) so I figure I must have RC6.
Is there is Remote Control 101 for newbie?

I'm still not to clear on what you're trying to accomplish. I especially can't see how to relate what you're saying now to the first couple sentences you wrote at the start of this thread.

I guess you weren't really interested in the codes for the Motorola.

IIUC, you want to use a specific remote to control something on a PC.

You have Irman (hardware and software I assume) that can receive and decode some IR signals. It can decode the Motorola signals. It can't decode the signals from the remote you want to use. Is that right?

You're considering building and programming something else to receive those signals?

But you don't have any information on what those signals are?

I use a program called CaptureIR (part of which I wrote myself) that uses a simple IR detector conected to a PC printer port to capture and decode IR signals. On a fast PC it is more effective than a learning remote at capturing an IR signal for analysis. But it is intended only for analysis of IR signals. It is not suitable for control purposes because it eats too large a share of the PC's CPU capacity while running.

I don't know how Irman works so I don't know what would be required to fix it for a specific IR protocol that it doesn't handle now, especially if we don't know what protocol it is.

I probably could give you some better advice on an IR capture design if I had more of a clue of the purpose and the constraints.

Sorry, I guess I just throw two different topic into one.. let me explain from beginning, hope this would clear up thing a bit more.

I have this chart with the following remote controls
Motorola DRC800
Scientific Atlanta AT8550
Philips RC144 (looks like it)
all three remotes were programmed to work with Motorola STB.
And since there are buttons that exist on one remote which doesn't exist on the other, I was hoping to find which buttons have similar code. For example, on the Motorola DRC800, there is a button label (PPV), but not on the SA and Philips remote controls. However, I was able to launch PPV using SA remote by pressing the "*" button. So in my table, I put SA's * button next to Motorola's PPV button to indicate the two have same code.


Yes, that is the ultimate goal. But before I get to that part, I would like to keep a table of the code for each remote.


Yes, that is correct. When I use the Irman with my old Panasonic TV, I was able to read unique code (hex) for each individual button, but when I use the Motorola, SA or Philips control (all still in STB mode) with Irman, I got the same string of code (hex). And that is when I assumed these remote must be using different protocol or something unique that Irman won't understand it.



Yes again :) I bought the parts listed in the LIRC website for serial port receivers and I would like to set it up so that I can just point the remote at the receiver, press a button ( say VOL+) and it will give me 13 or 0D (13 is the decimal and 0D is the hexadecimal) on the PC screen. I hope there are code/program out there would just give me this value instead of a long string of numbers (which I can also use, just that a long string of numbers tends to mess me up if I entered one digit incorrectly).


That is what I would like to do for step one, to get the signal/code for the remotes I have and enter them to my table.


Thanks, really appreciate your help. As u can tell, I have little to no clue to this remote control world. At first, I though "come on, just a remote with 12k or 16k chip. how hard can it be?" I guess I am wrong, I can't even get the basic info down......

Maybe I'm being dense, but I still don't understand.

In the first post you have a table of function numbers from several of the IR signals from the most common Motorola STB code set. Where did that table come from? You now say you have three remotes that generate parts of this code set, but Irman doesn't understand the signals from any of them.

One alternative for finding out what signals your remotes are sending: Your profile says you are in the town where my wife works. Reply by email if you want to drop off a remote there; that evening it would take me just a few minutes to read out all the signals (of one code set) through CaptureIR, and my wife could have it back to her workplace for you to pick up the next day.

Another choice would be puting together the CaptureIR hardware yourself. It is pretty simple, and I can give you the up to date version of the software.

Regarding the LIRC hardware, I don't know much about LIRC hardware and software. I'm sure there are forums where you can get better instructions on using all that. But what components did you get? It may be you have a component that could be connected temporarily to a PC printer port and be compatible with CaptureIR.

On yet another aspect of all this, I don't see what your issue is with a "long string of numbers", unless you meant an "inconsistent long string of numbers" as many IR capture devices yield. You're planning to involve a program in the process anyway. If you can convert an IR signal to anything that consistently discriminates between buttons, a program can easily translate that to watever dense coding you like.

I must not understand the basic and start throw questions at people.. sorry...


I created the table myself, but the value was gathered from Internet :P let me copy and paste a few lines...

Code(decimal)Code(hex)AT8550RC144DRC800
88888
99999
100APOWERPOWERPOWER
110BCHAN +CHAN +CHAN +
120CCHAN -CHAN -CHAN -
130DVOL +VOL +VOL +
140EVOL -VOL -VOL -
150FMUTE MUTE MUTE
1610
1711SELECT/OKSELECT/OKSELECT/OK
1812EXITEXITEXIT
1913LAST CHANNELLAST CHANNELLAST CHANNEL
2014INPUTINPUTINPUT
2115FAVORITEFAVORITEFAVORITE
2216
2317AAA
2418*PPV
.......
So if you look at last row. 24 is the decimal (I converted this from the 2nd column, so the remote control might not be sending this), 18 is the hex value of 24 (I got this off the lirc database, again could be wrong?). So with DRC800, PPV button has code 18 (I got this from Lirc site) and with AT8550, the * button launch PPV, so I put * on that row. What I am trying to do is, aim the remote (either of the 3 remotes, just got RC144) and press the PPV on DRC800 (or * on the AT8550) and the PC screen will give me the value 18 (hex) or 24 (decimal) so I can put a check on that row indicating it is verified :)
Actually, on a sidenote, usually what do the remote sends out? I know the value I got from Irman was something like 00 0A 1C 3D 00 FF instead of just 18 or 19. BTW, I programmed the remote to Motorola STB (code 0008)


Sure, but I won't be heading down to NJ until end of Oct (I left them at home, I could as my brother to ship them to me). This is a hobby that I am interested in doing. I was back home for the entire 2 weeks and now back to Boston :)


Sure, if you can point me to some direction. It would be helpful.


Here is what I ordered so far -
- TSOP 1738 IR Receiver
- 1N4148 diode
- 4k7 1% 4.7 kOhm resistor
- 100mA, voltage regulator with TO-92 casing
- 4.7µF capacitor
that is all I got so far, I know I need more, but didn't have to to shop around. :P


As long as I can get distinguish number for each button, I am fine. I was just wondering how these long string of numbers were mapped or convert or whaterver to something like 1A.

Thank you for everything!

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.