JP1 Remotes

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)

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.

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 ). 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.

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.

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.

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.

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.