RMIR Xsight Support

Since EZ-RC has closed down, JP1 is your only option to get these remotes upgrades. We will (eventually) support all remotes formerly supported by EZ-RC, including the Moster Revolution 200.

Moderator: Moderators

Post Reply
CyberSimian
Posts: 90
Joined: Thu Oct 24, 2013 8:10 am
Location: Southampton, UK

Post by CyberSimian »

mathdon wrote:Many thanks for that list. These were in fact the other things I wanted to look at before posting a revised version.
That's great. There is one item that is not on that list, namely files for the Xsight Colour (which are not included in the current package). I have an Xsight Colour, so I created the missing files by copying the ones for the Xsight Touch and then modifying them to apply to the Colour. I put them here:

http://www.xenscape.com/anon/RMIR_files ... Colour.zip

They seem to work correctly, except for the image, which is a straight copy of the Touch, and not an image of the Colour (one will need to be created for the Colour).

-- from CyberSimian in the UK
xnappo
Expert
Posts: 862
Joined: Tue Dec 30, 2003 12:29 pm

Post by xnappo »

CyberSimian wrote:
They seem to work correctly, except for the image, which is a straight copy of the Touch, and not an image of the Colour (one will need to be created for the Colour).

-- from CyberSimian in the UK
Xsight color map and image are here:

http://www.hifi-remote.com/forums/dload ... e_id=11806

It would be a good idea to include this, as well as the RDF clones for the various Color/Touch variations.

xnappo
xnappo
Expert
Posts: 862
Joined: Tue Dec 30, 2003 12:29 pm

Post by xnappo »

Hi Graham,

I realize you may have changes not yet checked in, but I built with the latest source and still have problems with activities.

To reproduce:

1. Open this RMIR file:
http://www.hifi-remote.com/forums/dload ... e_id=12464
2. Add an activity
3. Add a activity power macro
4. Save and close RMIR
5. Open RMIR
6. Open saved .rmir
7. Note that power is missing, and cannot be fixed

Sorry if you already know about this.

xnappo
3FG
Expert
Posts: 3434
Joined: Mon May 18, 2009 11:48 pm

Post by 3FG »

Graham,
It appears that upgrades built with 2.03 Alpha 21 may contain the line

Code: Select all

ButtonIndependent=false
. We see this for the JP1.3 remotes Atlas 3033 and RCRP05B. It isn't clear to me why this line appears, and it seems that RMIR 2.02a isn't able to handle this entry. The symptom is that the setup code in 2.02a is displayed in red, and the upgrade is not actually written into memory.

Is it intended that "ButtonIndependent=false" should work with 2.02a? If not, then it seems that RMDU files built with 2.03 aren't backwards compatible.
mathdon
Expert
Posts: 4725
Joined: Tue Jul 22, 2008 8:53 am
Location: Cambridge, UK

Post by mathdon »

3FG wrote:Is it intended that "ButtonIndependent=false" should work with 2.02a? If not, then it seems that RMDU files built with 2.03 aren't backwards compatible.
Some old remotes, e.g. those based on the Mitsubishi P8/740 processor, can have upgrades that are restricted to a specific device button. The XSight remotes have a separate upgrade for every device button, even for built-in device codes. When saved, both these types of upgrades will have that line in them. RMIR has been able to handle that line for a long time.

It should only occur, however, for remotes capable of supporting such upgrades. It should not be generated for an upgrade created by a remote that does not support such upgrades. If v2.03 Alphas are doing this, it is a bug. However, there may well be an issue with importing a button-dependent upgrade into a remote that does not support them. That may never have been tested, and could be a long-standing bug.

I will look into this.
Graham
vickyg2003
Site Admin
Posts: 7104
Joined: Sat Mar 20, 2004 12:19 pm
Location: Florida
Contact:

Post by vickyg2003 »

This line started appearing in my RDMU's that I created after I installed a 2.03 Alpha21e jar in 8/19/13

So what is the status on this. Is this still a beta/alpha thing? Do I need to go back and update ALL the RDMU files I uploaded after that date?
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
mathdon
Expert
Posts: 4725
Joined: Tue Jul 22, 2008 8:53 am
Location: Cambridge, UK

Post by mathdon »

vickyg2003 wrote:This line started appearing in my RDMU's that I created after I installed a 2.03 Alpha21e jar in 8/19/13

So what is the status on this. Is this still a beta/alpha thing? Do I need to go back and update ALL the RDMU files I uploaded after that date?
I cannot reproduce this behaviour. Please give me specific directions how to create an upgrade containing this line. As what you need to do, that depends on what you use the RMDU files for. I will make the next Alpha version ignore this line for remotes that do not support device-dependent upgrades, but if they are to be used with earlier versions then I am being told that it can cause a problem. How serious that problem is is not clear to me as I can't see that you have reported it before in the six months that it has been happening.
Graham
vickyg2003
Site Admin
Posts: 7104
Joined: Sat Mar 20, 2004 12:19 pm
Location: Florida
Contact:

Post by vickyg2003 »

Hi Graham, pretty easy to create the line since I have it in every single RDMU I created after I updated to 21e.

Open RM from your icon
Create an upgrade,
Save the upgrade,
The upgrade DOES NOT have the line.

Open the upgrade (by double clicking on the RDMU file in windows explorer)
make any change to the file
SAVE
The upgrade has the line

From the same RM session
Do a File New
make an upgrade
Save the file.
The upgrade has the line.
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
mathdon
Expert
Posts: 4725
Joined: Tue Jul 22, 2008 8:53 am
Location: Cambridge, UK

Post by mathdon »

OK, Vicky, I will try that. I had only tried the first stage, since the earlier posts just talked about created upgrades.
Graham
mathdon
Expert
Posts: 4725
Joined: Tue Jul 22, 2008 8:53 am
Location: Cambridge, UK

Post by mathdon »

Guided by Vicky's info I think I have located the code that is causing the erroneous line in RMDU files. For some unknown reason I have been unable to make it run through that code and so have not been able to generate the error, but I think I have corrected it nevertheless.

Please try RMIR v2.03 Alpha 22 Test 3 and let me know whether or not it has resolved the issue. This should also be able to load the affected files into remotes that do not support this line.

This version also includes the latest bugfixes for XSight remotes, thanks to xnappo for his bug reports via PM. It also resolves those issues pointed out here by CyberSimian that concern the RemoteMaster.jar file. I am not aware of any outstanding bugs in this version, so please report any that you find.
Graham
xnappo
Expert
Posts: 862
Joined: Tue Dec 30, 2003 12:29 pm

Post by xnappo »

Thanks Graham,

Definitely getting close.

I didn't have a lot of time before work - but I was able to add all my device-specific macros and they worked.

But... My stupid Lutron upgrade stopped working again! And this is after switching from using one Rob made to the one built in. Will have to dig in deeper. Wish I had an IR widget.

I will also try to find a reproducible sequence to recreate the 'signature mismatch' issue. Can you tell me what addresses in the hex dump it is looking at?

A few other questions:

1. When a macro is bold inside an upgrade, does that indicate that there is a macro on top of an assigned device function?

2. You have mentioned that every key has an upgrade. Is that to say that any key in a device specifies the protocol, parameters and the code for the key? And therefore the device upgrade editor is very much more of a device key assignment editor in this context?

3. The soft key ordering I understand autofills from the bottom - however are the soft1, soft2 etc locations treated as hard locations from a memory point of view? If I have assigned function in an upgrade to soft3 and soft6 (which will result in the remote displaying the bottom two buttons on its own) and then I assign a macro to soft5, is there going to be a conflict on soft5 somehow? I just ask this because a lot of my issues seem to occur when I start messing with the soft buttons.

Thanks!
xnappo
mathdon
Expert
Posts: 4725
Joined: Tue Jul 22, 2008 8:53 am
Location: Cambridge, UK

Post by mathdon »

xnappo wrote:Wish I had an IR widget
Do you realise that they are available once again? Go to TxSat Electronics in the Market Place and follow the widget links.
I will also try to find a reproducible sequence to recreate the 'signature mismatch' issue. Can you tell me what addresses in the hex dump it is looking at?
That's the weird thing. It is not in the hex dump! The signature for an XSight remote is "USB"+the USB Product ID of the remote. It is nothing that RMIR has any control over.
1. When a macro is bold inside an upgrade, does that indicate that there is a macro on top of an assigned device function?
No, it just means that it cannot be edited or deleted in the Buttons table. If you hover the mouse pointer over it you should get a tooltip saying that it can only be edited in the Macros tab. A macro that is not in bold is one that is on more than one button and it can be deleted from the extra button(s) in the Buttons table, but not from its main button.
2. You have mentioned that every key has an upgrade. Is that to say that any key in a device specifies the protocol, parameters and the code for the key? And therefore the device upgrade editor is very much more of a device key assignment editor in this context?
Effectively you are right, but the way it works is a bit different from what that implies. It is every device that has an upgrade, so it is possible to edit the assignments of functions to buttons, and the hex code of functions, even for built-in setup codes. The device upgrade editor also enables you to put functions from one device on to buttons of another, a facility which replaces key moves for these remotes. It also, as mentioned above, allows you to put a macro that is on one device-specific button (remember all macros are device-specific for XSights) also on to any other button of any device. So yes, it is far more powerful than it is for ordinary remotes. This is why there have been so many bugs with it, it really is a big beast :D .
3. The soft key ordering I understand autofills from the bottom - however are the soft1, soft2 etc locations treated as hard locations from a memory point of view? If I have assigned function in an upgrade to soft3 and soft6 (which will result in the remote displaying the bottom two buttons on its own) and then I assign a macro to soft5, is there going to be a conflict on soft5 somehow? I just ask this because a lot of my issues seem to occur when I start messing with the soft buttons.
No conflict. On the remote, they will appear in the order soft3, soft5, soft 6 and due to the autofilling algorithm the effect will be that soft5 will appear where soft3 was and soft3 will be pushed up to the row above. The remote does not reassign the functions to the soft keys starting at soft1, for the remote it is just a display issue. However, I think that if you upload the setup to EZ-RC and download it again, that will reassign the functions. I'm not sure about this, but I think so. My intention is that users of RMIR should never need to go back to EZ-RC and are best advised to avoid mixing uses of RMIR and EZ-RC.
Graham
xnappo
Expert
Posts: 862
Joined: Tue Dec 30, 2003 12:29 pm

Post by xnappo »

Thanks Graham. Knowing some of those details helps a lot.
mathdon wrote: No, it just means that it cannot be edited or deleted in the Buttons table. If you hover the mouse pointer over it you should get a tooltip saying that it can only be edited in the Macros tab. A macro that is not in bold is one that is on more than one button and it can be deleted from the extra button(s) in the Buttons table, but not from its main button.

Hmm. I have deleted those in the upgrade many many times using the delete key. That is bad then? Maybe that is causing some of my issues.

xnappo
mathdon
Expert
Posts: 4725
Joined: Tue Jul 22, 2008 8:53 am
Location: Cambridge, UK

Post by mathdon »

xnappo wrote:Hmm. I have deleted those in the upgrade many many times using the delete key. That is bad then? Maybe that is causing some of my issues.

I didn't realise it was possible to delete them with the delete key :( . Yes, it is likely to cause inconsistency. I will have to stop that from being possible.
Graham
xnappo
Expert
Posts: 862
Joined: Tue Dec 30, 2003 12:29 pm

Post by xnappo »

mathdon wrote:
xnappo wrote:Hmm. I have deleted those in the upgrade many many times using the delete key. That is bad then? Maybe that is causing some of my issues.

I didn't realise it was possible to delete them with the delete key :( . Yes, it is likely to cause inconsistency. I will have to stop that from being possible.
Are there other cleanup tasks that occur when you hit the delete button rather than the key? I have come to the conclusion I need to start over importing and modifying my upgrades. Something must be corrupt in my base setup.

As to the signature failures - I discovered something interesting last night. If I download from the remote, the problem clears up. I can have the remote in a state where it always gives me the warning regardless of what image I am uploading. If I do a download, followed by any other upload it works fine.

When I rebuild this weekend I will try using another computer. Maybe it is something with the USB driver?

xnappo
Post Reply