I had a few questions about importing created codes from ProntoEdit to MX-editor.

First off let me describe my system and what I am trying to do.
My Home Theatre system is based on a pc running linux and mythtv. It uses Lirc to read remote control signals. Lirc can make my remote receiver on the pc accept any remote signals I want. Basicly I want to use ProntoEdit to create a custom set of codes to send to my pc. I need like at least 80 codes so I can't use the set found on a normal remote.

I know to create a code in ProntoEdit that MX-editor will accept you use the Advanced button and choose RC6 mode 6A.

First off, what exactly do Customer Code, System, and Command mean? Obviously specifiying different combinations of numbers creates a different code. Is there a certain range of values I should use for this?

Also, my biggest question is, using this method how do I create a command that repeats (ie I hold the button down and the command gets send repeatedly) vs a command that just gets sent once?

Any advice or a link to the info would be much appreciated. Thanks!

That's one way, though I'm not sure which versions of ProntoEdit would produce codes that the MX-editor would accept when using that method. Some versions of ProntoEdit produce condensed codes for RC6 mode 6A. The MX-editor won't understand those.

The MakeHex program gives you far more flexibility to generate pronto hex. You have the choice of many different IR protocols, some of which may be easier to work with in LIRC. Then the output of MakeHex can be put into a CCF file using IrPanels.exe or Hex2CCF.exe, either of which is much easier than using ProntoEdit, especially for as many buttons as you want.


RC6 mode 6a generates an RC6 signal with a 6 in the mode field and either 24 or 32 bits in the main data field.

The main data field is divided into a few sections:

The last eight bits are the command. So that is any number from 0 to 255.
The seven bits before that, I think is "System", but I'm not sure. I might have "System" and "Customer" reversed.
The bit before that, in just some uses of RC6 mode 6A, is a toggle bit.
The first 8 or 16 bits I think are "Customer". I'm not certain of the rules used to decide whether it is 8 or 16, but so far as I recall, the value is always 0 to 127 for 8 bits and always 32768 to 32895 for 16 bits.

A normal device would use a single Customer/System pair for an entire set of IR signals and vary only the command number. You probably should do the same.


RC6 commands always repeat while held, so the Pronto Hex generated by ProntoEdit (or MakeHex) would correctly specify that repeat.

My experience with the universal browser has been that any command imported by it will repeat. If the Pronto Hex specifies repeat, the MX command will repeat correctly. If the Pronto Hex doesn't specy repeat, the MX command will repeat garbage.

Is there any tutorial out there for creating .irp files with makehex? I've played with it a little but can't seem to get a repeating codeset that lirc likes. Whether a code repeats appears to be defined in the .irp file. The readme helps a little bit but doesnt explain how it all works.

Just what is in the readme file. But I think you're better off selecting an existing protocol, rather than creating a new .irp file.


NEC2 is a good choice for what you want. Also, it is a good example for answering your question about repeat. Look at the Form line from NEC2.irp

Form=;*,D:8,S:8,F:8,~F:8,_

Notice the first character after Form= is ;
That indicates the entire signal repeats (vs. part of the signal if the ; were elsewhere or no repeat if there were no ;)

I'm surprised you had trouble with that. Most IR protocols repeat the whole signal, as you can see by looking at the Form lines in most of the irp files.

What test are you doing? What do you mean by "a repeating codeset that lirc likes"? And/or how do you know a given codeset isn't that?

I don't know the programming interface to LIRC, but I think LIRC has some understanding of when a codeset has repeat built-in. So I wouldn't expect it to report continuous iterations of the command. I would expect it to know the first is real and the rest just mean the button is still pressed. Hopefully the interface lets you determine that the button is still pressed.

I'm using irrecord with lirc to learn the remote commands from my MX-950. After doing so, I use irw to test the config file. The commands are not all recoginized
Not sure if all this will help you but here is some info.

nec2.irp
Device=210.109
Function=0..255

Protocol=NEC2 'Like NEC1, but repeats entire pattern
Frequency=38000
Time Base=564
One=1,-3
Zero=1,-1
Prefix=16,-8
Suffix=1,-78
Default S=~D
Form=;*,D:8,S:8,F:8,~F:8,

nec2.hex
Device Code: 210.109 Function: 0
0000 006D 0000 0022 0157 00AC 0015 0016 0015 0041 0015 0016 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0041 0015 0016 0015 0041 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0689
Device Code: 210.109 Function: 1
0000 006D 0000 0022 0157 00AC 0015 0016 0015 0041 0015 0016 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0041 0015 0016 0015 0041 0015 0041 0015 0016 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0689
Device Code: 210.109 Function: 2
0000 006D 0000 0022 0157 00AC 0015 0016 0015 0041 0015 0016 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0041 0015 0016 0015 0041 0015 0041 0015 0016 0015 0016 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0689

If I use the mode2 program with lirc after pressing buttons 0, 1, and 2 gives the following output:
Code 0
code: 0x001fddd7
code: 0x6ecdb24d
code: 0x6dedb7c0
code: 0x07e6d9b7
code: 0x6cd9365e
code: 0x6dedbfff

Code 1
code: 0x001fddd7
code: 0x66dfffff

Code 2
code: 0x001fd9f7
code: 0x66cdb76c
code: 0x66dfdbe0
code: 0x01f7cddb
code: 0x76edb24e
code: 0x76dedfff


After using irrecord, my lircd.conf looks like this:

15 begin remote
16
17 name lircd.conf
18 bits 16
19 eps 30
20 aeps 100
21
22 one 0 0
23 zero 0 0
24 pre_data_bits 16
25 pre_data 0x1F
26 gap 123990
27 min_repeat 2
28 toggle_bit 0
29
30
31 begin codes
32 0 0xDDD7
33 1 0x5DD7
34 2 0xD977
35 end codes
36
37 end remote

I don't know that much about LIRC. I only understand the most common form of lirc files, not the form you quoted.

For discussion, look at this example of an LIRC file for NEC2 protocol:

[Link: lirc.sourceforge.net]

Notice the lines

one 601 528
zero 601 1658

They are backwards. The one is the real zero and the zero is the real one. LIRC usually, but not always, gets that backwards. But the important point is that LIRC has understood one and zero bursts. By contrast, you have:

22 one 0 0
23 zero 0 0

I don't know what that means, and lacking valid one and zero, I don't know what anything else you quoted means.

Back in that Sansui file, notice the LACK of any line saying something like
repeat 9082 2214
Most LIRC files for NEC protocol have some line similar to that, indicating it is NEC1 protocol (the repeat part is just a stub) vs. NEC2 protocol (the repeat part is the entire signal).

Next notice the line
pre_data 0xDE4D

DE is the device number, but LIRC is always most significant bit first, while NEC is least significant bit first, so we need to reverse the bit sequence. Since this LIRC file has one and zero reversed, we also need to reverse the bit polarity.

Reversing both bit sequence and polarity on DE gives you 84. In decimal that is 132.

Similarly the subdevice is 4D, which happens to reverse to itself. In decimal it is 77.

So in MakeHex this would be device 132.77

In each line that look like
1 0x0000000000006F90
the two hex digits (6F here) before the last two are the command number. 6F reverses to 09, which is 9 decimal.

If your LIRC hardware and software can produce files in that general form, I can give you better help to diagnose what is going wrong with your signals.

BTW, here's an NEC2 LIRC example where LIRC didn't get one and zero polarity reversed (of course the bits are still sequence reversed):
[Link: lirc.sourceforge.net]

BTW2, 210.109 (that you used above) is a common Onkyo code set. If you're going to use that for your LIRC, hopefully you don't have any Onkyo devices that will also respond to those signals.
Here's an Onkyo example that is NEC2 with one and zero reversed:
[Link: lirc.sourceforge.net]
If one and zero weren't reversed the predata would be 4BB6
Onkyo normally mixes NEC1 and NEC2 in one code set. LIRC doesn't seem to understand that, so it picks one or the other. Most of the Onkyo lirc files it picked NEC1.

Well currently I'm still looking into this. However I did find this file which describes lircd.conf.
[Link: winlirc.sourceforge.net]

Also in my example file just in case you didnt notice, the numbers in the beginning are just line numbers from vi, so they can be ignored.

Also I looked at mce.irp and noticed that
Form=;6,-2,1:1,M:3,-2,2,128:8,S:8,T:1,D:7,F:8
it starts with a semi colon but when I import it into mx-editor it is still a single shot command and does not repeat.

I hadn't seen that before, and I didn't know about the REVERSE flag. So if that is used, you can handle an LSB protocol, such as NEC without needing to reverse the bits yourself. I wonder why I haven't seen that in real lirc files.

But nothing in that document explains what it means to have "0 0" on the lines defining one and zero.

I looked up irrecord and it says it can use a pre existing file to guide its decisions. You might want to try it again, starting with a valid conf file for NEC2 (probably with the correct pre data). Maybe your IR capture hardware is OK and could record signals correctly if it was guided by an initial file.

What are you using for IR capture hardware? Maybe I can give better advice if I know whatever limits there are to that hardware vs typical lirc IR capture hardware.


I assumed that.


The Pronto Hex generated by that definitely repeats the whole signal. BTW, a Pronto Hex string that repeats the whole signal has 0000 as its third 4-digit value.

I really doubt that the universal browser would get that wrong. I have an MX-850 I could test with, but I don't know when I might have time. How are you determining that the signal does not repeat?

BTW, the mce IR protocol is a subset of RC6 mode 6A with 32 bit data, so mce.irp should generate the same Pronto hex as we discussed at the start of this thread.

What are you using for IR capture hardware?
[Link: thermaltakeusa.com]

I have some other options available to use for ir hardware if I so choose. an ir receiver that comes with the hauppauge pvr 150 tv tuner card, the ir receiver that comes on the frontpanel of the soundblaster audigy 2 ZS sound card, and a usb receiver that came with a gateway computer that uses a windows mce remote.

The mce hex, the third set of numbers is 0000. I know it is sending a single shot command because when I add it to my mx-950 and then press and hold the key, the little icon on the remote lcd that looks like (((o))) only blinks once instead of continuing to blink. Also the mode2 command in lirc only shows one signal has been received.

I don't see any info about the IR sensor there. I do see a remote control. Is there a working lirc file for that remote. Maybe the format of that file will give some hint about any hard wired assumptions in the ir capture part of the system.


I guess I should find time to test that with my MX-850. It doesn't make sense, but I'm not an expert on the MX remotes. I've barely done anything with the 850.

Yes I have used the original remote there with lirc and works great. If I had some way to get its codes on the MX-950 and create some new codes that use the same format, that would be the most optimal solution.

Here is its working lircd.conf file
1 #
2 # this config file was automatically generated
3 # using lirc-0.7.1pre2(imon) on Tue Mar 1 23:15:44 2005
4 #
5 # contributed by Venky Raju
6 #
7 # brand: iMON-New
8 # model no. of remote control: iMON-PAD
9 # devices being controlled by this remote:
10 #
11
12 begin remote
13
14 name iMON-PAD
15 bits 32
16 eps 30
17 aeps 100
18
19 one 0 0
20 zero 0 0
21 gap 235965
22 min_repeat 1
23 toggle_bit 0
24
25
26 begin codes
27 Power 0x289155B7
28 AppExit 0x288195B7
29 Record 0x298115B7
30 Play 0x2A8115B7
31 SlowMotion 0x29B195B7
32 Rewind 0x2A8195B7
33 Pause 0x2A9115B7
34 FastForward 0x2B8115B7
35 PrevChapter 0x2B9115B7
36 Stop 0x2B9715B7
37 NextChapter 0x298195B7
38 Esc 0x2BB715B7
39 Eject 0x299395B7
40 AppLauncher 0x29B715B7
41 MultiMon 0x2AB195B7
42 TaskSwitcher 0x2A9395B7
43 Mute 0x2B9595B7
44 Vol+ 0x28A395B7
45 Vol- 0x28A595B7
46 Ch+ 0x289395B7
47 Ch- 0x288795B7
48 Timer 0x2B8395B7
49 1 0x28B595B7
50 2 0x2BB195B7
51 3 0x28B195B7
52 4 0x2A8595B7
53 5 0x299595B7
54 6 0x2AA595B7
55 7 0x2B9395B7
56 8 0x2A8515B7
57 9 0x2AA115B7
58 0 0x2BA595B7
59 ShiftTab 0x28B515B7
60 Tab 0x29A115B7
61 MyMovie 0x2B8515B7
62 MyMusic 0x299195B7
63 MyPhoto 0x2BA115B7
64 MyTV 0x28A515B7
65 Bookmark 0x288515B7
66 Thumbnail 0x2AB715B7
67 AspectRatio 0x29A595B7
68 FullScreen 0x2AA395B7
69 MyDVD 0x29A295B7
70 Menu 0x2BA385B7
71 Caption 0x298595B7
72 Language 0x2B8595B7
73 MouseKeyboard 0x299115B7
74 SelectSpace 0x2A9315B7
75 MouseMenu 0x28B715B7
76 MouseRightClick 0x688481B7
77 Enter 0x28A195B7
78 MouseLeftClick 0x688301B7
79 WindowsKey 0x2B8195B7
80 Backspace 0x28A115B7
81 Up 0x690281B7
82 Left 0x6A8281B7
83 Right 0x688A81B7
84 Down 0x688291B7
85
86 end codes
87
88 end remote

Actually, can I export a learned code from MX-editor to hex format? If i could do that I could create a working set of codes from my original remote.

I think the IR sensor in your original remote is restricted to a single IR protocol, and has nonstandard rules for the lircd.conf file.

There is no software to export from the MX-editor to Pronto (or other) formats, only import.

I don't know MX-850/950 software very well, but I'm sure there is some format that you can save learned signals from an MX-950 so they can be imported into an MX-850. If you know how to do that, send me an email (see address in profile) with that file.

I have an IR capture device with decode software that will tell me the details of any signal I send to it. So if I had your signals in my MX-850, I could easily determine what they are, and tell you what to use in an IRP file to generate at least a sequential set of 256 different commands and maybe more.

I got the email.

Maybe this evening I'll try to figure out how to import signals from your imonpc.mxa file into my MX-850.

I understand the original remote sends a distinct signal when you release each button (one bit different from the signal sent when you press that button). There is no way to represent that behavior in Pronto Hex, so no way to import it from a CCF file. So far as I know, there is no way to do it at all with an MX-950.

If I understand you correctly, the MX-950 learns only the first frame of this signal. If you do a short press (while learning), the MX-950 ought to learn both frames together as a one shot signal. You implied it doesn't. If you do a long press, the MX-950 ought to learn the first frame as a repeating signal. You said it didn't. I might be able to get some insight into that testing with my MX-850.

Maybe someone more expert in the MX-950 will join this thread and comment on some of these issues.

Actually I was a bit vague, sorry about that. The mx-950 learns the first and second frame as one hex code. When I try to do a long press it doesnt learn the repeating signal properly. (maybe because of the pause that occurs before the original remote starts repeating?)

I tested with my MX-850.

The universal browser wouldn't open the file imonpc.mxa. It gave no error message. It just wouldn't open.

The file wholeremote.mxa opened file and I copied a bunch of signals from the "PC" device to my MX-850 and then captured them with my IR sensor.

It is a very strange protocol that I've never seen before. I have it pretty much figured out. But I'm stopping for the day. I'll try to pick it up again soon.

I'm sure I can get MakeHex to produce repeating Pronto Hex for a large organised subset of this type of signal. Hopefully universal browser can import them correctly.