RMIR: The Next Generation

Post by **mathdon** » Mon Sep 16, 2019 12:06 pm

Barf wrote:I cannot directly relate. Can you please give me something I can reproduce?

I have uploaded build 2 of RMIR v2.09 to the RMIR Development folder which I hope meets this need. The Ortek and Ortek{2} decodes that show the described behaviour are in test file 1. I have also added test files 4 and 5. File 4 has six DirecTV real learns that decode showing the parm value, 0-5, in the protocol name. File 5 has three G.I.4DTV manufactured learns showing decodes to G.I.4DTV0123 and G.I.4DTV04567.

I don't really understand what you have done about G.I.4DTV. It seems to offer no benefit over that of my workaround, which consists simply in adding a second protocol in which the value of C is complemented. This is all that is required to change the supported device values from 0-3 to 4-7.

Barf · Post by **Barf** » Tue Sep 17, 2019 1:13 am

The 10000 meter view (or is it 10000 feet?) is this: There are some fairly serious problems with the "equation solving", so I am working on a refactorization. This will solve the G.I.4DTV problem and others. I really don't care too much of fixes that interfere, or will be obsoleted by this work.

I acknowledge the problem with the extra P delivered and will fix in the context of the refactorization.

mathdon wrote:
Barf wrote:I cannot directly relate. Can you please give me something I can reproduce?
I have uploaded build 2 of RMIR v2.09 to the RMIR Development folder which I hope meets this need. The Ortek and Ortek{2} decodes that show the described behaviour are in test file 1.

I have checked #p92, #p93, and #p97, and IMHO IrpTransmogrifier does the right thing, possible with the exception of the extra P. (DecodeIR's "only start frame" on #p97 appears outright wrong.)

I don't really understand what you have done about G.I.4DTV. It seems to offer no benefit over that of my workaround, which consists simply in adding a second protocol in which the value of C is complemented. This is all that is required to change the supported device values from 0-3 to 4-7.

G.I.4DTV0123 supports D=0,1,2,3 and G.I.4DTV04567 D=4,5,6,7, but the latter reports D off by 4 (e.g. 2 instead of 6). Possibly I did not understand your workaround, but when I tried it it did not produced the expected results.

Post by **mathdon** » Tue Sep 17, 2019 3:20 am

Barf wrote:I really don't care too much of fixes that interfere, or will be obsoleted by this work.

I have no idea what you are referring to. I was not aware of doing anything of this nature. Please be explicit. In any case I will track any updates of yours to IrpProtocols.xml into my version for RMIR, undoing any changes of mine if they have been superseded by yours. You will see that I have already done that with G.I.4DTV even though it seems to me that yours is much more complicated than my workaround without corresponding benefits.

As for my workaround for G.I.4DTV, I have uploaded IrpProtocols_demo.xml. This was an intermediate stage as I was merging your v1.1.1 changes into my RMIR version. When I reached G.I.4DTV I saved this snapshot to keep a version that had my workaround. If you use this in place of the IrpProtocols.xml in the installation folder of build 2 of RMIR v2.09 and open my test file 5, you will see identical results to those of the unmodified build 2 that uses your G.I.4DTV fix. The only difference is in the protocol names, my hi protocol being equivalent to your 4567 one.

Barf · Post by **Barf** » Sat Oct 19, 2019 2:11 am

In RemoteMaster.createAndShowGUI, I suggest moving LearnedSignal.getTmDecoder() to after the evaluation of the -home parameter (goes for setting of rmirSys, rmbIcon, summaryFile too) -- otherwise the -home argument is pretty meaningless.

Post by **mathdon** » Sat Oct 19, 2019 6:38 am

Barf wrote:In RemoteMaster.createAndShowGUI, I suggest moving LearnedSignal.getTmDecoder() to after the evaluation of the -home parameter (goes for setting of rmirSys, rmbIcon, summaryFile too) -- otherwise the -home argument is pretty meaningless.

Done. This will be in the release build.

rsbrux · Post by **rsbrux** » Sat Nov 30, 2019 8:04 am

The first great thing, which will be in RMIR v2.09 build 1, is conversion of learned signals to device upgrade that really works. This feature has been present in RMIR for quite some time now, but hidden on an Advanced menu as it works on only very simple cases. It will now be a permanently visible button on the Learned Signals tab.

Perhaps I didn't read the rest of this thread carefully enough, but in RMIR 2.09 build 6, the button "Convert to Device Upgrade" is only enabled when "IrpTransmogrifier" is selected under "Options / Set IR Decoder". It is no longer available when "DecodeIR" is selected. Is this intentional?

Post by **mathdon** » Sat Nov 30, 2019 5:35 pm

rsbrux wrote:in RMIR 2.09 build 6, the button "Convert to Device Upgrade" is only enabled when "IrpTransmogrifier" is selected under "Options / Set IR Decoder". It is no longer available when "DecodeIR" is selected. Is this intentional?

It is not only intentional, it is necessary. Reliable algorithmic conversion of learned signals to a device upgrade only became possible due to features in IrpTransmogrifier that are not available in DecodeIR.

Vyrolan · Post by **Vyrolan** » Sat Apr 18, 2020 11:58 pm

Wow Graham...you’ve done some serious work here. Much respect for the perseverance and dedication.