I have RECS80 codes for a Classe pre-amp working with a MX-800. It is a different remote and a different device, but thought I would post this just in case it helps.

For system (device) 1, command 16, I use

0000 0074 0000 000C 0008 00FE 0008 00B6 0008 00FE 0008 00FE 0008 00FE 0008 00B6 0008 00FE 0008 00B6 0008 00B6 0008 00B6 0008 00B6 0008 048F

I used ProntoEdit and Universal Browser to get it into the MX-800. The original code came from Classe and I have used it to generate commands that they did not provide.

I use an unused command (command 48 in my case) before each command in a macro to do the toggle part. That way I do not need toggle versions of each command. Works for my Classe.

Not sure if this helps or not.

dtc from Billerica

Still true.


I tested that and it all ran perfectly. My MX-850 correctly sends the signals I generated with MakeHex and that .irp file, and converted with Hex2CCF then imported with Universal Browser.


I just noticed you're that close to here (Burlington).


A good suggestion. If Remotefan gets things basically working and hits issues with the toggle bit, that is a good next step.

Sorry for the long time, but i had an accident and stayed the last 10 days in Hospital but i feel quiet well again.
My Problem with the RECS80 Code is solved. The problem was, i always copy & paste the hex-codes directly in to the hex-Window of the MX-950 universal Browser. Since i tried to convert the hex-codes build with makehex with irpanel to ccf file and then import that file, everything works fine. I used MX-950 Editor Ver.1.10.1. After updating the Editor to Ver. 1.10.108 also the copy & paste directly into the Hex Window works.
Makehex is a great solution to get codes from signals which are hard to learn into a remote. So i tried to build some codes for a RC5 Signal and the next problem appears:
I have a remote wich sends on first keypress device Nr.16 and on second press device Nr.48. I discovered that the rc5.irp file is used to get hex-codes for devices up to 32 and the rc5odd.irp file is used to get device numbers above 32. So i build my hex codes for device nr.16 and 48. But now my question: How can i combine these two hex codes so that i get on first keypress for eg. device nr.16, function 12 and on second press device nr.48 function 12?? Is this generally possible or is there only a simple trick to make that?
Please, enlighten me.....

That feature of the RC5 protocol is called a "toggle bit".

Sorry, I don't know enough about the MX-950 to know how to correctly import a signal with a toggle bit.

I expect built-in code sets for RC5 would get that right. Most RC5 code sets are consistent across a large range of models. So probably there is a built-in code set that will give you better results than learned or imported signals.

RECS80 also has a toggle bit and is less likely to have a matching built-in setup code.

There are some difficult work-arounds for problems with toggle bits, that can be used if necessary.

My CD player uses RC-5. As I understand it, the RC-5 device will not respond to the second of 2 consecutive identical device commands. The second command must be a "toggle" form of first command - or it can be a different command - for the device to respond to the code. For my MX-800, I build a macro for each command with an unused code (using the second form (NR.48)) followed by the desired code (NR.16 form). So I do not use the second form (NR.48) of each command at all. It means every command is a little slow because of the time between commands in a macro. This is only a problem in a long macro of multiple commands. Also, since you need to have both the NR.16 form of the command and the macro on the remote, it does takes space on the remote. Not elegant, but it works. The 950 may have a more elegant way to do it, but I do not have a 950. I do the same process for RECS80 codes for my pre-amp.

You can eliminate most of that delay by using a single Pronto Hex string for the two commands, rather than using a macro.

That also can give you correct results for keys that need extended duration when held. I'm pretty sure a macro can't.

A simple edit to the irp file will let MakeHex produce the desired double commands.

For commands that don't need duration based on the key press, you would have better response if you put the real command first and the dummy command second.

For commands that do need that duration behavior, there is no great solution to the problem of needing the dummy command first.


It shouldn't be an issue at all in long macros. In a macro, the sequence of commands is defined when you write the macro, not subject to the sequence in which the user presses buttons. So you will know in most cases that each command differs from the previous and thus doesn't need protection by a dummy command. In those cases where a command must be repeated, you can include and use the alternate toggle, so even there you don't need protection by a dummy command. Only the very first command of the macro might need such protection.

Thanks for the comments.

For my pre-amp there are about 20 commands, which means I would need to store 40 total commands, which fills up the device on the MX-800 before i have even build any macros. So, to save space on the remote I am storing only one form of a command on the remote. So I have the same form for all the commands and then just 1 dummy command of the toggled form. So, to buld a macro I need the toggled command before each command. If I had all the toggled forms of all the commands on the remote, I agree I could build macros without the dummy command, except at the beginning, as you say.

As to the timing issue in macros, I believe (may be wrong) that the MX-800 inserts a delay between each command in a macro. If you do a macro with a lot of commands in a row(e.g. Power On, Input 1, Mute Off, 6 Volume up commands) and there are dummy commands in front of each, the extra dummy commands and those delays can add up. That is what I was referring to. If the delay is minimal, there would not be a real issue. But since the long macros are only used occassional in my case, it is not really an issue.

I agree that doing the dummy command second can speed up the response to the macro. I put the dummy first just in case a command was given without the dummy - for example from the original remote. The dummy first insures the command will still work. Just a little extra caution.

How do you produce a double Pronto hex string in MakeHex for RC-5?

For example, in my case, the two codes for function 48 are

0000 0073 0000 000A 001F 001F 003F 003F 003F 003F 003F 001F 001F 003F 001F 001F 003F 001F 001F 001F 001F 001F 001F 0491

0000 0073 0000 000B 001F 001F 001F 001F 001F 001F 003F 003F 003F 001F 001F 003F 001F 001F 003F 001F 001F 001F 001F 001F 001F 0491

I use only the first one. I use the second form for function 63 (not used) in the macro for the dummy commnand.

0000 0073 0000 000B 001F 001F 003F 003F 003F 003F 003F 001F 001F 003F 001F 001F 001F 001F 001F 001F 001F 001F 001F 001F 001F 0491

I have tried just concatenating the first function 48 code with the 63 toggled code, but ProtoEdit says the concatenation is not a legal code. What is the correct way to combine these?

Thanks.

I'm surprised an MX-800 is that limited. But how many commands are ever used in long macros? Only those would need the non compound form.


Even though the original remote toggles on each command, the device doesn't require that. The toggle is only needed when the same command is used twice in a row. So even with single version non compound signals, you would mostly not need the dummy command between real commands in a macro.

The device will correctly process a bunch of commands in a row that are the same toggle state but different functions.


I think you're right and I think that is most of the total time.


Seems like excess caution. And if you are using both the original and the MX-800, having the dummy first means the original remote can fail when you use it right after the MX-800.


Try this in place of the Form line in rc5.irp (and save that as a different name.irp)

Form=*,1:1,T:1,D:5,63:6;*,~F:1:6,T:1,D:5,F:6

The part after the ; is the same as in the regular rc5.irp and describes the repeating frame of an RC5 signal. The part before that describes a single frame of function 63. In that part, I put 63 in place of F and I put 1:1 in place of the complex expression ~F:1:6 that places the inverse of the extra bit of the function number as required by the rather strange rules of RC5.

That concatenates a single frame of the dummy first, followed by repeating frames of the real command. I think one frame of dummy is enough, even though I expect the MX-800 would send a few frames of each command when they are used the way you have been using them.

As I said earlier, commands that need to be extended while held can only be done the above way (single dummy first, followed by repeating real command).

Commands that don't need to be extended might work better with both parts single, but I'm not sure how to get Universal Browser to understand that. For a Pronto, it would be:

Form=1,~F:1:6,T:1,D:5,F:6,^128,1,1:1,T:1,D:5,63:6,^256

But I'm pretty sure the correct Pronto Hex that MakeHex would generate for that would confuse Universal Browser.


I see you have a much smaller end value than specified by rc5.irp. If you have reason to want that smaller than the RC5 standard, reduce the MessageTime value in the .irp file.


The first four values in Pronto Hex are a header. To combine to Pronto Hex strings, you need to edit the first header and drop the second header.

The MX-800 has 20 devices each with 40 LCD slots. So there is a lot of room in the remote itself, just not in the LCD buttons for each device. I am using most of the other other devices (home theater, 2 channel, lights, lots of extra Yamaha codes, cable music, etc.) so want to confine the pre-amp and the CD player to one device each.


That is what I thought. But when I give multiple commands of the same toggle state, the second and following ones are not recognized. I need a toggle command in between. Not sure why.


The original hex codes came from Classe - so I just used them directly - and then for additional commands I changed the file that MakeHex produced to match the Classe form. Simple replace with an editor. I can also try the MessageTime value.


I will try this and the MakeHex suggestions. How would I edit the first header? Does it matter that the 4th value of the 2 commands are different?

Thanks.

The third and fourth values together count the number of pairs of values in the remainder of the string, with the third giving the number of pairs in the part (normally missing for RC5 and RECS80) which is sent just once, and the fourth giving the number of pairs in the part that gets repeated after that.

The simplest way to combine is to put the 4'th value from the first signal as the 3'rd value of the edited header and the 4'th value of the second signal as the 4'th value of the edited header. That edited header is then followed by the body (all but the first four values) from the first signal, followed by the body of the second signal.

All that only works if the second value in the header of the first signal is the same or very close to the second value in the header of the second signal. For program generated signals or good learns of the same protocol, that would always be true. But it can complicate things when someone tries to mix in signals from some worse learns.

I combined a code with the dummy by concatenating with changed headers and it worked fine. I input the combined code both through the Universal Browser both from a ProntoEdit file and directly through the new hex input option. Both worked fine. I have only tried one code for a test, but that works fine. I am tied up for the next several days and do not know when I will get back to this. But for now, it seems to work fine. This is with RC5 codes. I also want to try it for RECS80 codes, which I have a lot more of - pre-amp is RECS80 and CD player is RC5. Presumably it will also work on the RECS80 codes. This will clean up my remote a lot - no more need for the macros to do the 2 commands. Thanks John!

I realized the above could be misunderstood if taken even slightly out of context.
The correct rule is that the third value in the combined header is:
The third value from the first header
plus the fourth value from the first header
plus the third value from the second header.

For your current signals, that simplifies to what I said earlier, because the third values of the original signals were all zero.

The fourth value of the combined header is (as I described earlier) just the fourth value from the second header.

I finally got back to working on these double command hex codes. I tried them on my RECS80 pre-amp. They work - but not consistently. Sometimes I have to hit the command 2 or 3 times or do another command in between to get it to work. I cannot find a pattern in the problem. I also tried several of the double codes in a macro to be sure it was not a problem with the remote buttons - still had problems, but not consistently. At one point one code actually locked up the MX-800. I had to pull the battery to reset it. I suspect the remote is not handling the double codes consistently. It is also possible that the pre-amp cannot handle the commands consistently. So, I will continue to use the macros - not as elegant, but they do work consistently. John - thanks for the suggestions.