IrpTransmogrifier: new program/library for IRP protocols

[Barf]

The powers-of-two release 1.2.4 has been released!!

Release notes:

Code: Select all

* Code generation xml: Some fixes, more attributes, in particular tolerances.
* Better error messages for --logclass.
* New option list --parsedirp.
* Don't nuke whitespace from IRP in database.
* list --gui working again.
* Improved command line documentation for logging commands.
* Better command decoding for the demodulate command.
* Fixed problem with 0 durations in render --modulate. #154.
* Schema irp-protocols: Attribute protocol/@name now required.
* Documentation update.
* New protocol: Akord.
* Analyzer: --parameterwidths now allows for optional parameter names. #150.
* Several issues with patch files fixed.
* Changes from Graham Dixon to uei-executor, several protocols.
* Changed parameterization of NEC*-f16 protocols.
* Added more test files and API examples.
* Update JCommander to the current version 1.78. #153.
* Refactoring of CommandDecode and Decode. #152.

Available here.

[Barf]

New release 1.2.5!

This release contans a few bug fixes and minor improvements. Main reason for the release is to wrap up a release for usage in the new upcoming version of RemoteMaster.


Release notes:

Code: Select all

* IrpProtocols.xml: Merge protocol updates from RemoteMaster 2.10b2.
* Better error messages for rendered IrSequences not ending with gap. #158.
* Bugfix: IrpDatabase patch problems. #160.
* API: IrpDatabase API fixes; avoid return null. #159.
* Bugfix: overflow problem with very large data sets in --namedinput. #157.
* IrCoreUtils.parseLong improvements.
* list command: hide some ("expert") options. --all new option.
* Improve decoding of short Pronto hex (slightly more forgiving).
* Fixed decoder bug in Extent.decode. #156.
* render, bitfield, expression: --parameters now synonym for --nameengine. #155.

Available here.

[mathdon]

I am adding a signal analysis panel to Learned Signals in RMIR and have come across something that seems to me like a bug. This is the behaviour of the analysis option "invert". This is listed in your documentation as an option that determines how the computed IRP is displayed. Here are two analyses of the same signal, the first without "--invert" and the second with it:

{38.4k,521,msb}<1,-1|1,-3>(16,-8,A:16,1,-19m,(B:16,1,-19m)*){A=0xf50e,B=0xf50e}

{38.4k,521,msb}<1,-1|1,-3>(16,-8,A:16,1,-19m,(B:16,1,-19m)*){A=0xaf1,B=0xaf1}

These are not equivalent analyses of the signal as they complement the A and B values without any corresponding change elsewhere. I had expected that "invert" would complement A and B and also invert the bitspec, so in the second analysis above, the bitspec would be <1,-3|1,-1>. Doing both together leaves the signal unchanged.

Is this a bug or do I misunderstand the intention of "invert"?

[Barf]

This is a bug, sorry. Or possibly an option that is incompletely implemented? Sorry for that. (And thanx for reporting.) Will fix.

Issue

[mathdon]

Thanks for confirming that it is a bug that you will fix. In implementing my new signal analysis panel, I also want to allow setting of the radix for output values. I see that IrScrutininzer allows setting radix values of 2,8,10 and 16. Ideally I would also like to allow a radix of 4. I have that in ExchangeIR, with a prefix of 0q, for example 0q12 is decimal 6. I know this isn't a standard prefix, but is there any way that I can implement this?

[Barf]

IrpTransmogrifier accepts all radices Java accepts, and that is everything between 2 and 36. Several subcommands have a --radix option. All *.toString(...) functions have an int radix argument, in all cases where it makes sense. Carl Sagan fans can use 11

IrScrutinizer has a pull-down menue containing the most commonly used radices (2,8,10,16). This selection is, admittedly, in principle arbitrary.

[mathdon]

Thanks, it works. I didn't think of trying it as I assumed you would have included radix 4 in IrScrutinizer if it was supported. There are bitspecs that convert bit pairs, which is radix 4, so although it is not in common use I think this is one place where it is useful. As I can see no way of a user extending the IrCoreUtils.radixPrefix(..) function, I have used string replacement to insert the "0q" prefix for radix 4.

[mathdon]

Two further comments arising from my use of Analyzer in RMIR. AnalyzerParams.getFrequency() returns a "double" rather than a "Double" and so gives an exception on the default value of "null", and the "invert" option appears to work OK on biphase signals but not on others.

[Barf]

Just uploaded some fixes, available as the CI build.

* --invert has been fixed, What it really does is to reverse the order of the elements in the bitspec, and to compute the numerical parameter values accordingly.
* There is also an option --validate to analyze, which makes the analyze command validate its result, namey it renders its protocol, and compares with the input signal. (Not implemented for all use cases.)
* Argument to --radix is validated, and the program barfs if it is < 2 or > 36. (Previously it silently produced the radix-10 result.
* There is a possibility from the API to set the list of radix parameters, see below. This affects IrCoreUtils.parseLong (implicitly called by most parsing routines) and IrCoreUtils.radixPrefix (implicitly called by e.g. Protocol.toString(... int radix ...)
* Return type of AnalyzerParams.getFrequency() has been changed to Double (thanx Graham).

To use the configurable radix feature, define a Map<String, Integer> with prefixes and radices. Prefixes must be unique, but not radices. The static function IrCoreUtils.setRadixPrefixes(Map<String,Integer>) should then be called with this Map as argument. Example (from IrCoreUtilsNGTest.java)

Code: Select all

public void ztestParseLong_String_WithSetRadixPrefixes() {
        System.out.println("setRadixPrefixes");

        // Set up a map of prefix -> radix mappings
        Map<String, Integer> map = new LinkedHashMap<>(4);
        map.put("0b", 2);
        map.put("0x", 16);
        map.put("0q", 4);
        map.put("0cs", 11); // For Carl Sagan ;-)
        IrCoreUtils.setRadixPrefixes(map);

        assertEquals(IrCoreUtils.parseLong("0x12345"), 0x12345);
        assertEquals(IrCoreUtils.parseLong("12345"), 12345);
        assertEquals(IrCoreUtils.parseLong("0b100100"), 0b100100);
        try {
            IrCoreUtils.parseLong("%100100");
            fail();
        } catch (NumberFormatException ex) {
        }
        assertEquals(IrCoreUtils.parseLong("012345"), 12345);
        assertEquals(IrCoreUtils.parseLong("0"), 0);
        assertEquals(IrCoreUtils.parseLong("0cs1A"), 21);
        assertEquals(IrCoreUtils.parseLong("0q12"), 6);

        assertEquals(IrCoreUtils.radixPrefix(2), "0b");
        assertEquals(IrCoreUtils.radixPrefix(4), "0q");
        assertEquals(IrCoreUtils.radixPrefix(11), "0cs");
        assertEquals(IrCoreUtils.radixPrefix(10), "");
    }
}

Thanx Graham for the feedback!

[mathdon]

The configurable radix feature works fine, thank you, as does the invert option. Sorry to keep bothering you, but here are two further comments. Not bugs, not even suggestions as they have easy work-arounds, but things that do not work as I expected and that I felt were worth reporting. First, NamedProtocol.getIrp() includes whitespace when the IRP in IrpProtocols.xml is split over two lines. As an example, for SonyDSP it gives

Code: Select all

{40k,600}<1,-1|2,-1>((4,-1,96:8,18:7,^45m)3,(4,-1,195:8,^45m),(4,-1,81:8,^45m),(4,-1,F:8,^45m), 		    (4,-1,(F^145):8,11:6)){F=0x80}

Easily worked around by adding replaceAll( "\\s", "" ), but a surprise when I first came across it. Secondly, Decoder.Decode.toString(radix, separator) does not use the radix prefixes, just giving the raw converted value. This can again be worked around with a replaceAll but again it was not expected. The same may be true of other toString(radix ...) functions but that is the only one I have needed.

[Barf]

First, NamedProtocol.getIrp() includes whitespace when the IRP in IrpProtocols.xml is split over two lines.

It returns the unparsed line from the data base. It may also contain comments, and the user's radix is not taken into account. This is a feature, not a bug.

Easily worked around by adding replaceAll( "\\s", "" ),

Bad solution. The function you want to use is toIrpString, in some of its versions.

The list command has two options, --irp and --parsedirp, the the first one prints the verbatim string, the latter one prints the digested version, taking --radix into account:

Code: Select all

$ irptransmogrifier list --radix 16 --irp --parsedirp sonyDSP
name=SonyDSP
irp={40k,600}<1,-1|2,-1>((4,-1,96:8,18:7,^45m)3,(4,-1,195:8,^45m),(4,-1,81:8,^45m),(4,-1,F:8,^45m),
                    (4,-1,(F^145):8,11:7,^45m))[F:0..255]
parsedirp={40.0k,600,lsb}<1,-1|2,-1>((4,-1,0x60:8,0x12:7,^45m)3,(4,-1,0xc3:8,^45m),(4,-1,0x51:8,^45m),(4,-1,F:8,^45m),(4,-1,(F^0x91):8,0xb:7,^45m))[F:0x0..0xff]

Decoder.Decode.toString(radix, separator) does not use the radix prefixes, just giving the raw converted value.

Seeing it on the level of the interactive program, it turns that --radix works very inconsequentially.

Fixed version available as CI build. This also fixes Decoder.Decode.toString(...).

[mathdon]

Thanks for the info. I will have to think about it in the context of what I am trying to do. I hope you understand that in the API it is difficult to find all the various ways of doing things, and what their differences are. I am trying to do my best by studying the source code without having to keep asking you how to do something, but it is not an easy task.

[Barf]

First to check should always be the API-documentation, available here. Also, the test files src/test/java/... (being test that are being run when building the program) can often give some example on the usage of the classes.

[mathdon]

I have now posted development build 8 of RMIR v2.10 in the RMIR Development folder. This includes the signal analysis and documentation features on the Learned Signals panel that have led to my recent posts here. Because of the new documentation feature, I have now updated the documentation of the four NEC f16 protocols to describe NEC Yamaha as a special case. These documentation changes are the only content in the rmProtocols.xml patch file that is included in this build.

I do use the API documentation, but unless there is something in it that I am missing, it tells me the available commands and their syntax but not their semantics, so for example it does not help to distinguish between getIrp() and toIrpString() for NamedProtocol. I have updated the SVN with the new additions, so you can check how I have coded them if you wish. As a result of my testing, I am pretty confident that they work as I intend, but my coding may not be in the most appropriate way.

[Barf]

I had a quick look at the new feature in RM. Looks pretty neat.

API documentation: This is being developed all of the time. Feel free to request where it is particularly needed. I just checked in some improvements for the Protocol class.

The improved documentations for the NEC*-f16 protocols have been merged (after some change of the markup).

As discussed in the IrScrutinizer thread, the protocol Dysan has been renamed to Dyson.

New version available as CI build.