IrpTransmogrifier: new program/library for IRP protocols

[The Robman]

... BTW I think this should be an Announcement thread

Rob, can you take care of this? Thanx in advance.

Done.

[Barf]

In the light of recent discussion I think it would be a good idea to change the NEC1-f16 definition from

Code: Select all

{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:16,1,^108m,(16,-4,1,^108m)*)[D:0..255,S:0..255=255-D,F:0..65535]

to

Code: Select all

{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,E:8,1,^108m,(16,-4,1,^108m)*)[D:0..255,S:0..255=255-D,F:0..255,E:0..255]

(which is the one DecodeIR presently uses).

Comments?

[The Robman]

Does that break the long OBC into two smaller OBCs? If so, I agree with the proposal.

[mathdon]

As you wish. I have no preference.

[Barf]

Does that break the long OBC into two smaller OBCs?

Exactly.

I think there are several advantage of the two byte parameters instead of the one two-byte parameter:

* Compatibility with the standard NEC[1],
* Compatibility with (current) DecodeIR,
* Compatibility with e.g. "Rob's" new Excellist

Probably the old definition was taken at some point of time from DecodeIR, which later changed.

[The Robman]

I have made the update that Bengt suggested to rmProtocols.xml and then re-checked this file to see if it now displays 2 OBCs, but it's still only displaying 1. Are there other changes that need to be made?

Code: Select all

<irp:protocol name="NEC-f16">
        <irp:parameter name="prefer-over">NEC-Shirriff-32</irp:parameter>
	<irp:parameter name="uei-executor">01AD[;D,S,F:8,F:8:8]</irp:parameter>
        <irp:irp><![CDATA[{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,E:8,1,^108m,(16,-4,1,^108m)*)[D:0..255,S:0..255=255-D,F:0..255,E:0..255]]]></irp:irp>
        <irp:documentation>
            A relaxed form (but used in some real devices) of the <a href="#NEC">NEC</a> protocol. Byte 3 and byte 4 are independent, and display as F and E parameters.
        </irp:documentation>
</irp:protocol>

[Barf]

I have made the update that Bengt suggested to rmProtocols.xml and then re-checked this file to see if it now displays 2 OBCs, but it's still only displaying 1. Are there other changes that need to be made?

There are three protocols really, "NEC-f16", "NEC1-f16", and NEC2-f16"; your changed only the first one. (Have not checked "this file" though.)

[Barf]

This is the checked in IrpProtocols.xml with above mentioned changes, as well as Graham's additions..

[The Robman]

There's only 1 -f16 protocol in that file. I just downloaded IrpProtocols.xml and stored it in my RM folder (i didn't have that file before), but I'm still only seeing 1 long OBC for the -f16 signals in that file.

I just made the corresponding changes to IrpProtocols.html but still no luck.

[Barf]

There's only 1 -f16 protocol in that file.

There are three. Really.

I just downloaded IrpProtocols.xml and stored it in my RM folder (i didn't have that file before),

slightly hairy; you DID have that before, but contained within the jar file RemoteMaster.jar. (A jar file is really nothing else but a zip file with some extra structure.) You can use (I think...) WinZip or WinRar or some such to interactively inspect a jar file, and to replace a file within it. (Or the command line program "jar" from the Java development kit.) Alternatively you can replace Graham's rmProtocols.xml with an alternative IrpProtocols.xml.

I just made the corresponding changes to IrpProtocols.html but still no luck.

Not a very good idea: this file is only read by humans, using the browser. It is generated automatically from IrpProtocols.xml during build of IrpTransmogrifier.

[The Robman]

Take a look for yourself, there are 2 regular NEC definitions and 1 F16 definition:
https://www.hifi-remote.com/forums/dload ... e_id=25743

Putting IrpProtocols.xml inside remotemaster.jar did the trick, now I get OBC2 displayed as E= in the Misc column. May I suggest adding an OBC2 column in a future release?

[Barf]

Take a look for yourself, there are 2 regular NEC definitions and 1 F16 definition:
https://www.hifi-remote.com/forums/dload ... e_id=25743

That is Graham's patch file. It modifies some protocols in the present IrpProtocols.xml. What is in there, and not in there, is his decision.

Code: Select all

% irptransmogrifier --regexp list  'NEC.*-f16'
name=NEC-f16
name=NEC1-f16
name=NEC2-f16

Putting IrpProtocols.xml inside remotemaster.jar did the trick, now I get OBC2 displayed as E= in the Misc column.

May I suggest adding an OBC2 column in a future release?

That is Graham's decision.

[The Robman]

Lol, I know it's Graham's patch file, but you kept telling me that all 3 versions of f16 were in there and I was trying to show you that it only contains one.

And double lol that I know RMIR is Graham's program, Graham is in this thread too, so I was talking to him.

[mathdon]

May I suggest adding an OBC2 column in a future release?

The single-letter names D, S and F in IRP specifications have been (informally) standardized for Device, Subdevice and Function (OBC) protocol parameters. I don't think E has been standardized for OBC2, which would need to be the case for a new column which was present for all protocols. I would instead prefer to meet the particular case of NEC-f16 by having the E parameter show in the Misc column as OBC2, which I can do for an individual protocol without requiring any standardization of notation. I can even do it with IrpTransmogrifier still using a 16-bit F value, such is the flexibility of the uei-executor entries that link IrpTransmogrifier to RMIR.

The rmProtocols.xml patch file that I posted was a fix specifically for rsbrux and includes only entries for protocols that appear in his Learned Signal decodes. Before it gets added to a development build of RMIR, or incorporated into an IrpTransmogrifier release, I need to investigate what other NEC variants can be represented by the -f16 variants and make further additions to handle those.

[Barf]

Before it gets added to a development build of RMIR, or incorporated into an IrpTransmogrifier release, I need to investigate what other NEC variants can be represented by the -f16 variants and make further additions to handle those.

I intend to release the final 1.2.*-version or IrpTransmogrifier pretty soon, so if Graham (or someone else) wants something particular to go there, please give me an indication.