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: Prototype IR function in RM
Goto page Previous  1, 2, 3 ... 57, 58, 59
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1795
Location: Pittsburgh, PA

                    
PostPosted: Sat Mar 28, 2015 9:35 pm    Post subject: Reply with quote

Liz asked me to check in on the byte at $615.

The unextended remote uses this byte to carry the VPT status and probably some other bits. I set it by default in the extender to $00 since the extender re-uses that register to allow the user to decide if a long-press of setup deactivates the extender or if the long-press of setup changes the backlight state. (I don't remember which bit is used)

So changing that value to be something else in the RDF (assuming you hit the right bit) will change the behavior of a long-press of setup by default.

(and yes, I do something similar on the 15-100 to allow you to get into the built-in setup routine to change the clock)


When I migrated to the 3.xx version of the extender I think I took the key move that was assigned to a non-key out and just did the long-press of setup. I could certainly encode another bit into the VPT flag to determine if the Long press is disabled (or potentially another way) if that's an issue.

As for the fixed data not matching, I guess we could take out that line in the RDF that has fixed data for $615. The extender builds a $00 into it by default (I believe, I have to go look at the code) so that'll carry into the hex and rmir file when it's generated.


Finally, these extenders are built from the same source but they are not identical. The source has a tremendous amount of conditional assembly in it to allow me to build them all at once. On the 15-100 and the OCAP I build in the code to check to do special things because I'm building those extenders. However the bulk of the code that does the heavy lifting for the extenders is identical which allows me to release new versions if someone discovers a bug. (since all of them were derivatives of the original Atlas extender)
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Mon Mar 30, 2015 9:09 am    Post subject: Reply with quote

unclemiltie wrote:
So changing that value to be something else in the RDF (assuming you hit the right bit) will change the behavior of a long-press of setup by default.

I am not changing anything in the RDF. There is no issue. I have changed RMIR (in the next build) so that fixed data only applies to bits not affected by settings. So for bit $615, bit 7 is controlled by the LongPress setting and its default is as specified in that setting. Bits 0-6 are controlled by the fixed data, both in testing current data against the RDF and in changing it to the RDF fixed data values if there is a difference. The two will therefore no longer conflict.

There is, however, an inconsistency in the RDF over the default value of bit 7 of $615 for the OCAP extender v3.02. The LongPress setting has a default of 1 (deactivate) for this bit, but the fixed data sets this bit to 0 (BL Toggle). Now that the conflict is resolved, the default will be taken from the setting, i.e. deactivate. Is this what you want?

When you create RDFs for v3.03 of the Common Extender, could you please start from the RDFs that are here in the SVN repository. Dave (3FG) has been rationalising protocol variant names to prevent present and future conflicts between home-grown executors and UEI ones and this has involved updating a large number of RDFs.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Mon Mar 30, 2015 9:34 am    Post subject: Reply with quote

ElizabethD wrote:
On 6131 I have a case of an existing device (Sangean tuner) using Aiwa protocol 005E hacked by Rob, but I retained its PID (used paste into .rmir file after RMIR objected to it). Works fine.
Now I want to add an Aiwa device which normally uses a standard Aiwa protocol.
I can find no way in RMIR to add this device without messing with changing PIDs and parameters.

Ah, I thought, once I understood the problem. There is a way. Use the "Import Raw" button in the Device Upgrade Editor to import the upgrade in exactly the same format as used for IR.exe, i.e. that given by the Output panel of RM. That should work.

Well, SHOULD is the operative word. It turns out that "Import Raw" has not been fully implemented and it balks at the KeyMoves entries in your raw upgrade. Moreover, it still has a problem with PID conflicts. I am working to put both of these right, as I think this should provide the route for doing what you want.

On the more general question of RMIR allowing "illegalities", no, that is not possible. IR.exe just manipulates the data of the EEPROM area without attempting to interpret it, so you can do anything, without regard for consistency. It is left to the remote to interpret the data (or to foul up if it makes no sense). RMIR interprets it and reconstructs it, so consistency is enforced (apart from bugs Wink ). What you are asking in the present case is not inconsistent or "illegal", it is just to use the custom protocol for PID 005E that is already present in the remote instead of the built-in protocol. The .rmdu file specifies the protocol variant to use, so you get a conflict. The raw upgrade just specifies the PID and lets the remote, or RMIR, work out the version to use. This is why IR.exe, and "Import Raw", can achieve something that the .rmdu file cannot.

Watch this space. A new version for you to test will be along shortly.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Wed Apr 01, 2015 12:37 pm    Post subject: Reply with quote

mathdon wrote:
Watch this space. A new version for you to test will be along shortly.

Here it is, build 19 of RMIR v2.03 Alpha 28. For more about what is new, please see this post.
_________________
Graham
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2348

                    
PostPosted: Wed Apr 01, 2015 11:00 pm    Post subject: Reply with quote

Very Happy Very Happy Very Happy
Build 19 is great. Not only I can now add a device with somewhat conflicting protocol, but the Import Raw button and process is now working for the old upgrades that required it. It now works like in IR pasting any odd protocol from Notes in KM.
THANK YOU, Graham for all your very hard work. The result is a wonderful and very useable system.
Thanks also for your explanations so patiently delivered over time.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Wed Apr 15, 2015 8:06 am    Post subject: Reply with quote

At long, long last I have now made an official release of RMIR v2.03. This is the first build. Please see this announcement, for details, which should be carefully read before installing the software.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Sat Nov 12, 2016 1:31 pm    Post subject: Reply with quote

After a substantial period in development, I have now made an official release of RMIR v2.04. It is build 9, as there were eight earlier versions for development purposes. Please see this announcement for details.
_________________
Graham
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, 3 ... 57, 58, 59
Page 59 of 59

 
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