IrpMaster, program/library for IRP rendering, released

[Barf]

Inspired by this thread, I have been thinking over the "correct" way to render signals of this type ... (...)+ several times. I would like to stress out that this is a real issue, to determine the correct behavior when e.g. a program is sent the instruction "send the signal one time". It is not an academic question like "keypress shorter than 6ms" or debouncing circuitry.

The pronto notation is normally described as "intro part exactly once, repetition part if and as long as the button is held down". I.e., zero or more times. Therfore, I think I stand to my interopretation that the IRP

Code: Select all

I (R)+

should properly be rendered as having intro sequence I R, which is what IrpMaster presently does.However, in a sense, this is clearly ugly, awkward, and redundant. If I recall properly, there is a flag in LIRC called something like "send_repeat_least_once", which should be exacly what we need.

Returning from this philosophical excursion, I implemented a new option, tentatively called

Code: Select all

 --disregard-repeat-mins

, which will make IrpMaster render the intro sequence without repetition part, also in the ... (...)+ case. Example (connecting to the above mentioned thread)

Code: Select all

[1191]$ java -jar dist/IrpMaster.jar -c data/IrpProtocols.ini -p  dish_network 0 0 4
Device Code: 0.0 Function: 4
0000 0048 0012 0011 0017 015A 0017 00A1 0017 00A1 0017 00A1 0017 005C 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 015A 0017 00A1 0017 00A1 0017 00A1 0017 005C 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 015A
[1192]$ java -jar dist/IrpMaster.jar -c data/IrpProtocols.ini -p --disregard-repeat-mins dish_network 0 0 4
Device Code: 0.0 Function: 4
0000 0048 0001 0011 0017 015A 0017 00A1 0017 00A1 0017 00A1 0017 005C 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 015A

The latter form is obviously what mdavej expects.

I would welcome feedback of all sorts. Should it be default? Is there a less awkward name? I plan to incorporate it into the next release, due later this spring.

[Barf]

Version 0.1.2 has just been released. See the download area for downloads and links. Also see the IrMaster thread for the more user friendly GUI accompanying program, and some administrative changes.

The binary distribution of IrpMaster has been eliminated. Instead, the binary distribution of IrMaster (or its setup.exe-version for Windows) should be installed. This will create a (somewhat) user friendly wrapper, and adjust the Windows PATH to start IrpMaster just from a command windows, eliminating a considerable amount of cruft from the command line. See the documentation. Still, not intended for the "masses"...

[Barf]

I have just released version 0.2.0 of both IrMaster and IrpMaster, Available in the file area as a binary distribution, and as a Windows setup.exe file. As before, no separate binary distributiuon of IrpMaster. The source are no longer in the file section, but can be downloaded from my web site.

Release notes

User visible changes:

Plotting implemented using PtPlot.

Wave export and Audio Hardware output device implemented.
New export format Lintronic.

Wave import.

Many fixes to appearance, more careful layout etc. The main window now
rescales sensibly, making it possible to enlarge CCF window and/or the
log window. The divider on top of the log window allows for resizing
log window.

Have the send-button enabled some more, thus restoring old
short-circuiting behavior (render and sending if text area empty)

The short pronto forms 5000, 5001, 6000, 900a are now recognized in
the CCF window. They can be Plotted (and Analyzed!) directly.

IrpMaster: --analyzeIR --ccf .... was not working; fixed.

war dialer now has #-sends options.

IrProtocols.ini: MCE: make the T toggle. rs200 and intertechno new
protocols. A few toggling protocol (like rc6 and rc5x) was erroneously
written like (...,T=1-T)+, changed to ((...)+,T=1-T).

Internal improvements:

Many internal improvements in API and its documentation.

made exit codes uniform, see IrpUtils

Use jcommander for the decoding of command line decoding of the main
class of class Wave.

Macro new class, presently not really used yet. ModulatedIrSequence
new, use that in the API when appropriate. append(double) and
parseMacro new. use IrSignal(protocolIni, arg_i, args) in
main. Improved API: use doubles for data (in microseconds, not
periods) and for modulation frequency.

Version info moved into class Version (both IrMaster and IrpMaster).

use odd/even index in IrSequences instead of sign. Improved Help
message in Plotter. Put Time in Plotter header. Implemented plotting

I have also written a tutorial on what can be done with the XML export (as example, generating C code).

[3FG]

Well, since in another thread it was mentioned that no one is asking for features.....
I recently wanted to use IrpMaster to generate some air conditioner Pronto Hex. The form is {38.4k,413}<1,-1|1,-3>(8,-4,A:128,1,-100m)+. The makeup of A is more complicated, but the immediate issue is the length implementation limit of IrpMaster, which I take to be 64 bits, originating (I suppose) from the use of 64 bit integers. That seems to be true even if A is split up into 16 bit quantities.

This sort of situation doesn't come up often, and I can work around it, so probably it isn't worthwhile to increase the length limitation. By comparison, MakeHex can generate a 128 bit Pronto Hex, although it ability to calculate checksums is severely limited.

[Barf]

Thanx for the suggestion. As you seems to suggest, the length limit of 63 bit length for the parameters (not 64 due to James Gosling's questionable decision not to have unsigned types in Java) is a design consideration. I did not make this decision lightly: All the protocols in DecodeIR.html (and IrpProtocols.ini) are well below that limit. It makes the implementation easier and more efficient, it is not an "arbitrary limit". What is possibly more restricting than having each parameter less or equal to 2^63-1 = 9223372036854775807 is that also concatenated bitfields with an overall length > 64 are rejected (as you appear to have found out). I think that the first limitation is possible to live with, but I may consider fixing the second. The whole expression engine is build around the long type, so I am not really happy to fumble around with that.

By comparison, MakeHex can generate a 128 bit Pronto Hex

So, let's scrutinize MakeHex. First of all, it does not take any arguments larger than 32 bits. They are, silently(!!), replaced by their mod 2^32 version. In the interval 2^31-2^32-1, the text in the *.hex-files gives them out as negative numbers, as per the 2-complement. If using bitfields larger than 32 bits long interesting things happens: The C++ version happily lets you write a 1000 bits bitfield, and produces an corresponding CCF result. But is it correct? The Java translation (by me) throws an ArrayOutOfBoundsException as soon as a bitfield exceeds 32, but the C++-version happily delivers result. It turns out that the result is simply plain wrong. Looking at the C++-code shows

Code: Select all

    unsigned int m_mask[33];

but it is subsequently accessed outside of the limit, producing erroneous result. Using a memory checker would not be a bad idea...

Summarizing, both IrpMaster and MakeHex have their limits, IrpMaster's is higher. IrpMaster gracefully reports an error if you exceed its limit (ok, error messages could be better), MakeHex happily produces erroneous results with no warning or error ....

[3FG]

Yes, it isn't at all important to make individual parameters longer than 63 bits, because one longer parameter can be assembled from two or more shorter parameters, and I haven't run across any IR signal that actually needs a parameter of even 63 bits. But the total length limitation is harder to work around. For the air conditioner, I did it at first by manually assembling shorter Pronto Hex sequences, and then I found that MakeHex doesn't limit total length.

I quite agree that MakeHex tend to be silent when some limit is reached, and then may produce incorrect results. In this particular case, it worked fine, and is a suitable workaround.

[ebariaux]

Hello Bengt,

I did download the 0.2.0 version of the source code but have some issues building from it.

Given there is a Makefile present, I just tried make but this does not seem to work at all.
So I tried compiling the sources with Eclipse.
I see the classes that are generated using ANTLR from the grammar where not present, so I did generate them.

Still, I have a couple of classes that are still missing, such as org.harctoolbox.IrpMaster.Iterate.InputVariableSetValues.

Should those also be generated from somewhere ? Or are they coming from some other source bundle ?

Thanks for your help,
Eric

[Barf]

Hi Eric, nice to meet you here

The Makefile is there (as a comment therein suggests) since I have not yet succeeded to learn to write ant. I use it mainly to build distributions. Ant (which I normally call from Netbeans) builds the whole shebang, including running ANTLR. Of course this assumes that its build.xml (and others) are present. Which I stupidly forgot to include (again ). To make things even more embarrassing, I also forgot to include the source files in org/harctoolbox/IrpMaster/Iterate (third ).

I made another attempt, available here. Download, unzip into an empty directory, and just cd to it and type "ant" to the shell should do it (assuming you have ant installed). Thats all. I use Netbeans myself; in Netbeans you can probably just "open" it as a project, if you can tell me how it works with Eclipse I would be grateful (it should not be any problems).

Sorry for the silly errors I made. I was concentrating on the windows users and the setup.exe stuff. Thanx for reporting.

[ebariaux]

Thanks for the update Bengt.

Works much better this time.

I did try having Eclipse build its project based on the ant build file but it did not like the fact that the main build.xml just references other files and does not directly have the code the compile the java.

But I did create a project manually (barely pointing at the folder) and I can launch the tool from Eclipse. I'll try some more stuff and will let you know how it behaves under Eclipse but should not but very different from Netbeans.

[Barf]

Announcing IrpMaster version 0.2.1.

The new version has a number of small improvements, one of them the unlimited (concatenated) bitfield length, as requested by 3FG a few postings earlier. Another is the support of the UEI learned format both for input and output.

(This far I have implemented ALL requests ...)

There is also a new release of IrMaster, described here.

As before, there is no binary distribution, since it is contained in the IrMaster binary distribution. Sources are available from my web site.

A word on the difference between IrMaster and IrpMaster: IrpMaster is the API library and command line program (likely of limited interest to beginners), IrMaster the user friendly program with GUI and such. IrMaster depends on IrpMaster, but not vice versa. These remains two separate projects with different releases etc.

Release notes:

User visible changes in IrpMaster 0.2.1

General code cleanup, partially suggested by static code analysis.

Never throw org.antlr.runtime.RecognitionException in public methods:
That would break encapsulation and force use to install the antlr*.jar
just to compile.

Now bit streams can be of unbounded length, previously 64
bits. Suggested by 3FG, see
http://www.hifi-remote.com/forums/viewt ... 6&start=33 .

Main routine: new option -u|--uei. Can now interpret CCF strings as
UEI learned format. It interprets the "ccf" string either as Pronto or
as UEI learned, according to the number of characters in its digits.

Using ExchangeIR 0.0.8.2. For this, uses a new class ExchangeIR, with some
new functions, see API documentation.

Since the previously used com.hifiremote.decodeir.DecodeIRCaller produced pesky
outputs on stderr, use my own version (just removing the
LibraryLoader.loadLibrary stuff). Although the changes are trivial, my
fixed source is available on my website, in accordance with the GPL:
http://www.harctoolbox.org/downloads/DecodeIrCaller.zip

DecodeIR is not limiting the number of decodes any longer (was 10
previously).

New option --quiet, limits outputs.

Misc. minor bugfixes, documentation fixes, etc.
================================================================
Releasenotes for IrpMaster 0.2.0

User visible changes:

New export format Lintronic.

Wave import.

--analyzeIR --ccf .... was not working; fixed.

IrProtocols.ini: MCE: make the T toggle. rs200 and intertechno new
protocols. A few toggling protocol (like rc6 and rc5x) was erroneously
written like (...,T=1-T)+, changed to ((...)+,T=1-T).

Internal improvements:

Many internal improvements in API and its documentation.

made exit codes uniform, see IrpUtils

Use jcommander for the decoding of command line decoding of the main
class of class Wave.

Macro new class, presently not really used yet. ModulatedIrSequence
new, use that in the API when appropriate. append(double) and
parseMacro new. use IrSignal(protocolIni, arg_i, args) in
main. Improved API: use doubles for data (in microseconds, not
periods) and for modulation frequency.

Version info moved into class Version (both IrMaster and IrpMaster).

use odd/even index in IrSequences instead of sign. Improved Help
message in Plotter. Put Time in Plotter header. Implemented plotting

[3FG]

Thanks for implementing the unlimited bitstream length. The following Windows batch file generates ProntoHex for a Fujitsu Airconditioner. I show it here in case someone would like to use it as a template for complicated protocols. Note the use of %% instead of % to indicate the mod function. The Windows command interpreter reserves a single % sign.

Code: Select all

set IRPMASTERHOME=C:\Remotes\IrMaster
set JAVA=java
"%JAVA%" "-Djava.library.path=%IRPMASTERHOME%\Windows" -jar "%IRPMASTERHOME%\IrMaster.jar" IrpMaster -p -d 1 -o foo2.bar  -i "{38.4k,413}<1,-1|1,-3>(8,-4,20:8,99:8,0:8,16:8,16:8,254:8,9:8,48:8,H:8,J:8, K:8, L:8, M:8,N:8,56:8,Z:8,1,-104.3m)+ {H=16*A + wOn, J=16*C + B, K=16*E:4 + D:4, L=tOff:8, M=tOff:3:8+fOff*8+16*tOn:4, N=tOn:7:8+128*fOn,Z=256-(H+J+K+L+M+N+48)%%256} [A:0..15,wOn:0..1,B:0..15, C:0..15,D:0..15,E:0..15,tOff:0..1024,tOn:0..1024,fOff:0..1,fOn:0..1]" A=8 wOn=1 B=1 C=0 D=0 E=0 tOff=0 fOff=0 tOn=0 fOn=0

[Barf]

Announcing IrpMaster version 0.2.2.

The new version has only a few number of small improvements, see the release notes. Thanx to 3FG for a new new protocols in the IrpProtocols.ini.

There is also a new release of IrMaster, described here.

As before, there is no binary distribution, since it is contained in the IrMaster binary distribution. Sources are available from my web site.

Release notes:

Code: Select all

User visible changes in IrpMaster 0.2.2

Make System.getProperty("os.arch") lowercase when searching for the
DecodeIR shared library (see
http://www.hifi-remote.com/forums/viewtopic.php?t=14219&start=49 for
background.)

Accept '*' (three characters) as synonym for *, since some
Windows/Java enviroments seem to defy all logic when passing parameters.

IrpProtocols.ini: add RECS80 in three variants

Interpretation of extent: every extent executed resets the duration
counter. Thus, the Kathrein IRP
{38k,540}<1,-1|1,-3>(16,-8,D:4,~D:4,F:8,~F:8,1,^105m,(16,-8,F:8,1,^105m)+)
(note: there are extents both in the intro and the repetition) now makes sense.

Allow for separate 32 and 64 bit versions of decodeIr for windows.

New IrpProtocols.ini courtesy of 3FG (thanx!). DecodeIR decoding
adapted to this version -- several special cases of "funny names"
(for example with spaces) requiring special treatment.

Parameter intervals can now be given as #<number>, which is really the
old a:b#c notation, with a and b taken from the protocol parameter as
its min and max value respectivelly.

Protocol order in IrpProtocols.ini are now preserved by
--dump. They contain TAB instead of : after the protocol name -- makes
it better to import into a spread sheet. Protocol names are now
*really* compared case insensitively.

The --ccf command in the main routine can now parse raw signals,
signalled by a trailing `+'.

[Barf]

New version 1.0.0 released!

Source code on my website. No separate binary distribution.

Release notes:

Code: Select all

User visible changes in IrpMaster 1.0.0

This version is promoted to version 1.0.0!

DecodeIR.DecodeIrException new.

XmlExport new file. Moved some stuff from IrpUtils to XmlExport.

ICT class reconstructed (visible only from API).

Improvements to toPrintString functions in ModulatedIrSequence.

Bugfix and improvement in ExchangeIR.interpretIrSequence.

Implemented infinite bitfields (X::C) better. If trying to convert an infinite
bitfield to bitsequence, an error is thrown. Reject negative values for bitfield width and chops.

Iterating over parameter sets (including single values) complains for missing
parameter specs only when necessary, i.e. for iterations of type * and #.

Protocol inheritance now works also in the absence of parameter specs.

LircExport now does frequencies.

ExchangeIR.interpretString now interprets a raw signal with multi-line
string as already split in intro-, repeat-, and ending sequence.

Fixed bug in parsing - chars in BitFields.

[Johnson]

Hi,
I download the source code of IrMaster from
http://www.harctoolbox.org/downloads/Ir ... -1.0.0.zip.

But Eclipse prompt me some error info, pls take a look, it says some classes do not exist like IrpLexer.java , where can I get the class?


Thanks.

[Barf]

IrpLexer.java and IrpParser.java are generated automatically from Irp.g, and the Ant-script knows how to make this happen. Just typing "ant" in the top directory, assuming you have ant installed, should do the job.

Possibly Eclipse can do it automatically; I do not use Eclipse myself but Netbeans. Possibly there Eclipse can "import Netbeans project"? Neither Netbeans or Eclipse is required, though.