DecodeIR successor

[Barf]

From this thread:

Clearly the decode of RCA(old) is erroneous. I took a quick look at DecodeIR.cpp and from what I can see, if a protocol is recognized as gap with 24 bits, and hasn't been identified as some other protocol, it defaults to RCA. In this case the leadin more closely resembles RCA(old), so that's what DecodeIR calls it.

In truth I've never understood how DecodeIR works, especially the routine that decode gap type signals. I understand/remember even less now. I've handled the 2.42 through 2.45 versions of DecodeIR, but I am no longer willing to work on it, partly because it is pretty difficult and partly because I am close to providing a public version of a Java program which decodes IR signals using a single decoding engine which takes descriptions of IR protocols from an ASCII file. For me, it is much easier to understand, and should allow anybody to add protocols. However, it is not a direct plug-in replacement for DecodeIR.

Very interesting. DecodeIR is definitely a dead end; for many different reasons.

Actually, I am also working along these lines.
I am working on a program, tentatively called IrpTransmogrifier, that will among other things. do something like this. Project page and sources at Github. It is reasonably well described there, let me just stress that there is one data base, basically an XML version of IrpProtocols.ini that is used both for rendering and decoding. There can also be a number of other parameters, for example for decoding, in that file.

Feedback and cooperation welcome.

[Barf]

The first release of IrpTransmogrifier, version 0.2.0, is available here. This is (at least presently) a command line program only. Documentation.

[The Robman]

Hi Bengt, could you post an example of how to call this, I've tried piecing together a command line entry in a bat file from the readme doc but I'm not quite getting it.

Here's what I tried:

irptransmogrifier decode "0000 006C 0024 0002 0159 00AD 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 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 0041 0015 0016 0015 0016 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0016 0015 06C0 0159 0057 0015 0E81 0159 0057 0015 0E81" > output.txt

[Barf]

Hi Rob,

I will try to make a Youtube video; I think that I can explain things more efficiently that way. Anyhow, I uploaded a few bat files as examples; double clickable.

Here's what I tried:

irptransmogrifier decode "0000 006C 0024 0002 0159 00AD 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 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 0041 0015 0016 0015 0016 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0016 0015 06C0 0159 0057 0015 0E81 0159 0057 0015 0E81" > output.txt

Actually, it is without the double quotes (I will see if I can make it grok them anyhow). But if you remove them, you will still get -- nothing. This is not an error but means that no decode has been found. In the strict sense, this is correct: the signal is a NEC1 with one copy of the repeat-ditto tucked onto the intro, and there is no known protocol that looks like that. I am not saying this is the ideal behavior of a decoder. Instead, the use case of loose matching, "guessing", I have simply not yet implemented. I know that DecodeIR, and also Dave's teaser presently do a better job here. It is planned.

[The Robman]

Hi Bengt, thanks, that worked. So, for the decode option, how many different types of input can it handle? Obviously, you supplied pronto hex as an example and that works, and I also tried it with the raw timing data from IR.exe and it worked, though I got a message about it defaulting the frequency to 38khz, so I figured out how to add the frequency and got that to work. I added a times example to your zip.

I tried raw UEI code and it couldn't handle that, which I expected. So, can it decode anything else, apart from Pronto hex and raw times?

[Barf]

Hi Rob,

I am very happy to hear that get along with the Transmogrifier. As you suspect, only raw (the signs are optional) and Pronto are accepted on input. I do not plan to support other formats either. The reason is that the Transmogrifier is essentially a library, with a possibility to call it from the command line. Integrated in e.g. IrScrutinizer, the interpretation of the other formats, like UEI learned, will take place there. (Recall: Graham's ExchangeIR, both the original version and my Java translation, does this, to my knowledge, flawlessly.)

Regardless of this, if you have a good suggestion, let's hear. Possibly writing a "uei2pronto" program and pipe-ing two programs something like

Code: Select all

 uei2pronto 00 00 2F 00 D0 06 11 8E 08 CD 01 16 01 16 01 16 03 4F 01 16 57 EF 11 8E 04 6D 01 16 BC F2 22 01 11 11 11 21 22 11 21 11 11 21 11 22 22 12 22 13 82 45 | irptransmogrifier decode --input -

[mathdon]

There is no longer just one UEI Learned format. We already know of four, or possibly five depending on just what one considers to be a difference. RMIR can handle all of them, convert between them and convert any of them to Pronto.

[Barf]

Graham,

interesting. The conclusion I draw is that "UEI learned" should be considered as an internal UEI format, and it makes sense to leave conversions to and from UEI learned to RMIR. Differently put, support for UEI learned in other programs is not needed or even meaningful. Thoughts?

[mathdon]

The conclusion I draw is that "UEI learned" should be considered as an internal UEI format, and it makes sense to leave conversions to and from UEI learned to RMIR. Differently put, support for UEI learned in other programs is not needed or even meaningful. Thoughts?

I agree entirely.