IrScrutinizer: capturing, generating, analyzing, import, exp

[Barf]

Graham, as usual you are right.

Background:

The documenation files are written in the Apache Forrest/Cocoon system, using the "document" XML format. (This is a simple, but not too simple, format for writing technical documents. Unfortunately, this is since many years not being developed, and was recently declared retired. ) The files are written for my web site www.harctoolbox.org. Therefore, there are references to other files there. When generating the IrScrutinizer distro, (very) simplified versions are generated (IrScrutinizer.html, IrpTransmogrifier.html, Glossary.html), and linked from the program. For this reason, references to other files, like Girr.html, fail.

However, fixing just this problem is not that hard. I have just updated the xslt transformation that generates the simlified html files. It will direct the user to harctoolbox.org for the files that are not locally available. Checked in and available in the just published CI build.

IrpTransmogrifier.html has the same problem, but has not yet been fixed.

Thanx again!

[mathdon]

Thanks for fixing the Girr documentation link. From it:

For importing and exporting Girr files to Java programs, a Java library is provided.

Provided, but not very accessible . I have had to construct a jar file from org.harctoolbox.girr extracted from the IrScrutinizer distro for use in RMIR. Was there an easier way? It would be nice if it could be included in the IrpTransmogrifier distro as well, as that is already included in RMIR.

In the RMIR v2.10 thread I wrote:

However, at present there is nothing in the pipeline. I am having to keep myself amused instead by playing with IrScrutinizer

Update - there is something in the pipeline now , hence the Girr interest. I am planning to capitalize on the code for converting learned signals to a device upgrade by adding to RM (not RMIR) a facility for importing Girr files. Part of my "playing with IrScrutinizer" .

Serial: I will concentrate on getting the "new driver" (alternative: steal what the Arduino IDE is using) to work, and do not plan to address issues with the current driver RXTX.

RMIR uses jSerialComm for accessing the BLED112 Bluetooth dongle. Marcin, who wrote that part of the code, started out using RxTx but it gave problems so he changed to jSerialComm. I thought this might be of interest as you are looking for a replacement for RxTx as well.

[Barf]

I have had to construct a jar file from org.harctoolbox.girr extracted from the IrScrutinizer distro for use in RMIR. Was there an easier way?

No. I just put a *-bin.zip file there, so now there is. I can do a CI-build too if there is a need.

The "professional" way to deploy it (or IrpTransmogrifier) is to use Maven (or its successor gradle) as build system, instead of ant. You just add it to the pom.xml as per README.md, it is then automatically downloaded and included in the *jar-with-dependencies.jar.

It would be nice if it could be included in the IrpTransmogrifier distro as well, as that is already included in RMIR.

That would create a circular dependence, which is a no-go. (See this diagram of dependencies.)

Update - there is something in the pipeline now , hence the Girr interest. I am planning to capitalize on the code for converting learned signals to a device upgrade by adding to RM (not RMIR) a facility for importing Girr files. Part of my "playing with IrScrutinizer" .

Kewl. There is already an exporter of CSV-signals, for which I submitted a patch .

RMIR uses jSerialComm for accessing the BLED112 Bluetooth dongle. Marcin, who wrote that part of the code, started out using RxTx but it gave problems so he changed to jSerialComm. I thought this might be of interest as you are looking for a replacement for RxTx as well.

Thanx for the link; I have not started it yet. The reason why NeuronRobotics / nrjavaserial seems attractive is that there has been very much activity lately, so if I run into quirks, I can probably get it fixed. And it is, as direct successor to RXTX, it is supposed to be almost API compatible.

[mathdon]

And it is, as direct successor to RXTX, it is supposed to be almost API compatible.

I think this is true of jSerialComm too. It is intended as an alternative to RxTx and Marcin needed to make only trivial changes, but perhaps his use was simpler than yours.

The "professional" way to deploy it (or IrpTransmogrifier) is to use Maven (or its successor gradle) as build system, instead of ant. You just add it to the pom.xml as per README.md

Sorry, I am not a professional (and never have been) and I have no idea what this means. I just wanted the compiled classes as a library to add into Eclipse.

[Barf]

... I have no idea what this means. I just wanted the compiled classes as a library to add into Eclipse.

Maven and gradle are supported by Eclipse, as alternatives to ant. But if the current method works, fine.

[mathdon]

I am planning to capitalize on the code for converting learned signals to a device upgrade by adding to RM (not RMIR) a facility for importing Girr files. Part of my "playing with IrScrutinizer"

A few words on my motivation for this. I see it as a replacement for the present ability of IrScrutinizer to export RemoteMaster .rmdu files, which I understand (without trying it) only works in simple cases. That is like the RMIR conversion of learned signals to a device upgrade when the decoder was DecodeIR. The Girr import will be like the conversion of learned signals is now, with IrpTransmogrifier as decoder - it works perfectly, whenever the conversion is possible. But this is not entirely altruistic. There are signals that the UEI learned signals formats cannot handle, or have difficulty handling, so this also provides a means of capturing signals with IrScrutinizer and creating a device upgrade from them that bypasses the somewhat unreliable UEI learned signals formats. (I expect Rob will say that can be done now, manually, but the import/conversion process can handle complex combo executors with ease and for me at least, it is an improvement on manual upgrade construction.)

[mathdon]

Is there a way, in the decoding in IrScrutinizer, of setting the IrpTransmogrifier option DecoderParameters.setRemoveDefaultedParameters( false )? I have this set in RMIR to avoid conflicts when converting a set of signals to a device upgrade where some have the default and some an explicit value for a parameter, such as Subdevice in NEC1 signals.

[Barf]

I am planning to capitalize on the code for converting learned signals to a device upgrade by adding to RM (not RMIR) a facility for importing Girr files. Part of my "playing with IrScrutinizer"

Graham, I am excited to hear this! I have been planning to suggest something like this for some time myself. Probably, Most ("most") collections of "arbitrary" IR signals would produce a working JP1-setup with less than 1 minute!

It should not be too hard, given what we already have finished. Basically, you just have to fill the "leared signals" table with the (raw) content of a Girr file.

... I see it as a replacement for the present ability of IrScrutinizer to export RemoteMaster .rmdu files, which I understand (without trying it) only works in simple cases.

I would express it slightly differently: the export, using the dummy protocol "ImportOnly" is extremely "dumb"; it always succeeds, but it leaves the hard work for the user...

There are signals that the UEI learned signals formats cannot handle, or have difficulty handling, so this also provides a means of capturing signals with IrScrutinizer and creating a device upgrade from them that bypasses the somewhat unreliable UEI learned signals formats.

I am lost here. Where does the UEI learned signal format enter the equation?

[Barf]

Is there a way, in the decoding in IrScrutinizer, of setting the IrpTransmogrifier option DecoderParameters.setRemoveDefaultedParameters( false )?

No. But it would not be too hard to implement it either...

[Barf]

Just checked in a version which does have removeDefaultParameters as user settable variable.

[mathdon]

It should not be too hard, given what we already have finished. Basically, you just have to fill the "learned signals" table with the (raw) content of a Girr file.

It wasn't. It is done, subject to further testing. The main effort was in doing some restructuring of the learned signals to device upgrade conversion to separate the conversion process from the decoding with IrpTransmogrifier, and that needed doing anyway.

There are signals that the UEI learned signals formats cannot handle, or have difficulty handling, so this also provides a means of capturing signals with IrScrutinizer and creating a device upgrade from them that bypasses the somewhat unreliable UEI learned signals formats.

I am lost here. Where does the UEI learned signal format enter the equation?

Perhaps I have expressed this badly. At present the conversion to a device upgrade starts with a set of learned signals in UEI format, either learned on a remote and downloaded to RMIR or imported to RMIR from elsewhere, such as from Pronto signals. You cannot literally 'fill the "learned signals" table with the (raw) content of a Girr file'. Put another way, you cannot import a learned signal decode, only a learned signal. The restructuring I described above was essentially to make this separation, to be able to import the decode without it having to come from a learned signal. From a practical point of view, I see this as using IrScrutinizer instead of a remote control as the "device" to learn the signals that are to be converted to a device upgrade.

No. But it would not be too hard to implement it either...

Then please do so . [Sorry, this crossed with you saying you have already done this.]

[mathdon]

It should not be too hard, given what we already have finished. Basically, you just have to fill the "learned signals" table with the (raw) content of a Girr file.

I've only just noticed you say "(raw)" here. I am importing the parametric remote in a Girr file, with the decoding done in IrScrutinizer. I hope this is OK by you, as it seems preferable to me. IrScrutinizer has greater control over the decode with IrpTransmogrifier than RMIR offers.

[Barf]

Basically, I envision something like this (using the Girr library), simplified (and not tested)

Code: Select all

RemoteSet remoteSet = new RemoteSet(girrFile);
List<Command>commands = remoteSet.getAllCommands();
for (Command command : commands) {
     IrSignal irSignal = command.toIrSignal();  // computes the raw IR signal in a "smart" way
     String name = command.getName();
     learnedTable.add(irSignal, name); // you tell me what this does
}

then the learnedTable decodes the (raw) signals that was entered into it.

[mathdon]

My first idea was similar to your suggestion, but then I thought it preferable to let IrScrutinizer do the decoding. The corresponding part of my code is

Code: Select all

      ArrayList< ExternalSignal > esList = new ArrayList< ExternalSignal >();
      Map< String, Command > map = remote.getCommands();
      for ( String cmdName : map.keySet() )
      {
        ExternalSignal es = new ExternalSignal();
        esList.add(  es );
        es.signalName = cmdName;
        es.decodes = new ArrayList< LearnedSignalDecode >();
        Command cmd = map.get( cmdName );
        NamedProtocol np = LearnedSignal.getTmDatabase().getNamedProtocol( cmd.getProtocolName() );
        Map< String, Long > parms = cmd.getParameters();
        Decode decode = new Decode( np, parms, 0, 0, 0 );
        LearnedSignalDecode lsd = new LearnedSignalDecode( decode );
        es.decodes.add( lsd );
      }

ExternalSignal is just a simple structure. If the RemoteSet contains more than one Remote, the user is asked to select which Remote to import. I will have something for you to test in a day or so.

[mathdon]

I have found that on the Import tab, if I select a folder rather than a Girr file it will import all the Girr files in that folder as a tree of remotes. But how can I export that tree as a single Girr file containing a RemoteSet with multiple remotes? I am trying to test my facility to select one remote for import to RM from a RemoteSet containing multiple remotes, but can find no way to generate such a Girr.