IrpTransmogrifier: new program/library for IRP protocols

Barf · Post by **Barf** » Thu Sep 12, 2019 12:50 am

No problem; you made me find a nasty bug in the development version, that I would not have found (so quickly) otherwise.

Is there a way that the command line can also be made to use this file?

It is the --configfile option. I will check in new versions of irptransmogrifier.bat and irptransmogrifier.sh, hope that is OK.

In the longer time span I plan to merge you changes. In the short time span, using separate versions is likely better. I would suggest that you update the version "number" of if (it is the version attribute of the top level element) to anything unique, for example with a suffix -rm or such. That version number is (at least presently) only used by humans.

Post by **mathdon** » Fri Sep 13, 2019 6:35 am

Barf, I have found that there are problems caused by changing the default frequency tolerance to 1000 to handle the Pioneer issue. Although it is OK for my test file 1, most of the signals in test file 2 give no decode.

I have found an alternative fix and want to run it past you. I looked at DecodeIR and see that it distinguishes Pioneer by a frequency in the range 39700 to 41000. I have mimicked this (fairly closely) in IrpDatabase by changing the Pioneer frequency from 40k to 40.3k, setting its frequency tolerance to 700 and as prefer over NEC2. I've done the same to Pioneer-Mix and have also commented out all the "prefer over Pioneer" elements in the various NEC protocols.

This works. My test Pioneer signal decodes as Pioneer and the test file 2 signals decode as expected. Is this a reasonable fix?

Barf · Post by **Barf** » Fri Sep 13, 2019 7:47 am

I do not think that 1000 is a good default. Users measured signals tend to be pretty imprecise. Many live in a 38k world (Lirc mostly, IRremote,...).

Please consider also to reduce the frequency tolerance in the NEC protocols.

I do not like the idea of changing a known, correct value to a value that is known to be incorrect to achieve something else. (This is also used for rendering.) Too much like changing the value of pi... As a last resort, we can introduce a lower (and a higher) frequency tolerance, but only if it is really important.

Having the Pioneer protocols prefer-over-ed the NECs is sensible, since it is (sort-of) more specialized.

Post by **The Robman** » Fri Sep 13, 2019 8:44 am

When trying to differentiate between Pioneer and NEC2, you could consider that Pioneer only uses the following device codes: 162, 163, 164, 165, 168, 170 and 175 (and the sub-device is always the complement of the device).

Checking the JP1 upgrades, I found one file that uses NEC1 with device code 165, and I found a few UEI setup codes that uses some of those setup codes, but again with NEC1, not NEC2.

VCR/0758 = 163
VCR/1226 = 165
TV/0090 = 170
VCR/0225 = 170

I'm not suggesting that you add any hard rules here, but when a tie-breaker is needed, this might help.

Post by **mathdon** » Fri Sep 13, 2019 8:55 am

Barf wrote:I do not like the idea of changing a known, correct value to a value that is known to be incorrect to achieve something else. (This is also used for rendering.) Too much like changing the value of pi... As a last resort, we can introduce a lower (and a higher) frequency tolerance, but only if it is really important.

I agree with you that I do not like changing the correct value, but I would like to set the same frequency limits as DecodeIR. DecodeIR has been used for a long time so its decodes have had a pretty good testing. IrpTransmogrifier has probably never been used yet to decode a genuinely learned Pioneer signal, as opposed to one created by IrpTransmogrifier itself. So I would feel more confident about the ability of IrpTransmogrifier to decode real learned Pioneer signals if it mimicked the frequency discrimination of DecodeIR.

So what I am saying is that I really would like to have separate tolerances for the lower and upper limits of the frequency range and yes, to me it is really important.

Barf · Post by **Barf** » Fri Sep 13, 2019 9:37 am

@Graham:
Ok, I accept your argument. See issue. Planned for 1.2.0, not 1.1.1 (which will be out next few days).

@Rob:

... the sub-device is always the complement of the device

This can be taken into account by changing the IRP from {40k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m)*[D:0..255,S:0..255=255-D,F:0..255] to
{40k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m)*{S=255-D}[D:0..255,F:0..255].

you could consider that Pioneer only uses the following device codes: 162, 163, 164, 165, 168, 170 and 175

Cannot do exactly that (recall, in IrpTransmogrifier everything decision is governed by the configuration file, no decisions in Java code permitted), but what can be done is (combining with previous) {40k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m)*{S=255-D}[D:162..175,F:0..255]. Would this be desirable?

Post by **The Robman** » Fri Sep 13, 2019 2:43 pm

Why use D:8,S:8{S=255-D}, isn't this normally notated as D:8,~D:8 ?

I only pointed out the sub-device part (or lack of a sub-device) to show that Pioneer needn't clash with NEC signals which have a sub-device (ie, one that isn't ~D).

Pioneer doesn't use all the device codes in the range 162..175, some of the other codes are used for NEC signals. But none the less, if this would help steer the program in the right direction, maybe it would help, not sure.

Barf · Post by **Barf** » Sat Sep 14, 2019 2:59 am

Thinking about it, I really dislike restricting the domain of D like [D:162..175,F:0..255]. How about instead having a predicate in prefer-over, that specifies that the prefer-over should only take effect if the predicate is true, like

Code: Select all

<irp:parameter name="prefer-over">D==162 || D==163 || D==164 || D== 165 || D==168 || D==170 || D==175 ; NEC2</irp:parameter>

(meaning that a decode as Pioneer should be preferred over NEC2 if the D is as described. Comments?

Post by **mathdon** » Sat Sep 14, 2019 8:08 am

This might help for learns where the frequency is not well learned. I presume this is new syntax and it would give flexibility that may be useful again in future. So on the whole I would support it. I too don't like restricting the domain of D.

Post by **The Robman** » Sat Sep 14, 2019 8:51 am

I agree, I don't like restricting D, but as a "preferred" tie-breaker I think it's good.

Post by **mathdon** » Sat Sep 14, 2019 11:43 am

Barf wrote:
mathdon wrote:This is just a comment made as I am working through IrpProtocols.xml. You have a protocol called Ortek whose IRP shows it to be NEC-like. Protocols.ini has an executor called Ortek (Official) that sends signals that are nothing like NEC. They are instead similar to OrtekMCE, both having an IRP that begins roughly
Code: Select all
{39.0k,490}<-1,1|1,-1>(4,-1,
with the values in braces differing only slightly between Ortek (Official) and OrtekMCE. Where did your Ortek IRP come from? Could it possibly be Onkyo, which protocols.ini says is NEC-like but for which I have no further details?
As written in the documentation string, that protocol comes from this thread. The IRP form is the one given in 3FG's post from Dec 06, 2013. I have no personal experience with it, nor preferences. I will be happy to accept any sensible changes.

I've only just got round to looking up 3FG's post and I think you have misread it. It says that we used to use PID=01ED for OrtekMCE but that PID is now used by UEI for a completely different protocol, and the IRP you have given as Ortek is the one 3FG gives for that different protocol. It appears we have not identified what that protocol is, so I suggest you delete your Ortek entry as whatever it is, it isn't Ortek.

Post by **The Robman** » Sat Sep 14, 2019 12:00 pm

The official Ortek PID is PID=021B

Post by **mathdon** » Sat Sep 14, 2019 12:08 pm

Barf, in the context of DirecTV, you wrote

Parameterizing the leadout is "in principle" easy, but in practice a hairy thing: The capturing device only detects how long no activity has been registered, not how long the leadout is supposed to be. Users always tend to complain like "why does this signal not decode as xxx". For these reasons, IrpTransmogrifier considers all trailing durations > minLeadout (which is a user settable parameter) to be acceptable as leadout.

If I am reading your source code correctly, the default minimum leadout is 20ms. I see from protocols.ini that the two values used by DirecTV are 9ms and 30ms, so with your default, the longer one would be decoded and the shorter one would not. Is the default minimum leadout something like the default frequency tolerance that can be set globally but overridden by an XML parameter in the protocol entry? If so, that could be used to distinguish the two cases, with the protocol with the shorter leadout being set as prefer-over the longer one. Is this possible?

Barf · Post by **Barf** » Sun Sep 15, 2019 12:33 pm

IrpTransmogrifier Version 1.1.1 has been released!

Code: Select all

Release Notes for IrpTransmogrifier 1.1.1.

The notation #n refers to issues number n at
https://github.com/bengtmartensson/IrpTransmogrifier/issues

===============================================================================
2019-09-15: Version 1.1.1

Open issue: Protocol G.I.4DTV partially broken, see #126.

* --ignoreLeadingGarbage now forces IrSequence decoding.
* Improved logging of prefer-over removal of decodes (loglevel FINE).
* Bugfix: User parameters sometimes did not take effect (after #121). #131.
* IrpProtocols.xml: Prefer NEC2 over NEC, and prefer NEC1 over NEC1-rnc.
* For decoding of IrSignals, remove prefer-overs transitively. #130.
* Fixed definition of F12. Resolves #129.
* New render option --decode.
* Handle XHTML in element irp:documentation sensibly. Resolves #125.
* Allow XML in irp:parameter element. Resolves #124.
* Refusal to render decode-only protocols implemented. Resolves #123.
* New decode option --ignoreLeadingGarbage. #122.
* New decode option --override. #121.
* New common option --blacklist. #120.
* Refactoring some decoding stuff. Dramatic speedup on --recursive.

(Graham & Rob: I will answer your issues shortly.)

Barf · Post by **Barf** » Sun Sep 15, 2019 1:35 pm

Predicates in prefer-overs, hopefully implemented in 1.2.0.

I've only just got round to looking up 3FG's post and I think you have misread it. It says that we used to use PID=01ED for OrtekMCE but that PID is now used by UEI for a completely different protocol, and the IRP you have given as Ortek is the one 3FG gives for that different protocol. It appears we have not identified what that protocol is, so I suggest you delete your Ortek entry as whatever it is, it isn't Ortek.

OK, so I am open to any suggestion what to call it. "NotOrtek"?

mathdon wrote:Barf, in the context of DirecTV, you wrote
Parameterizing the leadout is "in principle" easy, but in practice a hairy thing: The capturing device only detects how long no activity has been registered, not how long the leadout is supposed to be. Users always tend to complain like "why does this signal not decode as xxx". For these reasons, IrpTransmogrifier considers all trailing durations > minLeadout (which is a user settable parameter) to be acceptable as leadout.
If I am reading your source code correctly, the default minimum leadout is 20ms. I see from protocols.ini that the two values used by DirecTV are 9ms and 30ms, so with your default, the longer one would be decoded and the shorter one would not. Is the default minimum leadout something like the default frequency tolerance that can be set globally but overridden by an XML parameter in the protocol entry?

yes.

If so, that could be used to distinguish the two cases, with the protocol with the shorter leadout being set as prefer-over the longer one. Is this possible?

(You probably mean the other way around, since matching the longer implies matching the shorter.) In principle do-able, but I doubt that it will work "in practice"; the only way to really determine the intended lead-out it to send the signal immediately followed by something else.