JP1 Remotes

Posted: **Sun Sep 01, 2019 11:31 am**

What problem am I addressing? Constructing a set of values for the device parameters of an executor (in protocols.ini) from a set of learned signal decodes (from IrpTransmogrifier) of one or more protocols that are all supported by that executor. In my Sony 12/15 example the relevant lines in its protocols.ini entry are:

DevParms=Device 1=0,Force Sony15:bool,Device 2=[0],Force Sony15:bool
CmdParms=Device:0|1,OBC=0

Consider the decodes

Sony15 D=26 F=88, Sony12 D=1 F=67, Sony12 D=1 F=72

which are the first three in the test set I was using. Initially the user values of the DevParms and CmdParms are all null. The first two decodes can each be generated by setting the first two parameters, giving (26,1,null,null) and (12,0,null,null) but these are inconsistent, so the second needs to go into the second parameter pair, giving (26,1,12,0). The third decode is consistent with this. The command parameters for the three signals are (0,88), (1,67), (1,72).

The additional assignment X=D<32 (thank you for the simplification, also I mistyped it in my earlier message) needs a name, X, as it is referenced in the executor parameters. The executor parameters do not need names, just values, so they are expressions rather than assignments. Indeed, using the parameter names from protocols.ini would just make things more difficult, as the RMIR code references the parameters by their position in the DevParms and CmdParms lists, not by their name. I accept that I could achieve this without by notation extensions, but I find:

[D?0,X?0,D?1,X?1;??,F]

simpler to write and more readable than

[N=0?D: (-1),N=0?X: (-1),N=1? D: (-1),N=1?X: (-1);N,F]

which would have the same effect for N=0,1 as a negative value could be treated as equivalent to null. But also I would have to add an assignment to N into the list of assignments passed to the evaluator and I see no way of knowing what values of N are valid (without preprocessing the expression list

).

There can be more than one element <irp:parameter name="uei-executor">: it is up to subsequent processing to select one candidate.

Yes, I intend to let the user choose the executor if there is more than one that is compatible with the selected learned signals and the remote in question.

I really doubt that a preprocessor is a sensible solution.

Why? I have implemented it and tested it robustly and it does exactly what I want. I would accept that it might not be the best solution, but I have no idea why it should be considered not a sensible one. I appreciate you offering an alternative, but at present I still prefer mine.

Finally, thank you for your comments on CDATA, < etc. These are very helpful as I have very little familiarity with XML and your own extensions of the IRP notation such as the conditional expression.

Posted: **Sun Sep 01, 2019 4:08 pm**

Here is a separate question. I have been using IrpTransmogrifier to create pronto to import into RMIR as learned signals for testing. I find that I cannot generate G.I.4DTV signals with D>3, yet the protocol supports the range 0..7. I have tried changing the allowed range to D:0..7 in the entry and it will then generate the signals, but I don't know if they are correct as it will not decode them. Only the G.I.4DTVnoCheck decode is found, yet for values of D<4 it gives both the normal and the noCheck decode. Is this easily fixable?

Edit: DecodeIR shows that with the range changed to D:0..7, the signals generated ARE correct, but I still need IrpTransmogrifier to decode them, preferably showing the 3-bit D value correctly.

Posted: **Mon Sep 02, 2019 4:08 am**

In case there is no simple solution to the G.I.4DTV issue, I have a work-around. In my copy I have added an extra protocol:

Code: Select all

<irp:protocol c-name="GI4DTVhi" name="G.I.4DTVhi">
        <irp:parameter name="uei-executor">00A4</irp:parameter>
        <irp:parameter name="prefer-over">G.I.4DTVnoCheck</irp:parameter>
        <irp:irp><![CDATA[{37.3k,992}<1,-1|1,-3>(5,-2,F:6,D:2,C:4,1,-60)*{C=~(((#p(F&25) + #p(D&5))&1) + 2*((#p(F&43) + #p(D&7))&1) + 4*((#p(F&22) + #p(D&7))&1) + 8*((#p(F&44) + #p(D&6))&1))}[D:0..3, F:0..63]]]></irp:irp>
         <irp:documentation>This is a moderately robust protocol, but <A href="#pspurious">spurious decodes</A> are still possible. This corresponds to the G.I.4DTV protocol for Unit (device) numbers from 4 to 7, with the value of D being four less, so in the range 0..3.  The check sum C is a Hamming Code, which can correct single bit errors. The top bit of the 3-bit device number is encoded in the check sum. See <a href="https://www.hifi-remote.com/forums/viewtopic.php?p=103934#p103934">forum thread</a>.</irp:documentation>
    </irp:protocol>

Perhaps it should be set as decode-only if the range of D for the normal G.I.4DTV is changed to 0..7, but I don't understand what decode-only means. It does not seem to stop the render operation from working.

A similar issue arises with DirecTV. The entry notes say "There are six variants of the DirecTV protocol, distinguished in RemoteMaster by the parameter "Parm" on the Setup page. The Parm value is shown in the Misc field of DecodeIR." Your IRP corresponds to the default case Parm=3 and I presume, without testing, that this is the only case that IrpTransmogrifier will recognise. I would like all six cases to be recognised, with the Parm value identified. My view is that if this means six protocols rather than one, then so be it. I presume the differences between the six cases are sufficient for IrpTransmogrifier to be able to distinguish between them. If not, that is a separate issue.

Finally a further thought on the notation/preprocessor question. There is another way of using pure IRP notation without a preprocessor. Indeed, it was my first thought, and that is to list the alternative parameter expressions explicitly. This would be, for Sony15 in the Sony 12/15 case:

Code: Select all

<irp:parameter name="uei-executor"><![CDATA[00CA{X=D<32}[D,X, , ;0,F| , ,D,X;1,F]]]></irp:parameter>

However, I then realised that I could have a more concise notation that expanded into this with a preprocessor:

Code: Select all

<irp:parameter name="uei-executor"><![CDATA[00CA{X=D<32}[D?0,X?0,D?1,X?1;??,F]]]></irp:parameter>

I prefer this for several reasons. It generally is more concise, especially when the number of alternatives increases (such as the six pairs in Denon-K rather than the two here), and it shows the relationship between the choice command parameter and the alternative selected. It is also easier to compose when updating the database file from the protocols.ini entry, as there is a direct correspondence between the parameters in protocols.ini and those in the uei-executor entry. I even think that its meaning is more intuitive, in that it shows what all the slots are for in one list and the use of a question mark to indicate an option seems natural. I realise that this is a matter of opinion, though, and hope we may agree to differ on its intuitiveness.

Posted: **Mon Sep 02, 2019 1:55 pm**

G.I.4DTV: I see that I have misunderstood what other people, have written, including the documentation snippet that I have cut-n-pasted obviously without understanding it

As you write, rendering is trivial, but decoding is a completely different ballpark. With the notation in IrpProtocols.xml, the equation (i.e. the "=" has the mathematical meaning, not an assignment, nor a comparison)

C= ((#(F&25) + #(D&5))&1) + 2*((#(F&43) + #(D&7))&1) + 4*((#(F&22) + #(D&7))&1) + 8*((#(F&44) + #(D&6))&1) % 16

with C and F given has to be solved with respect to D. Without hard soldering anything in code... Let me see...

I don't understand what decode-only means. It does not seem to stop the render operation from working.

Sorry, I just see that I forgot to implement it. It is supposed to prevent some protocols from being rendered, like protocols that represent incomplete or erroneous decodes. Thanks for bringing it to my attention.

I will return on the other issues.

Posted: **Tue Sep 03, 2019 5:14 am**

This is just a comment made as I am working through IrpProtocols.xml. You have a protocol called Ortek whose IRP shows it to be NEC-like. Protocols.ini has an executor called Ortek (Official) that sends signals that are nothing like NEC. They are instead similar to OrtekMCE, both having an IRP that begins roughly

Code: Select all

{39.0k,490}<-1,1|1,-1>(4,-1,

with the values in braces differing only slightly between Ortek (Official) and OrtekMCE. Where did your Ortek IRP come from? Could it possibly be Onkyo, which protocols.ini says is NEC-like but for which I have no further details?

Posted: **Fri Sep 06, 2019 2:45 am**

Sorry for the delay, been busy...

mathdon wrote:This is just a comment made as I am working through IrpProtocols.xml. You have a protocol called Ortek whose IRP shows it to be NEC-like. Protocols.ini has an executor called Ortek (Official) that sends signals that are nothing like NEC. They are instead similar to OrtekMCE, both having an IRP that begins roughly
Code: Select all
{39.0k,490}<-1,1|1,-1>(4,-1,
with the values in braces differing only slightly between Ortek (Official) and OrtekMCE. Where did your Ortek IRP come from? Could it possibly be Onkyo, which protocols.ini says is NEC-like but for which I have no further details?

As written in the documentation string, that protocol comes from this thread. The IRP form is the one given in 3FG's post from Dec 06, 2013. I have no personal experience with it, nor preferences. I will be happy to accept any sensible changes.

A similar issue arises with DirecTV. The entry notes say "There are six variants of the DirecTV protocol, distinguished in RemoteMaster by the parameter "Parm" on the Setup page. The Parm value is shown in the Misc field of DecodeIR." Your IRP corresponds to the default case Parm=3 and I presume, without testing, that this is the only case that IrpTransmogrifier will recognise. I would like all six cases to be recognised, with the Parm value identified. My view is that if this means six protocols rather than one, then so be it. I presume the differences between the six cases are sufficient for IrpTransmogrifier to be able to distinguish between them. If not, that is a separate issue.

The modulation frequency is not parametrized in the IRP, so different protocols are needed. Practically, "not every" captures are very accurate when it comes to identify frequency. Parameterizing the leadout is "in principle" easy, but in practice a hairy thing: The capturing device only detects how long no activity has been registered, not how long the leadout is supposed to be. Users always tend to complain like "why does this signal not decode as xxx". For these reasons, IrpTransmogrifier considers all trailing durations > minLeadout (which is a user settable parameter) to be acceptable as leadout. I am pretty sure DecodeIR does something similar (except that it is neither settable nor documented...). Having said that, I am open for suggestions.

G.I.4DTV issue: Still working on it. I will likely come up with a solution soon.

Notation for executors: Will come back in a later post.

Posted: **Fri Sep 06, 2019 10:08 am**

Many thanks for the latest info, and also for v1.1.0 as IrpDatabase.getProperties(..) was missing from v1.0.1, as I discovered when I came to need it.

I hope you are reconciled to my notation extensions to describe Protocols.ini device and command parameters, as I have now finished updating my copy of IrpProtocols.xml using it. I will post it for you to look at if you wish, but was waiting to do that till it is fully incorporated into RMIR code in case any fine tuning is needed. As one more comment on this issue, I would say that IRP notation was not designed to handle descriptions of the parameters used in combo protocols, which is what my extensions are designed for. Just try describing the parameters of Panasonic Mixed Combo (001F:8) in standard IRP notation. Even my original extensions won't cope with this one, so I have needed to add a little further syntax to do so. That's one bit of fine tuning that I haven't yet added into IrpProtocols.xml, though.

If you really don't like my extensions, there is no reason why RMIR cannot have a version of IrpProtocols.xml that uses it while IrpTransmogrifier retains the original version, but I hope that will not be necessary.

Posted: **Mon Sep 09, 2019 8:59 am**

Sorry for the delay.

G.I.4DTV issue: I am afraid that trying to fix the problem has revealed some problems that I would like address with a considerable refactoring of the equation solving engine. For the meantime, I have checked in some half-baked fixes: The protocol "G.I.4DTV" is essentially the old one. Renders D in interval 0..7; since it does not decode completely, marked decodable=false. There is also the decoding protocol G.I.4DTV0123 which produces decodes with D=0..3, and G.I.4DTV4567 which decodes signals with D between 4 and 7, but reports them as 0 to 3. Sorry for that.

Changes are available in the continuous build.

Posted: **Mon Sep 09, 2019 12:28 pm**

To the mapping to executors:

First, I have extended IrpTransmogrifier so it is possible to have XML fragments as content of the parameter element, see examples below. Don't know if that is something that you would like to take advantage of.

mathdon wrote: What problem am I addressing? Constructing a set of values for the device parameters of an executor (in protocols.ini) from a set of learned signal decodes (from IrpTransmogrifier) of one or more protocols that are all supported by that executor.

So, is the executor already selected? I think of it differently:

Given a set of parametrized signals, find (if possible) one executor and its parameter assignment, that enables to generate them all.

I envision to solve this in two steps: First, for all signals, find the executers, and their possible parameter assignments (see the Sony example below, where it is two alternatives). Secondly, try to combine these sets together, to find one executor and one parameter assignment that will satisfy the requirements. This is not just a set intersection, as the Sony example below shows.

Of course, an alternative approach may be to instead seach through the possible executors, to see if there is one that can satisfy all the requirements. Possibly that is more of your approach?

For the first step, all protocols need to know all executors that are candidates for it, which can be expressed with the <irp:parameter name="uei-executor"> element. For example, the NEC1 entry can be like

Code: Select all

      <irp:parameter name="uei-executor" type="xml">
            <rm:deployment executor="NEC1" pid="00 5A">
                <rm:assignment target="Device">D</rm:assignment>
                <rm:assignment target="Sub_Device">S</rm:assignment>
                <rm:assignment target="OBC">F</rm:assignment>
                <rm:assignment target="hex">~OBC:-8</rm:assignment> <!-- strictly speaking redundant, while RM knows this -->
            </rm:deployment>
        </irp:parameter>
        <irp:parameter name="uei-executor" type="xml">
            <!-- Alternative executor for the same protocol -->
            <rm:deployment executor="NEC1 Combo" pid="00 B6">
                ...
               
            </rm:deployment>
        </irp:parameter>

This means that for that protocol there are (at least) two executors: NEC1 (00 5A) and NEC1 Combo". The first executor has the parameters (for example as defined in protocols.ini) "Device", "Sub device", and "OBC". The three rm:assignment elements tell how to give them values from the IRP protocol parameters. The next rm:assignment element is strictly speaking superfluous, since RM knows how to compute hex (from OBC) but if desired, the line above shows how to do it with IRP. Similarly, RM knows how to compute the device parameters from the ones given; if it is desirable to do it here, it can go like this:

Code: Select all

<rm:FixedData><<![CDATA[ 
NEC2_for_repeat_group << 19| send_2X_then_dittos << 17 | specialRecordkey << 16 | (~Device:-8) << 8 | ~Sub_Device:8
]]></rm:FixedData>

In this case, the second step, combining the signals, is now quite simple, since any signal fixes the choices that can be made: they can be combined if and only if device and subdevice are the same.

The second <irp:parameter name="uei-executor"> declares another alternative executor for the said protocol.

For Sony 12 and Sony 15 it is slightly more complicated:

Code: Select all

    <irp:protocol c-name="Sony12" name="Sony12">
        <irp:parameter name="uei-executor" type="xml">
            <rm:deployment executor="Sony 12/15">
                <rm:hex bits="8"><![CDATA[((Device << 7) | OBC):-8]]></rm:hex>
                <rm:alternative name="first">
                    <rm:assignment target="Device_1">D</rm:assignment>
                    <rm:assignment target="Device">0</rm:assignment>
                </rm:alternative>
                <rm:alternative name="second">
                    <rm:assignment target="Device_2">D</rm:assignment>
                    <rm:assignment target="Device">1</rm:assignment>
                </rm:alternative>
            </rm:deployment>
        </irp:parameter>
        <irp:irp><![CDATA[{40k,600}<1,-1|2,-1>(4,-1,F:7,D:5,^45m)*[D:0..31,F:0..127]]]></irp:irp>
        <irp:documentation/>
    </irp:protocol>
    <irp:protocol c-name="Sony15" name="Sony15">
        <irp:parameter name="uei-executor" type="xml">
            <rm:deployment executor="Sony 12/15">
                <rm:hex bits="8"><![CDATA[((Device << 7) | OBC):-8]]></rm:hex>
                <rm:alternative name="first">
                    <rm:assignment target="Device_1">D</rm:assignment>
                    <rm:assignment target="Device">0</rm:assignment>
                </rm:alternative>
                <rm:alternative name="second">
                    <rm:assignment target="Device_2">D</rm:assignment>
                    <rm:assignment target="Device">1</rm:assignment>
                </rm:alternative>
            </rm:deployment>
        </irp:parameter>

The protocol Sony12 declares (at least) one executor. To deploy this, there are two alternative parameter assignments. The same goes for Sony15. Each one of a set of sony12 and sony15 signal has a selection; the problem (i.e. that executor is a candidate) can be solved if there is a assignment to the executor parameters Device_1 and Device_2 compatible with all signals.

Step2 requires a special Java program/function/class to compute a compatible parameter.

Well, your solution is probably different. Looking forward to look at it. Hope it is something that can be used for having IrScrutinizer generate RM files. That is more important than

If you really don't like my extensions

...

("like" is for Facebook...)

Posted: **Mon Sep 09, 2019 12:36 pm**

Many thanks for your latest info. I didn't see it till after posting to the SVN a first draft of RMIR v2.09 build 1, which incorporates IrpTransmogrifier 1.1.0. The IrpProtocols.xml file that RMIR uses is separate from the one in the included IrpTransmogrifier jar file, which is included unchanged. If you are interested, you can find my IrpProtocols.xml file here.

Posted: **Wed Sep 11, 2019 3:39 am**

In my testing, I have created Pioneer signals with IrpTransmogrifier render and imported them as learns into an RMIR setup. But IrpTransmogrifier decodes them as NEC2, not as Pioneer. If I switch the decoder to DecodeIR, they decode correctly as Pioneer. I know the two protocols differ only in frequency, but I would at least have expected IrpTransmogrifier to show Pioneer as one of two decodes if not as the unique one. Instead it shows NEC2 as the unique decode. Is this fixable? Here is one of the signals:

Code: Select all

0000 0068 0000 0022 0169 00B4 0017 0017 0017 0044 0017 0017 0017 0044 0017 0044 0017 0017 0017 0044 0017 0017 0017 0044 0017 0017 0017 0044 0017 0017 0017 0017 0017 0044 0017 0017 0017 0044 0017 0017 0017 0044 0017 0044 0017 0017 0017 0017 0017 0044 0017 0017 0017 0017 0017 0044 0017 0017 0017 0017 0017 0044 0017 0044 0017 0017 0017 0044 0017 0044 0017 0636

Posted: **Wed Sep 11, 2019 5:19 am**

Code: Select all

$ irptransmogrifier --frequencytolerance 1000 decode 0000 0068 0000 0022 0169 00B4 0017 0017 0017 0044 0017 0017 0017 0044 0017 0044 0017 0017 0017 0044 0017 0017 0017 0044 0017 0017 0017 0044 0017 0017 0017 0017 0017 0044 0017 0017 0017 0044 0017 0017 0017 0044 0017 0044 0017 0017 0017 0017 0017 0044 0017 0017 0017 0017 0017 0044 0017 0017 0017 0017 0017 0044 0017 0044 0017 0017 0017 0044 0017 0044 0017 0636
Pioneer: {D=90,F=38}, beg=0, end=67, reps=1

from the API

Code: Select all

decoderParameters.setFrequencyTolerance(1000);

Default frequency tolerance is 2000, interesting in feedback on the "optimal" choice.

Posted: **Wed Sep 11, 2019 12:11 pm**

It's very strange. Your command line setting the frequency tolerance to 1000 works, but if I set the default from the API to 1000, the Pioneer signal says "no decodes". I've got the command line right, as setting it to 2000 returns to decoding as NEC2. Can you see a reason for this odd behaviour?

Posted: **Wed Sep 11, 2019 2:23 pm**

When I tried, it worked with the released version 1.1.0, but there seems to be a problem with the current development build. (Differently put, with 1.1.0 I cannot reproduce the problem.)

If you are using 1.1.0 and the problem persists give me something I can reproduce.

Code: Select all

package javaapplication8;

import java.util.Map;
import org.harctoolbox.ircore.IrSignal;
import org.harctoolbox.ircore.Pronto;
import org.harctoolbox.irp.Decoder;
import org.harctoolbox.irp.Decoder.Decode;
import org.harctoolbox.irp.IrpDatabase;

public class JavaApplication8 {

    public static void main(String[] args) {
        try {
            System.out.println(org.harctoolbox.irp.Version.versionString);
            IrSignal irSignal = Pronto.parse("0000 0068 0000 0022 0169 00B4 0017 0017 0017 0044 0017 0017 0017 0044 0017 0044 0017 0017 0017 0044 0017 0017 0017 0044 0017 0017 0017 0044 0017 0017 0017 0017 0017 0044 0017 0017 0017 0044 0017 0017 0017 0044 0017 0044 0017 0017 0017 0017 0017 0044 0017 0017 0017 0017 0017 0044 0017 0017 0017 0017 0017 0044 0017 0044 0017 0017 0017 0044 0017 0044 0017 0636");
            Decoder.DecoderParameters decoderParameters = new Decoder.DecoderParameters();
            Decoder decoder = new Decoder(new IrpDatabase((String) null));
            Map<String, Decode> sigDecodes = decoder.decodeIrSignal(irSignal, decoderParameters);
            for (Decode decode : sigDecodes.values())
                System.out.println(decode);
            decoderParameters.setFrequencyTolerance(1000.0);
            sigDecodes = decoder.decodeIrSignal(irSignal, decoderParameters);
            for (Decode decode : sigDecodes.values())
                System.out.println(decode);
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}

Posted: **Wed Sep 11, 2019 4:18 pm**

Sorry to have bothered you with this. It turns out that the issue was with one of my uei-executor entries for Pioneer. The command line uses your IrpProtocols.xml, RMIR uses my version with my uei-executor entries. The error in the uei-executor entry was somehow preventing the Pioneer decode showing up, even though IrpTransmogrifier was producing that decode.

On a related matter, the RMIR distribution currently includes two copies of IrpProtocols.xml, one in the RemoteMaster.jar file (which is used when the IrpTransmogrifier command line is run from RMIR) and the other separately in the RMIR installation folder (which is used by RMIR itself). I want to keep RMIR using the file outside the jar, so that it can be updated without rebuilding the jar. Is there a way that the command line can also be made to use this file? It isn't a big issue, but I just feel it is untidy to need to include two copies of the file.

JP1 Remotes

IrpTransmogrifier: new program/library for IRP protocols