NECx1 Decoding difference - DecodeIR vs IRTransmogrifier

[jmezz13]

I've been doing some testing with the NECx1 protocol as documented in my other thread on the LG Soundbar. The bottom line is that the signals I see generated do not formally comply with the IRP Notation for this protocol.

The IRP for NECx1 is (38.0k,564}<1,-1|1,-3>(8,-8,D:8,S:8,F:8,~F8,1,^108m,(8,-8,D:1,1,^108m)*)

The discrepancy is in the D:1 in the repeating section. Given a device number of 44, D:1 should be 0, but in every remote I've tried, the signal always includes a logical "1" signal. I'm using the standard NECx1 protocol in the device upgrade for my testing. Interestingly, IRScope(DecodeIR) identifies the signal as NECx1. IRScrutinizer(IRTransmogrifier) does not identify it as any known protocol I assume because it does not match the specified protocol exactly. Also, DecodeIR decodes this signal with the 0 (that complies with the IRP above) as NECx. It should be noted that the LG Soundbar responds to the signals with either a 0 or 1 in that location.

So, it appears there is a difference in the way DecodeIR and IRTransmogrifier decode the signal. Are we sure the D:1 is the correct specification for this protocol?

[mathdon]

The short answer to your question is that yes, we are sure about the D:1.

Here is the long answer, saying why we are sure. Protocols (strictly, executors) for the MAXQ processor are sufficiently well structured that for many of them it is possible to automate creation of an IRP from the executor code. I have a program that does this, and for NECx1 it gives an IRP of

{38.0k,566}<1,-3|1,-1>(8,-8,B:8,C:8,X:8,~X:8,1,^108m,(8,-8,~B:1,1,^108m)*)

in which A,B,C are the fixed data bytes with bit order reversed, X is the variable byte again bit-reversed.

For this executor, the first fixed byte is just a set of flags that determines which of the NEC protocols is being generated. The IRP I have given is that corresponding to NECx1, so A does not appear explicitly in the IRP. The second and third fixed bytes are complements of the Device and Subdevice values, the variable byte is the complement of the OBC. The BitSpec entries are reversed from your IRP as B, C, X are complements. You will see that the ditto frame indeed has ~B:1, corresponding to ~D:1 in your IRP.

Edit:The original version I gave for the IRP had the first frame sent twice. The executor has a flag that determines whether the first frame is sent once or twice and I picked that form without noticing this. The NEC005ATranslator used by RMIR only allows this flag to be set for NEC1, not NECx1, so NECx1 has the first frame sent only once. I have amended the above IRP, and my description, accordingly.

[Barf]

If desirable, it is possible to define a relaxed version of the NECx1 for IrpTransmogrifier, accepting any value for the bit in the repeat.

[jmezz13]

You will see that the ditto frame indeed has ~B:1, corresponding to ~D:1 in your IRP.

Isn't it D:1 in protocols.ini for NECx1 and not ~D:1? In my testing with different device codes, I think ~D:1 is what is happening which seems to be what you're saying as well(?)

[mathdon]

Isn't it D:1 in protocols.ini for NECx1 and not ~D:1? In my testing with different device codes, I think ~D:1 is what is happening which seems to be what you're saying as well(?)

You are, of course, correct. Because I thought you were questioning the presence of a D:1 term and there really is one, I somehow missed the missing complement sign in what IrpTransmogrifier uses, which I think was taken from DecodeIR documentation that is also wrong. This needs to be fixed. There may also be other instances of this error, but I am not aware of one in protocols.ini. Where are you seeing that?

[jmezz13]

I should have been more clear that I was referring to the complement issue.

I see the IRP for NECx1 without the complemented D:1 in the following locations (if that's what you were asking):

RMProtocols.html (RMIR folder)
DecodeIR.html (IRScope folder)
IrpProtocols.xml (IRScrutinizer folder)

[The Robman]

It's also here, which I can fix:
http://www.hifi-remote.com/johnsfine/De ... html#NECx1

[mathdon]

I think DecodeIR.html is the original source of the error, which was copied into IrpProtocols.xml for IrpTransmogrifier and RMProtocols.html is generated from IrpProtocols.xml. I think that probably is the limit, as the NECx1 executors for the various processors are of UEI origin so will not be affected by errors of ours.

[The Robman]

I fixed it here:
http://www.hifi-remote.com/johnsfine/De ... html#NECx1

And I fixed DecodeIR.html in the IRScope zip:
http://www.hifi-remote.com/forums/dload ... e_id=26615

Not sure if DecodeIR.dll also needs to be changed?

[mathdon]

Here are replacement rmProtocols.xml and RMProtocols.html files for the installation folder of RMIR 2.14.15 or later:

http://www.hifi-remote.com/forums/dload ... e_id=26678

They include the IRP fix for NECx1 and NECx1-f16 protocols and also the Pioneer-2Part protocol included in an earlier replacement rmProtocols.xml dated 2023-03-01. This time I include also a new RMProtocols.html documentation file with corresponding updates. Note that rmProtocols.xml is a patch file automatically applied in RMIR to the IrpProtocols.xml file of the included IrpTransmogrifier, so that this should fix the decoding of learned NECx1 signals by RMIR.

Rob, I do not think that DecodeIR.dll needs to be changed, as it does "fuzzy decoding", essentially just enough to distinguish one protocol from the others that it supports, so it does not need to test the bit concerned. IrpTransmogrifier, on the contrary, tests precise agreement with the IRP, allowing for a certain latitude in frequency and timing but not in bit values.