I'll tried to learn a remote sending RECS80 Code into a MX-950 but this won't work. It's a remote for a 6 Channel Relais-Box to switch Power Supplies. The Remote is hardcoded to modulated pulse code and transmitted one toggle-bit, three adress-bit followed by six command-bit pulses. Please have a look at the pdf-sheet of the used SAA3004:

[Link: it.lth.se]

The box uses Device 1 for TV and the buttons 1-6 for the channels and other for eg. all on and off. I know that the MX-950 only accept HEX-Code in Pronto format and i know the way to get Hex-Code from the pronto-editor database to the MX-950. But my problem is to get the Hex Code's from this device.
Is there anybody who can explain me step by step how i can translate the giving information from the data-sheet in the known pronto hex format? Also i did not know enough about timing and affords to the pronto header-format to build it for myself. My next problem is my bad english, so be appreciate. Thank you for help.

I think that may mean the signal is not modulated.


Are you sure? That pdf file describes both modulated and unmodulated ("flashed"). How do you know which your remote sends?


I don't think the MX-950 can handle the toggle bit correctly, so that may complicate things after you have it basically working.


I look at that pdf again later and give you more details.

The Pronto Hex can be generated with the MakeHex program. But that pdf covers a range of choices for the exact structure of the signal. I don't know whether the RECS80.irp file included with MakeHex is the structure you want or whether it would need some changes.

If the signal is unmodulated, there is a Pronto Hex representation for unmodulated signals, but I don't know whether the MX editor cam import that.

Hello johnsfire,
and thank you for your fast reply.


I'll opened the remote and saw that the driver pin DRV6N is connected to ADRM, that's described in the manual as modulated output.


Often I have problems to learn toggle bit into a MX-950 but if i take the code from a database, everything works fine.


This is very kind and in the meantime i take a look at the MakeHex-Program and the form of the RECS80.irp file.

There are a couple different versions of RCES80 in MakeHex.zip

Here is the RECS80_45 version for discussion:

Device=5
Function=0..63
Define T=0
Frequency=38000
Zero=170,-4900
One=170,-7425
MESSAGETIME=121000
First Bit=MSB
Form=;1:1,T:1,D:3,F:6,170

The lines you probably want to change are Device, Frequency, Zero, and One.

Device you said you knew was 1.

Frequency (in hertz) is 1 over the value described in that pdf file as "tM".

In "Zero" and "One", the values are in microseconds. The first value (170 above) is the value described as "tPW" in that PDF (but using a larger value for that than documented usually improves reliability).

The unsigned total of the two numbers in Zero (5070 in the version above) should be the value documented in the PDF as "2 x To".

The unsigned total of the two numbers in One should be the value documented in the PDF as "3 x To".

You also might change MESSAGETIME, which is "tW" in the pdf file.

Did you check the oscilator component(s) in your remote? I think the "455 kHz" value for fOSC in that PDF is an example, rather than a standard. Everything else seems to be computed from that.

1) I forgot to mention above: All frequency and timing values just need to be rough approximations. There is no benefit to getting it exactly right. Pronto Hex doesn't represent that level of precision and the IR transmit process itself isn't precise.

2) I checked the formulas in that PDF file, using 455kHz, and RECS80_45 seems to be correct already.

tM = 12*tOSC = 26.37 uS
freq = 1/tM = 37917
RECS80_45 has 38000, which is closer than it needs to be.
tMH = 4 * tOSC = 8.79 uS
tPW = 5*tM + tMH = 140.66 uS
RECS80_45 has 170, which is intentionally larger, because that usually helps.
To = 1152*tOSC = 2532 uS
Second part of "Zero" = 2 * To - increased_tPW = 4894 uS
RECS80_45 has 4900, which is closer than it needs to be.
Second part of "One" = 3 * To - increased_tPW = 7426 uS
RECS80_45 has 7425, which is closer than it needs to be.

First of all, thank you much for the time you spend on my problem, it is not self-evident to do that. With your help now i get light in the darkness-thanks!!


Yes you're right, there is a 455kHz Ceramic Resonator inside. So i think your calculations of your last post will work. Now, after you give me the "How To" I'll try to test around with a little diffrent values this night an give you the reply if it works.
But there are two things i didn't understand in the moment:
The carrier frequency is 38kHz but in the Reciever there is build in a TSOP1736 with 36kHz. Is that not a mismatch? And in the line "Form" is there T:1 the value for the toggle-bit? If so, with T:0 i am able to make discret codes? In the moment, one keypress switches on, the next switch off the device.
Thank you once again for your answer!

Small changes in those values DO NOT make any difference that matters in the signal your remote would generate.

It is possible that the 170 uS is too small for the MX-900 to process (which might explain the learning problem). In that case, you might fix things by a BIG increase in that number, while decreasing the next number to keep the total unchanged.

The Philips documentation focusses on what the encoding chip creates, rather than what the decoding logic requires. Typically the decoding logic only cares about the timing of the active edge out of the TSOP1736. It doesn't care about the inactive edge. So making that 170 MUCH longer will make no difference to the decoder while making the TSOP, and maybe the MX, more reliable about processing the pulse.


Not as serious as you might expect. A TSOPxx36 will receive 38kHz signals fairly well. Each TSOP chip has a published spec sheet that has details such as how much performance is degraded for a given difference in frequency. I don't have the TSOP17xx spec sheet handy, but others are spec'ed that a 10% difference in frequency (39.6kHz for as TSOPxx36) is the same effect as doubling the distance between the remote and the sensor (which typically isn't very much).

However, it is strange that the designer of that device chose a TSOP1736 instead of TSOP1738. There does seem to be something there we're missing.

Of course, you could always try 36000 instead of 38000 and see what difference it makes.

However, each of those TSOP parts typically specs a minimum number of carrier cycles per modulated pulse. Most of them spec ten cycles. I don't know what the TSOP17xx spec is. 170 uS is less than ten cycles. At 36kHz it is even fewer cycles.

The original design might have been out of spec and only marginally working.


Double NO.

1) T:1 in the Form means that T is one bit LONG, not value '1'.
The value of T is controlled by the line
Define T=0
You could change that to T=1 for the other toggle state.

2) A single T value may act like a discrete code during simple testing, but it would never work correctly as a discrete code in real use.

I checked the pdf file (from the manufacturer Vishay Telefunken) for the TSOP17xx.

It does spec the minimum modulated pulse as ten cycles of the carrier. So using that for RECS80 seems to be a serious design flaw.

I was helping someone with a project a few years ago and he used a different TSOP part with the same documented ten cycle limit for a protocol with a only five cycles of mudulation. It didn't fail entirely, but it wasn't reliable enough for general use. He needed to change his design.

Also the graph in that PDF shows a "Responsivity" of approximately .6 for the frequency error of a 38kHz signal to a 36Khz part. I'm not entirely sure what "Responsivity" means in practical terms, but they seem to use it in a way that varies with the square of the distance between the remote and the sensor, so a "Responsivity" of .6 should just reduce the maximum operating range of the remote to 77% of what it would be otherwise.

Hello johnsfine,
unfortunatelly i had no success. I tried several timings and settings and had no luck. Then i noticed that the control LED at the Reciever did not flash with my beamed signals.
So i thought there must be basically something wrong with the signal. I opend the remote again and determind that the sub-adress of the remote s0,s1,s2 are coded to binary 111 and that is in the Data-Sheet described at sub-adress 0 . So i tried 0 for Device but also no luck. Currently i'm helpless. But i won't give up. Tonight I'll try to lock at the pulses with a scope, perhaps this give me a hint to my problem. You tried hard to help me - thanks for that!

What function number(s) did you try? Did you examine the key matrix on the original remote to deduce the function numbers of any important keys?


What data sheet? I don't see that in the pdf you linked. What is connected to the address pin of that Philips chip?

If you know a valid function number, you should try all 8 possible device numbers (0 to 7). I'm not convinced you are interpreting those address switches correctly.


Do you know what they're supposed to look like?

What will you connect the scope to? (The IR LED inside the original remote or the output pin of the TSOP1736 inside the IR receive device or what?) I think you'd get the most information from that TSOP, but that is subject to whatever mechanical issues there may be in touching the scope probe safely to the right point.

Once again:

I'll tried Device number 0-7 because in the Data Sheet of the SAA3004 they count from 0 to 6. The function number 16 from the matrix is my key for channel 1.


Please look at the data sheet of the SAA3004 Table 3. Pin 9 (ADRM) is connected to pin 19 (DRV6N). My Remote is similar to the circuit diagram shown in fig.1


No, i don't know how they look like but i only want to compare the signal from the original Remote to the programmed signal of the MX-950.


I have a IR-Testreciever with scope output. He only shows me the transmitted signal.

Now here is the output from MakeHex for eg. i used:
Device Code: 1 Function: 16
0000 006D 0000 000C 0006 011B 0006 00BB 0006 00BB 0006 00BB 0006 011B 0006 00BB 0006 011B 0006 00BB 0006 00BB 0006 00BB 0006

these are 25 hex codes and i dont know for what they are standing and how they are compound. There are the bits for adress and command integrated, but i know not enough about binarys so i can't encrypt that. Sorry for this. I'm sure I'll make a big mistake but i need time to look at it again. Often the mistakes are simple. I'll try it again and will report.

Did you do that copy/paste wrong only when you copied that Pronto Hex into your post above? Or did you make similar errors when you copied the Pronto Hex to the Universal browser?


Actually it is 28 hex codes. It should have been:

0000 006D 0000 000C 0006 011B 0006 00BB 0006 00BB 0006 00BB 0006 011B 0006 00BB 0006 011B 0006 00BB 0006 00BB 0006 00BB 0006 00BB 0006 088B

I assume that Pronto Hex string is too wide for the display in whatever text editor you used to open the .hex file, and word wrap or related issues caused you to truncate the string as you copied it out of that file.


Basic description on that:

The first number 0000 tells which form of Pronto Hex this is. I think Universal browser only understand 0000.

The second number 006D encodes the modulation wavelength (the value tM in the PDF file, but in strange units).

The third number 0000 gives the length (in cycle count pairs) of the non repeating header of the signal. RECS80 doesn't have one.

The fourth number 000C gives the length (in cycle count pairs) of the repeating porting of the signal.

The rest of the numbers are cycle counts:

The fifth number 0006 says the signal starts with six cycles of modulated signal.

The six number 011B says those six cycles of modulated signal are followed by a gap that takes as long as 0x11B cycles of modulation would have taken (but a gap contains no signal, so there are no actual cycles).

The rest continues that alternating pattern.

When you look at the signal on a scope, you should see a sequence of 12 very short modulated bursts seperated by short gaps, followed by a longer gap, whole thing repeating (same 12 bursts again, same gap, etc.)

The information is encoded in 11 durations, which are measured from the start of each modulated burst to the start of the next one. Each of those durations should be either 2*To or 3*To, where To is that value around 2.5 milliseconds that was derived above from the info in that pdf file.

Simple mistake with large effect! Yes, i did the copy/past wrong into the MX-editor. The text-editor window was to small and i did not noticed that. Shame on me! I'll try it again later.
Thank you for your description about the hex-code. No it gets clearly to me.

Hello Johnsfine,
last night i had time to test again. Also with 28 hex-codes i had no success. The reciever-Led won't flash. After that i looked at the remote with a scope. I saw a clear pulse package with ten pulses.There was no reference-bit and the package starts with the toggle bit, followed by three adress-bit all of 1. So i got for Device=1 and Funktion 16 this result at first keypress:

and second keypress:

Then i looked at the output of the MX-950. I took the hex-code also for Device=1 and function 16 and had problems to sync the signal with the scope. I saw a large square pulse and it seems to be so long as the pulse package of the original remote. In the square was a small pulse package embedded but i could not synchronize it. Othere codes i fired out of my MX-950 (eg. TV) looks also clear and synchronized with my scope. I think i have a general Problem with the timing. Any more ideas for me?
Thank you for response.

I would need more details of what you saw in the scope in order to give you useful advice.


You listed ten bits. Ten bits would take eleven pulses. The bits are defined by the duration from the start of one pulse to the start of the next. So the last pulse can't define a bit (because there is no next pulse).

What did the pulses themselves look like? According to that PDF, each "pulse" should have consisted of five much shorter pulses (cycles of the modulation). Can you see that (and the modulation cycle length) on the scope?

What duration (start of pulse to start of next pulse) were you seeing for each of '0' and '1'?


That is strange. It isn't the expected number of bits (from the PDF). It isn't device 1 and it isn't function 16.


My first guess is still that the 170 uSec pulses are too short for the firmware of the MX to understand and it gets confused and generates a mess.

I have an MX-850, which might process things in a similar way. I also have a very good IR capture system. I'll try to find some time (maybe Sunday) to run a test. I can import Pronto Hex for RECS80 into my MX-850 and see what signals it actually generates.