|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
jmezz13
Joined: 28 Oct 2004 Posts: 94
|
Posted: Fri Mar 03, 2023 7:54 pm Post subject: NECx1 Decoding difference - DecodeIR vs IRTransmogrifier |
|
|
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? |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Sat Mar 04, 2023 6:52 am Post subject: |
|
|
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. _________________ Graham
Last edited by mathdon on Tue Mar 07, 2023 7:37 am; edited 1 time in total |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1416 Location: Munich, Germany |
Posted: Sat Mar 04, 2023 7:31 am Post subject: |
|
|
If desirable, it is possible to define a relaxed version of the NECx1 for IrpTransmogrifier, accepting any value for the bit in the repeat. |
|
Back to top |
|
|
jmezz13
Joined: 28 Oct 2004 Posts: 94
|
Posted: Sat Mar 04, 2023 1:30 pm Post subject: |
|
|
mathdon wrote: | 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(?) |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Sun Mar 05, 2023 7:05 am Post subject: |
|
|
jmezz13 wrote: | 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? _________________ Graham |
|
Back to top |
|
|
jmezz13
Joined: 28 Oct 2004 Posts: 94
|
Posted: Sun Mar 05, 2023 12:19 pm Post subject: |
|
|
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) |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21246 Location: Chicago, IL |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Sun Mar 05, 2023 12:36 pm Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21246 Location: Chicago, IL |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Mon Mar 06, 2023 1:51 pm Post subject: |
|
|
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.php?action=file&file_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. _________________ Graham |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|