JP1 Remotes

Posted: **Sun Sep 27, 2020 7:24 am**

Bengt, you have posted an installation script for RMIR in Linux but as far as I can tell, there is no such script for IrScrutinizer. There is a Windows installer but not a Linux one. There is the AppImage that works just by double-clicking, but that is not an installation and it does not appear as an application to Linux. Am I missing something?

Posted: **Mon Sep 28, 2020 4:03 am**

mathdon wrote:Bengt, you have posted an installation script for RMIR in Linux but as far as I can tell, there is no such script for IrScrutinizer.

Here you go.

There is a Windows installer but not a Linux one.

I am not aware of an "Inno Installer" for Linux. Despite of that, Linux users tend to hate installers... I think the current procedure (download, unpack, execute setup-irscutinizer.sh) is not that frightening, though...

But I am open to suggestions. Flatpak I have not evaluated yet, possibly you...

There is the AppImage that works just by double-clicking, but that is not an installation...

Official site.

... and it does not appear as an application to Linux. Am I missing something?

See this.

Posted: **Mon Sep 28, 2020 6:36 am**

Barf wrote:Linux users tend to hate installers...

So do I - I didn't realize I was a natural born Linux user

. I am not wanting an IrScrutinizer installer, I was just curious as to why there wasn't one.

I think the current procedure (download, unpack, execute setup-irscutinizer.sh) is not that frightening, though...

That is of course also the procedure with RMIR, yet you want an installer for that. I know you want it installed in a read-only folder, but for me the biggest issue with that is as follows. Almost every time a user has problems, we say "upload your rmaster.err file for us to look at - you will find it in the RMIR installation folder". With RMIR in a read-only folder that becomes ""upload your rmaster.err file for us to look at - its location depends on your OS and the installation procedure you used and is probably buried deep inside some nested folder so good luck trying to find it".

Posted: **Tue Sep 29, 2020 2:28 am**

mathdon wrote:...I know you want it installed in a read-only folder, ...

Wrong thread. I am not going to bite...

Posted: **Mon Apr 12, 2021 9:05 am**

Bengt, you will see that I have posted screenshots from IRScope in this thread on the X10 protocol. I tried using IrScrutinizer but could not get it to decode even the valid X10.n signals from the S3F80 executor. I tried with the Widget on Win10 and with both the Widget and Arduino on Linux. It gave reasonable-looking analyses in Scrutinize Remote > Raw Remote but no decode. I thought you might like to know this.

Posted: **Mon Apr 19, 2021 7:34 am**

I wrote above:

I tried using IrScrutinizer but could not get it to decode even the valid X10.n signals from the S3F80 executor.

With the Arduino, at least, this was due to the settings I had on the Options tab. With a change of settings I now have it decoding X10.n reliably on both Windows and Linux with the Arduino device. I haven't repeated tests with the Widget, as I consider your Arduino device to be the most reliable of the devices supported by IrpScrutinizer and am happy that this is working now with that device.

Posted: **Thu Jun 10, 2021 6:41 am**

I have been looking at Nokia32 signals in order to understand the three toggle modes that the Nokia32 executor (PID=0173:1) offers. The High X-bit can be set to Constant, Toggle or Release. The meanings of Constant and Toggle are obvious but I did not understand Release. Examination of the executor code suggested to me that in Release mode the High X-bit was constant until the key was released, when a final frame was sent in which this bit was set to 1, regardless of what its value was in the earlier frames.

I wanted to verify this and have used both IrScrutinizer and IRScope to examine IR signals sent by the executor. I found that IRScope showed what I would expect, but I cannot make sense of the equivalent output from IrScrutinizer. Here is a link to a screenshot from IRScope:

https://imgur.com/v8YKuZA

It shows that the signal decodes with D=38, S=112, X=38, F=5 with the initial frame and 5 copies having T=0. The final frame shows as a separate decode, differing only in having T=1, as I expected. The displayed IRP form shows that the 32 bits of the initial signal are

A=0b 00100110 01110000 0 0100110 00000101

where I have parsed it into the 5 parameters D, S, T, X, F according to the IRP for Nokia32. These are the correct binary forms for the decode values. The analysis for the second signal differs only in having T=1.

IrScrutinizer also analyzes the signal as several repeats of one frame followed by a different frame, giving the decode again with D=38, S=112, X-38, F=5 and T=0, though the final frame shows as "UNDECODED". Here is a link to a screenshot:

https://imgur.com/7S3Hvov

It gives a single analysis of both frames but this time with binary forms

A=0b111010101100010011101100011010
B=0b111011101101011011101000011010

I am unable to parse these into anything corresponding to the parameter values. Am I misunderstanding the output or is there a bug here? Another comment is that IRScope allows one to set the analyzer output to base 4, prefix 0q. IrScrutinizer does not support base 4. I know this is not standard but it is very convenient in protocols such as this which encode bits in pairs.

Posted: **Thu Jun 10, 2021 11:14 am**

Further to my post above, I have tried to get IrScrutinizer to recognise the release form of Nokia32 by adding the following protocol into IrpProtocols.xml:

Code: Select all

    <irp:protocol name="Nokia32_release">
        <irp:irp>
            <![CDATA[{36k,1p,msb}<6,-10|6,-16|6,-22|6,-28>([][T=0][T=1],15,-10,D:8,S:8,T:1,X:7,F:8,6,^100m)+[D:0..255,S:0..255,F:0..255,X:0..127]]]>
        </irp:irp>
        <irp:documentation xml:space="preserve">A version of the Nokia32 protocol that sets T=0 except for the last frame, which has T=1.
        </irp:documentation>
        <irp:parameter name="absolute-tolerance">50</irp:parameter>
        <irp:parameter name="relative-tolerance">0.04</irp:parameter>
        <irp:parameter name="uei-executor">0173:1[D,S,X,2;F]</irp:parameter>
    </irp:protocol>

But whatever I do with prefer-over entries, I cannot get it to distinguish between Nokia32 signals with T=0 that have the final T=1 frame (which I want to be Nokia32_release) and ones without (that should just be Nokia32). Both types of signal decode as whichever is set as preferred. If Nokia32 is preferred, if I go to the Generate tab, generate a Nokia32_release signal and send it to Scrutinize Signal, it still shows as Nokia32 with the final frame shown as "UNDECODED", rather than as Nokia32_release. As a test that the signal is OK, if I export it as a .ict file and load it into IRScope, it gives the two decodes of T=0 followed by the T=1 final frame. So I believe the IRP is OK.

Is there any way to get the two signal types distinguished?

Posted: **Fri Jun 11, 2021 1:57 am**

First of all, I prefer to work with IrpTransmogrifier from the command line. Not all possibilities in IrpTransmogrifier are present in IrScrutinizer, as will be illustrated below.

I put your protocol into IrpProtocols.xml, and everything worked as expected.

Code: Select all

$ irptransmogrifier -c src/main/resources/IrpProtocols.xml render --name '{D=38, S=112, X=38, F=5}' nokia32_release --raw --decode
Freq=36000Hz[][417,278,167,278,167,611,167,444,167,611,167,444,167,778,167,278,167,278,167,278,
167,611,167,444,167,611,167,278,167,278,167,444,167,444,167,89361]
[417,278,167,278,167,611,167,444,167,611,167,444,167,778,167,278,167,278,167,611,
167,611,167,444,167,611,167,278,167,278,167,444,167,444,167,89028]
Decode succeeded!

(Long line broken for Rob-friendliness

.) The --decode argument makes IrpTransmogrifier test-decode the signal it has just rendered.

But here is the catch that bothered you:

Code: Select all

$ irptransmogrifier -c src/main/resources/IrpProtocols.xml  render --name '{D=38, S=112, X=38, F=5}' nokia32_release --raw -# 4 | \
   irptransmogrifier -c src/main/resources/IrpProtocols.xml decode --all --input -
        Nokia32: {D=38,F=5,S=112,X=38}, beg=0, end=143, reps=4 {UNDECODED. length=36}
        Nokia32_release: {D=38,F=5,S=112,X=38}, beg=0, end=179, reps=4

(The first part generates a Nokia32_release with 4 repetitions, then the second part decodes the just computed signal; the option --all discards all prefer-overs.) So in the first decode, it stops after the 4 T=0-sequences. However, there is an option --recursive, that calls the decoder again there:

Code: Select all

$ irptransmogrifier -c src/main/resources/IrpProtocols.xml  render --name '{D=38, S=112, X=38, F=5}' nokia32_release --raw -# 4 | \
   irptransmogrifier -c src/main/resources/IrpProtocols.xml decode --all --input - --recursive
        Nokia32: {D=38,F=5,S=112,X=38}, beg=0, end=143, reps=4 {Nokia32: {D=38,F=5,S=112,T=1,X=38}, beg=144, end=179, reps=1}
        Nokia32_release: {D=38,F=5,S=112,X=38}, beg=0, end=179, reps=4

which, I think, is exactly what you want. --recursive is not the default, because it sometimes generates output that is really hairy...

BTW, you can request the output in any basis between 2 and 36:

Code: Select all

$ irptransmogrifier -c src/main/resources/IrpProtocols.xml  render --name '{D=38, S=112, X=38, F=5}' nokia32_release --raw -# 4 | \
   irptransmogrifier -c src/main/resources/IrpProtocols.xml decode --all --input - --recursive --radix 4 
        Nokia32: {D=212,F=11,S=1300,X=212}, beg=0, end=143, reps=4 {Nokia32: {D=212,F=11,S=1300,T=1,X=212}, beg=144, end=179, reps=1}
        Nokia32_release: {D=212,F=11,S=1300,X=212}, beg=0, end=179, reps=4

Both --recursive and radix different than 2,8,10,16 are presently not supported in IrScrutinizer. Presently...

Finally, I would prefer the name "Nokia32_endsequence" (for example) over "Nokia32_release", because the latter makes you think of software releases instead of key releases.

Posted: **Fri Jun 11, 2021 4:58 am**

Many thanks. I will experiment with this in RMIR. I'm not actually concerned by what IrScrutinizer does, as the real aim was to get RMIR to make the distinction in decoding learned signals. It was after I could not get that to work as I wanted that I tried IrScrutinizer. I am happy with your name change, I just went with the option name in the executor, even though I had no idea what it meant until I tried my testing

.

I take it that you will reply later about the strange binary decode described in my earlier post.

Posted: **Fri Jun 11, 2021 6:32 am**

mathdon wrote: I take it that you will reply later about the strange binary decode described in my earlier post.

Sorry, to me it is unclear what is unclear.

Posted: **Fri Jun 11, 2021 10:36 am**

Barf wrote:Sorry, to me it is unclear what is unclear.

The correct binary decode of the signal concerned, in its IRP analysis, is that given by IRScope, namely

A=0b 00100110 01110000 0 0100110 00000101

where the parsing is mine, corresponding to the parameters D, S, T, X, F but IrScrutinizer gives

A=0b111010101100010011101100011010

which I cannot relate to the parameter values. Is this a bug or just my misunderstanding of your analyzer output?

Posted: **Fri Jun 11, 2021 11:37 am**

mathdon wrote:Is this a bug or just my misunderstanding of your analyzer output?

It is a misunderstanding. Note that the decoding is correct. The analyzer tries to "model" the sequence; approximately 10 different "models" (subclasses of org.harctoolbox.analyze.AbstractDecoder) are tried, and the "simplest" is considered the answer ("most powerful unfalsified model"...). So it is all but guaranteed to produce a result compatible with the "true" decode. (Try the analyzer option --all just for the fun of if.) Moreover, the Nokia32 protocol with its BitSpecs <6,-10|6,-16|6,-22|6,-28> cannot be successfully decoded with the default parameters absoluttolerance = 100, relativetolerance=0.3. Note that IrpProtocols.xml give them the protocol specific values 50 and 0.05 respectivelly. If you try to "analyze" with those parameters you may get more what you expect.

Posted: **Sat Jun 12, 2021 5:58 am**

Many thanks. Setting the tolerances solved the problem. I now have RMIR distinguishing between learned signals for Nokia32 and Nokia32_endframe (as I have now named it - is that OK?) and also showing the analysis correctly. I also found that RMIR options for radix include 4, displaying values with 0q prefix, so I must have asked you about that a long time ago and forgotten

.

So finally I think I have resolved everything that came to light in my recent testing. I am surprised how much crept out of the woodwork

that I had never noticed before, and though much of it is esoteric in that it affects only one or two of the many protocols, I needed to solve it all for my own personal satisfaction, if for no other reason.

I still need to do another round of testing to make sure the fixes don't mess up anything that already worked properly, but I really don't think any more issues will come to light. I should then be able to post an rmProtocols.xml that is ready for incorporation into your LTS IrpTransmogrifier.

Posted: **Mon Jul 05, 2021 3:40 am**

Version 2.3.1 of IrScrutinizer has been released, available here.

This version has many small improvements and bug fixes. The most visible change is that the IRDB importer (the web site irdb.tk has ceased to exist) has been replace by the more powerful tool RemoteLocator, available under the "Import" pane. This tool can import files from the GitHub-based IRDB repository, Lirc-files from the official Lirc-files repository, my "toy" GirrLib. It also allows for browsing of the JP1-master file content, which cannot be imported directly, but downloaded with the user's browser.

The RemoteMaster import and export has been removed. The reason is that the current RMIR has a vastly superior Girr import- and export-facility (thank you Graham!), making the (partial) import and export from IrScrutinizer useless.

Release notes:

Code: Select all

Version 2.3.1, released 2021-07-04.

* If possible, use xdg-open instead of java.awt.Desktop. #433.
* Add basis 4 option to the analyzer. #432.
* Replace IRDB data base by RemoteLocator- #429.
* Girr importer now imports also Remotes, CommandSets and Commands. #420
* Misc bugfixes (#403, #407, #412, #414, #417, #421, #430).
* interpretString: Robustness fix. #407.
* Remove RemoteMaster import and export. #400.
* Say "Render" instead of "Generate". #402.
* Arduino export issues: #414.
* Support HTML in help popups. Resolves #159.

JP1 Remotes

IrScrutinizer: capturing, generating, analyzing, import, exp