JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

IrpTransmogrifier: new program/library for IRP protocols
Goto page Previous  1, 2, 3 ... 6, 7, 8 ... 12, 13, 14  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Wed Jan 15, 2020 7:52 am    Post subject: Reply with quote

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

Release notes:

Code:

* 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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Tue Mar 24, 2020 7:32 am    Post subject: Reply with quote

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:

* 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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Tue Apr 21, 2020 9:49 am    Post subject: Reply with quote

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"?
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Tue Apr 21, 2020 4:17 pm    Post subject: Reply with quote

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

Issue
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Tue Apr 21, 2020 5:18 pm    Post subject: Reply with quote

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?
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Wed Apr 22, 2020 2:10 am    Post subject: Reply with quote

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 Wink

IrScrutinizer has a pull-down menue containing the most commonly used radices (2,8,10,16). This selection is, admittedly, in principle arbitrary.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Wed Apr 22, 2020 5:48 am    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Wed Apr 22, 2020 11:34 am    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Wed Apr 22, 2020 2:54 pm    Post subject: Reply with quote

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:

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!
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Thu Apr 23, 2020 9:54 am    Post subject: Reply with quote

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:
{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.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Thu Apr 23, 2020 12:21 pm    Post subject: Reply with quote

Quote:

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.
Quote:

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:
$ 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]

Quote:
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(...).
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Thu Apr 23, 2020 12:40 pm    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Thu Apr 23, 2020 1:40 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Sun Apr 26, 2020 6:58 am    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Thu Apr 30, 2020 4:17 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3 ... 6, 7, 8 ... 12, 13, 14  Next
Page 7 of 14

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control