To look for the discrete IR code, I want to edit ConfigEdit.xml by the script.

However, the code expression in ConfigEdit.xml and the code expression in ProntoEdit are different.

For instance,

in ProntoEdit
900A 006D 0000 0001 18E6 00FF

in ConfigEdit.xml
<IRCODE>
<BASICIRCODE>
<Duration>
<WhilePressed />
</Duration>
<Code>58 0 f 6c 5 60 ab 16 15 40 ab 55 3f 7f f0 b 31 10 10 10 20 20 10 10 10 10 20 20 10 10 20 20 20 10 10 10 10 10 10 10 10 20 20 20 20 20 20 20 20 0 bf 49 f0 a bf 10 4 f0 d</Code>
<Label id="102" />
</BASICIRCODE>
</IRCODE>


Will you know the method of converting the code expression in ProntoEdit into the code expression in ConfigEdit.xml?

The is NEC1 protocol. It is device 24 (18 hex) subdevice 230 (E6 hex) and command 0.


The header part of that is complicated to decode and more complicated to encode. But since you have learned samples already, you can keep the header and tail parts of the signal and just tweak the data part.

58 0 f 6c 5 60 ab 16 15 40 ab 55 3f 7f f0 b 31
Thats the header
10 10 10 20 20 10 10 10
That's the device number (18 hex) in reversed binary
10 20 20 10 10 20 20 20
Thats the subdevice (E6 hex) in reversed binary

10 10 10 10 10 10 10 10
That's the command number 0 in reverse binary
20 20 20 20 20 20 20 20
That's the command number complement (FF) in reverse binary.

0 bf 49 f0 a bf 10 4 f0 d
That is lead-out and repeat data.

To convert another one from 900A format to that XML format, get the command (left two hex digits of the last 4-digit hex number). Convert from hex to binary and reverse the sequence and use "10" for each 0 bit and "20" for each 1 bit. Put that in place of the command part of the XML. Make the command complement by using a 20 everwhere the command is 10 and a 10 everywhere the command is 20.

Leave everthing other than command and command complement unchanged.

Thank you for your reply.

I examined the decipherment of the NEC format etc. by material on the following pages.
[Link: home.tiscali.nl]

The method of processing the output data might be one method.
However, I want to convert it directly without never outputting it if possible.
It is because it wants to automate not only 900a format but also the output of other formats.

Header: 58 0 f 6c 5 60 ab 16 15 40 ab 55 3f 7f f0 b 31
Lead-Out: 0 bf 49 f0 a bf 10 4 f0 d

Will you know more detailed information about these?


900A 006D 0000 0001 18E6 00FF

This can be converted into 0000 formats as follows.

0000 006D 0022 0002
0157 00AB
0016 0015 0016 0015 0016 0015 0016 0040 0016 0040 0016 0015 0016 0015 0016 0015
0016 0015 0016 0040 0016 0040 0016 0015 0016 0015 0016 0040 0016 0040 0016 0040
0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015
0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040
0016 05E7
0157 0055 0016 0E3B

Here,

0016 0015 => 10
0016 0040 => 20

I think data part to be converted like the above-mentioned as you pointed it out.
However, how the rivet and bolt header part, Lead-In, and Lead-Out, etc. are converted is not understood.

Header: 58 0 f 6c 5 60 ab [16 15 40 ab] 55 3f 7f f0 b 31

I think that the above-mentioned part is a table.
"10" and "20" etc. I think that it refers from this table to two data.

However, Lead-In and Lead-Out cannot be found by this method.
Moreover, information that hits frequency ("006D") seems not to exist either.

Thank, you.

I think this format to look like the one of ProntoNeo.
The document concerning the format of ProntoNeo was in the following places.

[Link: remotecentral.com]

However, there are still a lot of points that do not understand either.
I will take time and examine it a little more.


58 0 f 6c
5 # of duration variations
60 Carrier frequency divisor. 3672600/0x60 = 96 = 38256.25Hz
4.145146/0x6d = 109 = 0.0380288MHz = 38028.8Hz
ab Lead Out duration
16 Variation 00
15 Variation 01
40 Variation 10
ab Variation 11 (?)
55 Variation 100 (?)
3f [0011.1111]
7f [0111.1111] Preamble End. 11 1111 0111 1111
f0 [1111.0000] Repeat Cue
0b [0000.1011]
31 IR Sequence? (0016 00ab?)
10 10 10 20 20 10 10 10 IR Sequence
10 20 20 10 10 20 20 20
10 10 10 10 10 10 10 10
20 20 20 20 20 20 20 20
0
bf [1011.1111] Burst Pair? However, the format is not understood.
49 [0100.1001]
f0 [1111.0000]
0a [0000.1010]
bf [1011.1111]
bf [1011.1111]
10 [0001.0000]
10 [0001.0000]
04 [0000.0004]
f0 [1111.0000]
0d [0000.1101] Sequence End?

The format used internally by the NG models is very similar to the Neo format. But there are significant differences vs. that document. I think some differences are because that document only covers a subset of the format. But maybe there are also real differences between the NG and Neo formats.

I figured out most of the details of NG format at one point, but never wrote much about it and have since forgotten most of it.

I'll assume you're correct about where the number of durations, the carrier value, and the lead out are encoded. Somewhere in there it also tells you the number of bits used to index the table of durations. We can see that 4 bits are being used, but I forget where that is encoded. Often the NG uses 2 bits instead of 4, and I think other numbers are possible.


Since 4 bits are used for each index, those are 0000, 0001, 0010, 0011 and 0100.


Within each byte, the bit fields are taken in reverse sequence. So that is an F followed by a 3. The code of 'F' means something special follows. That is where things get most confusing, interpreting how many bit fields following an F are part of one longer element and what that element is. It's even more confusing when they use just 2 bits per field (making 3 the special value, rather than F).


We know the 3 there represents the AB in the raw format. Since the fields are reversed in each byte, the 3 is in a section of the sequence best viewed as:
... F B 0 1 3 0 1 0 1 0 1 0 2 ...

The 0 1 0 1 0 1 0 2 following the 3 clearly encode the 16 15 16 15 16 15 16 40 of the raw data.
Somehow the items before the 3 encode the 157 of the raw data. They have a strange format for anything larger than 00FF. They don't include it in the table of durations. Instead they have an F, followed by some bits that indicate this is a large value (rather than some other special item) followed by the duration of the large item (I think in units other than the cycles used for ordinary durations). I forget how the B 0 1 encodes all that, but it must.


Again the sequence is really F B 9 4 0 F
The F says something special follows. The B 9 4 0 somehow encodes a really long gap. The next F introduces the next special.


The A is the repeat marker (introduced by the F before it). The 0 has me confused.


That is F B 0 1 4 0, where (as above) the F introduces the B 0 1 to encode 157. Then 4 0 is 55 16.


0 F D 0

0 encodes the 16 (the on part of the last burst).
F introduces special.
D (as a special) marks the end.
The last 0 is just padding.
The Off part of the final burst is never included.

I know all the above will be giberish to most people reading this, but you seem to half understand it already. Feel free to ask about any details that I didn't communicate well enough.

Thank you for a detailed explanation.

Lead-Out: bf 49 f0 a bf 10 4 f0 d

f b 9 4 0 f a 0 f b 0 1 4 0 0 f d 0

The sign was put on this as telled.

[f] (b:long 9 4 0)
-> 05E7
[f] (a:? 0)
-> Repeat Mark?
[f] (b:long 0 1)
-> 0157
4 0
-> 0055 0016
{0:padding?}
[f] (d:last)
{0:padding?}

Former code corresponding to this:

end of once sequence : 05E7
repeat sequence : 0157 0055 0016 0E3B

It seems that it was possible to decipher it almost.
However, there seems to be no part corresponding to 0E3B.

Moreover, I do not understand whether f b * is encoded like any well.

I will encode various codes, and compare it because it obtained a lot of hints.


Thank you very much.

That is the "lead out". Earlier you seemed to already understand that the NG format encodes the lead out in the header rather than encoding it at the end where it logically fits.


Both regular and NG formats encode the wavelength of the carrier, rather than the frequency. So a normal duration can be computed by multiplying the duration number (the 15 or 16 or 40 etc.) by the wavelength and multiplying that by the unit time used to encode wavelengths (which is a different unit between old Prontos vs. NG, but the concept is the same).

But the NG encodes longer values differently. They don't depend on the wavelength. For some of them I think it multiplies the unit time by 256 and multiplies that by the number encoded after the B. That makes the relationship to the value in the Pronto Hex harder to see.

To further confuse things, I think the number of bits after the B varies and the multiplier (that 256) varies. You also should understand that those multiple bit fields need to be rereversed to form a number (the low bit fields come before the high bit fields).

In theory you could paste similar Pronto Hex in a few times varying just the size a one large gap in the middle of the signal and see how the XML changes. (In fact I did that). But that method runs into some PENG bugs and gives incorrect results. To really get the answer you would need to learn from the NG remote to some reliable IR learning system and see the actual gap lengths. I don't own any Pronto (NG or otherwise) so I never did that).

I examined whether other methods existed a little.

In PENG, there is a file named CCF_Translate.dll.

I examined the symbol of DLL because I saw the one that seemed that the translation table of IR code it when it saw in this file in the editor.

As a result, the function that seemed it for conversion was found.

ordinal hint RVA name
1 0 000218B0 CleanupIRCmd
2 1 000217F0 EcoSIF2HEX
3 2 000215B0 Hex2SIF
4 3 0001DBA0 RCS_CCF2XML_V_1_0
5 4 0001DD20 RCS_CCF2XML_V_2_0
6 5 0001DF60 RCS_CCF2XML_V_3_0
7 6 0001E1F0 RCS_GetJobName
8 7 0001E170 RCS_GetLastError
9 8 0001E1E0 RCS_GetProgress
10 9 0001E150 RCS_XML2CCF
11 A 000214E0 RIS_APIVersion
12 B 000212C0 RIS_GetLastError
13 C 00021350 RIS_IR2SIF
14 D 00021310 RIS_IsIRvalid
15 E 00021330 RIS_IsSIFvalid
16 F 00021400 RIS_SIF2IR

When these functions were run after by the debugger, it was able to be confirmed to do the code conversion in this DLL.

If the parameter is passed to these functions, and the method of receiving the result is understood, my purpose seems to be realized.

I will examine it a little more by this method though it is thought that it takes time.



Thank you.

DLL was able to be analyzed.

The program converted from IR code to the code of
which Pronto used with XML was made.
Separately, DLL of ProntoEdit NG is necessary.

Execution example:
>prontoir "900A 006D 0000 0001 18E6 00FF"
58 0 f 6c 5 60 ab 16 15 40 ab 55 3f 7f f0 b 31 10 10 10 20 20 10
10 10 10 20 20 10 10 20 20 20 10 10 10 10 10 10 10 10 20 20 20
20 20 20 20 20 0 bf 49 f0 a bf 10 4 f0 d

I think that it can efficiently analyze it by using
this though it seems to take time.
I will try the analysis of the code when there is time
because it was able to achieve my purpose by this.

Mikage,

Can I get a copy of your source code used to perform the test?

Please Zip and email to me your VC project. Please no PDBs or NCBs. My mailbox only has about 1MB left available.

Thanks,
Lyndel

Oops.

It forgot to fill in URL.
The source code is included in this zip file.
Please use it freely.

[Link: mikage.to]

Thanks.

I wish I had that when I investigated this format earlier. It would have saved much time vs. using PENG and trying to find the results in the XML file.

One thing I failed to invesigate is toggle bits.

If I understand correctly, the RC5 and RC6 Pronto hex (starting 5000 or 6000) work correctly (toggle correctly) in the NG remotes. This means that XML format has some means to represent a toggle bit. I tried your program on some 5000 and 6000 codes with interesting results that I haven't had time to disect yet.

The NG remotes fail to toggle on most (maybe all) 7000 format codes. If the XML format supports a general form for toggle (rather than just specific RC5/RC6 support) then the 7000 problem may be a minor glitch in translation that could be fixed in the XML file.

Similarly the MCE protocol (RC6-6-32) has a toggle that's a big problem for NG remotes, but might have a very robust solution using directly generated XML hex.

Agree!

These "minor glitches" in translations looks so permanent, that it is a reason to develop a precision translator to XML hex... I'm near to decrypt all bits at this avid format :)

Yes, all 7000's I tested looses toggle ability.

John! There an amount of requests for this MCE. Could you say - do those StreamZap remote from [Link: remotecentral.com] the same as MCE or not?

StreamZap is a nonstandard extension of the RC5 protocol. The MCE protocol is a nonstandard extension of the RC6 protocol.

They are not the same protocol.

An MCE does not natively understand the Streamzap protocol.

I understand that someone was able to control his MCE using the Streamzap protocol. I assume that required adding to the MCE hardware and/or software that was purchased with the StreamZap remote.

John! I think, I can generate the 7000-format codes to control MCE at non-standard RC6, in case of the comfortable solution is not exist yet - please, send me a ccf with raw (0000) codes and at least one sample with odd and even codes for any command!