I saw many posts in this forum about how to insert HEX codes directly into MX-Editor, but i'm asking for opposite operation: how to obtain HEX code from a command learned with MX-Editor?
Is there any tool around that import and manipulate mxf file or something that will do the job?

Bye

None that I've heard of. You can't actually input hex commands directly into MXEditor. You have to input them into a Pronto file, then use the Universal Browser to open the Pronto file.

Mike
www.SurfRemoteControl.com

Suppose I have a remote not listed in MXEditor database and for which no discrete codes are available in ccf format.
But I know IR protocol used by the vendor (Nec1) e know some discrete on/off codes for other devices of the same vendor.
Moreover I know that function number remains the same across different model for a specific function (on and off ). Only device number change between different models.
So, if I could see the hex code of the learned toggle on/off button, i should understand which device number my product uses among the 128 availables e so generate the (hopefully) correct discrete codes.
Make sense? I tried to hex edit a mxd file, but it seems to me that hex codes from learned buttons are not saved in this file in a plain form (some encoding is done).
Hope someone else has other ideas...

Bye

Since you know the IR protocol, have you looked into creating the hex code with the "Make Hex" program? It's downloadable from this site and discussed here.

I partially know the format of mxd files, not nearly enough to know which IR signal goes with which function, nor even enough to recognise every protocol. But I know more than enough to see NEC1 signals within a hex view of an mxd file and to know the device and command numbers of each such signal.

Since you want such a small amount of info from an mxd, you can email it to me and I'll take a quick look and then tell you that device number you're looking for. BTW NEC1 protocol supports more than just 128 device numbers.

Thanks for jumping in as always John. You must have radar for every time "make hex" is mentioned. ;-)

thank you very much John, I really appreciate your interest. I will email you the mxd as soon as possible. But I'd like to understand how is possible to extract hex codes from this files, are there any guide or literature around to learn?

I tried to open the mxd file with a hed editor. Is that the right way to go to extract hex of learned commands?

If you have a rough understanding of mxd files and a great understanding of various ways of representing IR data in hex, then that's the right way. Otherwise you're not going to understand what you see. It isn't stored in anything similar to Pronto Hex, so you need to recogise and translate, not simply "extract".

I didn't get any email of that mxd.

I don't know anything about mxd file format. I think it's a propetary format. How is it possible to learn how IR data are stored in this files?
Sorry for the email, I sent it, probably to wrong address.
Just sent another, hoping this one doesn't get lost in the net again.

I got the email with your mxd file for a "Humax DVB-T receiver, model DTT 4000".

I looked at the IR signal stored at approximately hex address 1540 within that file (which I chose pretty randomly). It looks to me like NEC1 protocol, device 0.48, function 29.

You could use the MakeHex program to generate all 256 possible commands for NEC1 protocol device 0.48 then use IrPanels to convert it to a CCF file, then drag individual functions into the MX editor.

I checked the CCF files I have for Humax. They are NEC1 protocol, device 0.16. They each have a function 29, but I can't tell (from the DecodeCCF output) what that button means in any of those CCFs. Of course I also can't tell which function it is in your mxd file. So I can't guess whether your model has just a different device number or diffierent command numbering as well.

Here is the hex data that I examined (you should be able to find the same sequence of bytes around address 1540 in your hex editor). I put in line breaks to help explain the structure:

58 06
F6 01
56 00
AA 00
57 00
40 00
36 00
17 00
16 00
15 00

26

34
9A 9A 98 A9 99 99 A8 9A
9A 9A 9A 98 96 A6 99 9A
96 9A 96 96 96 9A 9A 9A
98 96 9A 9A 99 96 96 96
92
35 91 35 97

Those first ten pairs of hex bytes represent durations. There aren't always ten, typically there are fewer. Some other part of the data tells how many there are. But I don't recall how that detail works.

Each pair must be read backwards, so 58 06 is a duration of hex 0658.

These pairs are referenced in the next section by numbers 1 through A: 0658 is number 1, 01F6 is number 2, ..., 0015 is number A.

They're supposed to be consolidated unique durations. This example doesn't seem to be consolidated at all. When two durations in a signal are nearly equal, the learning logic is supposed to guess that those durations were truely equal but mismeasured. Note that durations 3 and 5 should have been consolidated as should 8, 9 and A.

The next value (26) is some sort of count. 26 is 38 decimal and there are 38 items in the following section, but I think the count doesn't mean that exactly. There is some method of dividing the following data into the one-time part and the repeating part and I think the 26 is used for that. But this really crappy learn is divided wrong into one-time vs repeating, and I don't recall exactly how it works with a good learn.

The next 38 bytes each represent a burst with the high nibble as the On half and the low nibble as the Off half. Each nibble is an index back to the durations in the first section. So 3 represents a duration of 0056 and 4 represents a duration of 00AA.

That's backwards for an NEC1 lead-in. I'm not sure at the moment whether I've misread the hex or misremembered some detail or the learn is worse than it looks or Humax uses NEC1 strangely, or what. But we were looking for the device number, not for every timing detail, so I think we can safely ignore that problem.

Note the four 8-bit bytes of NEC1 data. In NEC1, a zero bit is Short/Short and a one bit is Short/Long. Note there are three different measurments of "Short", durations 8, 9 and A. So 98, 99, 9A, A8 and any similar combinations I might have missed are all Short/Short and represent a zero bit. 96 is Short/Long and represents a One bit.

Remembeing that NEC1 has bits least significant first in each byte, we get device 0.48, command 29.

Then the 92 is the lead-out at the end of the first NEC1 frame and the last four bytes are a garbled version of the NEC1 repeating frame.

I hope you understand that all the specifics of which index nibble means what depend on the list of durations, which is independently learned for each signal. So you couldn't take that rule of what 96 meant over any another signal even in the same file. You need to decode each signal based on its own table of durations.

Thank you, this is exactly what I was looking for. Your explanation is vey clear. I tried to decode the other humax code you have posted in this forum (device 0.16) following your instructions and obtained the same device and function numbers.

I was wondering: what are those bytes before the list of durations?
1401 7000 0400 0000 6A00 0000 0000 0000 4A00 9E0E
1401 7000 seems to me somthing like a identifier for the start of code
0400 seems a progressive number (0100 for the first code stored, 0200 for the 2nd and so on...)
The others I don't know. 6A00 seems to repeat always the same in every code, while 4A00 and 9E0E have little changes from code to code.

Most of that I never knew, some of it I knew and forgot.

You are making things less clear for yourself by merging pairs of bytes into 4 digit values before understanding what they mean. Some pairs of bytes are 4 digit values but others are independent bytes. When a pair is a 4 digit value it must be reversed. For example you said "0100 for the first ... 0200 for the second" for one pair of bytes. You're probably right that it is a pair, but the correct 4 digit value would be 0001 for the first, 0002 for the second, etc.

One thing I never figured out was how the IR signals in this section are associated with the identifying info in the earlier section of the file. I never noticed that number you called "progressive". Maybe it is an ID for the signal that is used elsewhere in the file to refer to the signal.

One thing I found before but forget now is which of those values represents the modulation frequency.

Did you understand my earlier suggestion to use MakeHex and Irpanels to create clean versions of all 256 possible commands?

Did you try that, and test any of the commands?