JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

RMIR: The Next Generation
Goto page Previous  1, 2
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Mon Sep 16, 2019 1:06 pm    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Tue Sep 17, 2019 2:13 am    Post subject: Reply with quote

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 #92, #93, and #97, and IMHO IrpTransmogrifier does the right thing, possible with the exception of the extra P. (DecodeIR's "only start frame" on #97 appears outright wrong.)

Quote:

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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Tue Sep 17, 2019 4:20 am    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sat Oct 19, 2019 3:11 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Oct 19, 2019 7:38 am    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
rsbrux



Joined: 25 Dec 2015
Posts: 81

                    
PostPosted: Sat Nov 30, 2019 9:04 am    Post subject: Reply with quote

Quote:
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?
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Nov 30, 2019 6:35 pm    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
Vyrolan



Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL

                    
PostPosted: Sun Apr 19, 2020 12:58 am    Post subject: Reply with quote

Wow Graham...you’ve done some serious work here. Much respect for the perseverance and dedication.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control