Is there a way to use RC5 codes directly in the T2?

If not (I cannot find it anywhere in the manual or in this forum) can anyone help me with converting RC5 codes to hex codes to use in the T2?

I have the RC5 codes... examples are...

Device code 25

Power on 123

Power off 124


Thank you.

Cougmeister

Here are those commands in the non-database format in Pronto Hex. These can be done with John Fine's MakeHex found in the Pronto|Utilites section assuming this is what you want.

Device Code: 25 Function: 123

0000 0073 0000 000B 0020 0020 0040 0040 0020 0020 0040 0020 0020 0040 0020 0020 0020 0020 0020 0020 0040 0040 0020 0020 0020 0CA4


Device Code: 25 Function: 124

0000 0073 0000 000B 0020 0020 0040 0040 0020 0020 0040 0020 0020 0040 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0020 0CC4

-Jon

Jon,

Thnak you for the information. It is helpful even though I am not sure this is what I want either.

I am trying to use the "remote in" wired connection on the Arcam DV27 to maintain a consistent response. Arcam says it accepts RC5 codes...which the T2 does not have a mechanism of accepting as RC5. There is a way to add the hex codes. I tried the ones you sent, without success.

There must be some parameter I am not adding.

Thanks again.

Cougmeister

Would anyone know why the codes sent by Jon would not work in the T2 when cut and pasted directly into the F12 function of the T2 remote library?

For example, the Device Code: 25 Function: 123

0000 0073 0000 000B 0020 0020 0040 0040 0020 0020 0040 0020 0020 0040 0020 0020 0020 0020 0020 0020 0040 0040 0020 0020 0020 0CA4

does not work directly. It has a frequency of 36 kHz and 1 repeat. The direct learned command has a frequency of 35.7 and 2 repeats.

Any suggestions?

Thanks.

Cougmeister

They don't work because I forgot that the RC5 protocol uses the second bit to denote commands>63.

Try these instead:

Device Code: 28 Function: 123
0000 0073 0000 000B 0040 0020 0020 0040 0020 0020 0020 0020 0040 0020 0020 0040 0020 0020 0020 0020 0040 0040 0020 0020 0020 0CA4

Device Code: 28 Function: 124
0000 0073 0000 000B 0040 0020 0020 0040 0020 0020 0020 0020 0040 0020 0020 0040 0020 0020 0020 0020 0020 0020 0040 0020 0020 0CC4

BTW, the frequency difference is trivial and the repeat value is out of the database format and doesn't apply in this case. It is the number of burst pairs that repeat. That changes in the learned version of RC5 from command to command because it is bi-phase.

-Jon

Jon,

Thank you again. You are just about the only resource I have to solve this problem.

I tried the new codes... no response.

Any other suggestions?

I tried the IR from the Arcam remote, it worked. I tried a learned IR with the T2 to the IRF6 by way of the RF, it worked.

RC5 codes have not.

Cougmeister

Cougmeister,

My first mistake was sort of a forgivable error since it was sort of technical. The second was me puting in device 28 vice 25 -- DUH!

Try these ...

Device Code: 25 Function: 123

0000 0073 0000 000B 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0020 0020 0020 0020 0020 0020 0040 0040 0020 0020 0020 0CA4

Device Code: 25 Function: 124

0000 0073 0000 000B 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0020 0CC4

As you probably know these are straight from the manufacturer and can be found in the link IR Codes for DV-88 [Link: arcam.co.uk]

You can create the other commands in Pronto Hex with John Fine's MakeHex found here in Files|Pronto|utilites but you need to use the file below instead of the one included in order to do commands > 63. Name it rc5.irp and put it in a directory with MakeHex.exe.

Just copy everything (between but NOT including the asterisks) into Notepad and save as, pick all files, otherwise it will append a .txt


************************************************
Device=25
Function=123..124

Protocol=RC5
Frequency=36000
Time Base=889 '888.89 = 32 cycles at 36Khz
Message Time=113778 '128 times TimeBase of 888.89
Zero=1,-1
One=-1,1
First Bit=MSB
Form=;1:1,~C:1,T:1,D:5,E:6

Define=C as F(6..6)
Define=E as F(0..5)

*****************************************************

Sorry about all the confusion,

-Jon

Jon,

Worked!!! Thank you so much...errors excluded... It was such a long time for this resolution and should be the last of the difficult components left to control.

I have been setting up libraries one at a time for different components, and the DV27 was the most difficult because it variably responded with just learned IR. RC5 direct wired seemed the only way to go.

I am not quite sure I fully understand John Fine's MakeHex. It seems to be DOS based and may need some additional characters. I will work on this next.

I had been to the Arcam site many times, but did not look at the 88 thinking it was a different unit from the AV27...this is what I get for thinking too much.

Thank you again.

Cougmeister.

Glad it worked at last!

MakeHex doesn't have a GUI, but it works in all versions of Windows that I have. If you create the file above and save it in the directory where you unzipped MakeHex. Then drag rc5.irp onto MakexHex.exe and release. It will instantaneously create a text file rc5.hex that will have the commands. You need only vary the line:

Function=123..124

To get all commands:

Function=0..127

To get only 63:

Function=63..63

It is probably easier to get all 128 commands (0..127) at one time and find them in rc5.hex and copy into the T2 editor program where it converts pronto hex.

-Jon

Jon,

These are examples of codes I get above 63. I am not sure they are correct, but I have not yet tried them.

Thanks again for your help.

Cougmeister

Device Code: 25 Function: 63
0000 0073 0000 000C 0020 0020 0040 0040 0020 0020 0040 0020 0020 0040 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0CA4
Device Code: 25 Function: 64
0000 0073 0000 000B 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0040 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0CC4
Device Code: 25 Function: 65
0000 0073 0000 000B 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0040 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0CA4
Device Code: 25 Function: 66
0000 0073 0000 000A 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0040 0020 0020 0020 0020 0020 0020 0040 0040 0CC4
Device Code: 25 Function: 67
0000 0073 0000 000B 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0040 0020 0020 0020 0020 0020 0020 0040 0020 0020 0020 0CA4
Device Code: 25 Function: 68
0000 0073 0000 000A 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0040 0020 0020 0020 0020 0040 0040 0020 0020 0CC4
Device Code: 25 Function: 69
0000 0073 0000 000A 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0040 0020 0020 0020 0020 0040 0040 0040 0020 0CA4
Device Code: 25 Function: 70
0000 0073 0000 000A 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0040 0020 0020 0020 0020 0040 0020 0020 0040 0CC4
Device Code: 25 Function: 71
0000 0073 0000 000B 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0040 0020 0020 0020 0020 0040 0020 0020 0020 0020 0020 0CA4

I spot-checked them and they look good. I had fixed the limitation in the rc5.irp file that comes with MakeHex WRT commands >63 (that I posted above and it looks like you used it correctly).

BTW, MakeHex is a very powerful tool for generating Pronto hex since it uses external irp files to define the protocol. That way you are not limited to the protocols that John Fine had decoded three years ago when he wrote MakeHex and the irp library that is included.

John recently wrote a DecodeIR.dll that works with versions of:

ccf2efc.exe - decodes Pronto ccf files
cml2efc.exe - decodes T2 files
IRTool.exe - decodes Pronto hex (directly from the discrete code section)
IR_decodeIR.exe - a program that reads the EEPROM in One For All remotes that have the JP1 connector and decodes learned commands.

I used the special version of IRTool to spot check your results.

So you could learn an unknown command save it as a cml file and figure out Protocol, Device and command if it is in DecodeIR.dll decoding repertoire that is pretty extensive. You could generate all available commands with MakeHex, if you know the protocol and can find or build an irp file.

-Jon

JOn,

Thanks again. I tried these last night...and almost all did not work!!! I was very frustrated. Then, this morning I tried them again to determine if maybe there was something in a button press that caused it to malfunction...almost ALL WROKED!!!

There are some functions not listed by the manufacturer that are important. Are you suggestiong that I could create these functions? Would be good if I could. They list only 45 total RC5 codes, and there are several I would like to have that are not listed.

The other issue is the repeat of the same button press. When, for example, the up arrow is depressed twice in a row it doesn't believe it was depressed twice rapidly, but rather once slowly. Could I drop the hex in twice, two different names...like "arrow up" and "arrow up1" and then toggle between the two in a macro? It is suggested by RTI to learn the codes twice for this situation, so it seems that adding the hex twice might correct the problem.

Thanks again for all your help.

Cougmeister

Cougmeister,

As you suspect the problem stems from IR protocols like RC5 that have a toggle bit. This bit alternates with every button press in the OEM remote. So sending two successive button presses of the SAME button will not be seen by the IR receiver in your equipment as a new command. This should not be a problem with two different buttons. 111 is a problem (all it thinks it sees is 1) but 121 should work fine.

The easiest way to solve the toggle bit problem is to generate one set of codes with the "default" rc5.irp file and make a second irp file, rc5-1.irp and add this statement:

Define=T as 1

Then you will have both sets of codes. Back to the example of selecting channel 111. That would take a 1 from the "default" or Zero case, then a One from T=1, and a 1 from the Zero case.

When you test all 128 commands you probably will find plenty that do nothing. You can execute a "nothing" command between legitimate commands as long as timing isn't important. That should reset the toggle bit.

AFAIK, the only reason you need to use two sets of codes would be to do a macro with two successive button pushes of the SAME key but it is possible that your gear works differently than most. So it might record the last toggle state of EVERY command. If so all multiple commands would need to be done like 111.

Also, most IR receivers only keep the toggle state of the prior command for a few seconds.

So, yes you should be able to do a macro for keys that you want to repeat by holding down by alternating the toggle states. However, I always thought keys like Vol+/- were exempted from the toggle bit logic.

If you do need that macro, you will probably need to experiment with timing between those commands. If too short of an interval, then the Volume or channel may move too fast.

If the T2's editor doesn't allow for programming variable delays, you could tinker with the protocol file (rc5.irp or rc5-1.irp).

Message Time=113778 means that the total IR command will be 113,778 uSec or millionths of a second so changing that value to 213,778 would add a tenth of a second more between commands.

It is also possible that the macro takes too long to execute. So you also might have to shorten the interval if you want quicker response.

BTW, the '128 times TimeBase of 888.89 is a comment and make hex ignores anything with a " ' " in front. So if you start editing this a lot to vary the timing you can erase that whole comment lest that important " ' " get lost and the program bomb.

-Jon

Jon,

Overall, things are working well. I spent a lot of time gettin the Arcam DV27 working, and it is now reliable.

I started working on macros for more global operations like "watch projector movie". Only rarely did all operations work. I had to send some RS232 commands 2-3 times, some commands would not work after a short pause, etc. With some fine tuning and multiple repeats of commands in a macro, I have things relatively consistent. It seems that tinkering with the macros is a very important aspect of how well they will work. The individual commands work well.

I wonder if there are some rules of placement of commands in a macro, or if this is just "do it and see what works"...then change it until it works the best?

Thanks again for all your help.

Cougmeister