RMIR Xsight Support

vbs_ · Post by **vbs_** » Sat Oct 07, 2017 11:41 am

Ok, here we go. Remote is an Xsight Touch.

This is a raw download of the RF working and the not working state:
http://www.hifi-remote.com/forums/dload ... e_id=14735

Also I included the protocol.inis I have used.

Another interesting fact: The problem only appears when loading a RMIR file from disk and uploading it.
Downloading from the remote and immediately uploading the data again does not break RF functionality.

Thanks guys!

Post by **mathdon** » Sat Oct 07, 2017 12:12 pm

At a very quick first glance, the only difference seems to be three extra bytes of 00 in the non-working one. More specifically, where the working one has 11 01 81 91, the non-working one has 11 04 81 00 00 00 91.

The 11 is a start tag, the 91 is the corresponding end tag. The byte after the start tag is the length of the following data up to but not including the end tag. So it really is just the three 00's. I'll try to look into why they occur in one and not the other.

Post by **The Robman** » Sat Oct 07, 2017 7:17 pm

vbs, how did you create these files? I was expecting to see *.rmir files, but these are *.bin files and I can't find a way to open them using RMIR. I was hoping to do some experiments with them.

I see in reality that they are just text files, so I can see how Graham compared them. I have tried re-creating them as *.rmir files but so far nothing has worked.

vbs_ · Post by **vbs_** » Sun Oct 08, 2017 3:18 am

I create the files using the function "Raw download" in RM. But I just did it again and created RMIR files also:
http://www.hifi-remote.com/forums/dload ... e_id=14737

Post by **mathdon** » Sun Oct 08, 2017 10:41 am

I have finally tracked down what is happening. The underlying cause is a bug in RMIR that I suspect has been there for a very long time. The bug occurs when you load a .rmir file with a device that uses a protocol that is built in to the remote but is not in protocols.ini. It doesn't matter whether the protocols.ini entry has code for the remote concerned or not. The effect of the bug is that RMIR gets the number of protocol fixed bytes wrong. It is possible that the bug also only affects certain types of remotes. I haven't investigated that far, it was hard enough finding the bug in the first place.

One effect of the bug is that if you upload to the remote from a .rmir file saved from a setup with RF working, the RF will or will not work depending on whether or not protocols.ini has the PID=00FD protocol entry. The same .rmir file loads differently into RMIR when this entry is or is not present. The fact that the bug is in the loading of the .rmir file (not the saving of it, which is OK) also explains why the RF works OK if you just download and then upload, without going through saving to disk.

I will fix this in the next development build, but that will not be for a few days as I have other things to fix in it as well. I will leave the PID=00FD entry in protocols.ini, as it is a valid entry, but I would be grateful if you could test that RF works with this new build and with the bad protocols.ini.

vbs_ · Post by **vbs_** » Sun Oct 08, 2017 11:25 am

Nice finding, good work! Sure, I will test it again using the current protocols.ini and your new build as soon as it is available. Again thanks alot!

Post by **mathdon** » Mon Oct 09, 2017 11:49 am

The new build I mentioned above is now posted. It is development build 7 of RMIR v2.05 and includes what I hope is a fix for the .rmir loading bug.

vbs_ · Post by **vbs_** » Mon Oct 09, 2017 12:05 pm

Sorry to say but it does not work

I used your dev-version as you posted it (without replacing protocols.ini) since it seemed like the included one already was a version without the block.

So I tried uploading my previously saved rmir-file but it broke RF functionality.

Also I tried downloading to rmir-file, restarting the program and then uploading it again. But that also broke RF

Post by **mathdon** » Mon Oct 09, 2017 1:01 pm

I'll do some more experimenting and then get back to you on this. I'm sure I've found the bug, I think I just haven't fixed it properly.

Post by **mathdon** » Tue Oct 10, 2017 10:17 am

I wonder if there was something wrong with your testing, with erroneous data carried over into the test that caused it to fail. I have uploaded here a .rmir test file for you. When I load this into RMIR build 7 with a protocols.ini with the [pid: 00 FD] entry removed, it creates data for upload that is identical to the raw_rf_working.bin file you posted. So I cannot see how this can fail to work in your remote.

Please use build 7 with a "bad" protocols.ini to load this .rmir file and upload it to your XSight Touch. If the RF then doesn't work, please do a raw download and post it for me to look at. It must be a raw download, as the data in a normal download has been processed by RMIR and may be affected by any bug in that program.

vbs_ · Post by **vbs_** » Tue Oct 10, 2017 12:07 pm

Ok, it works with your .rmir file but not with mine

Well, I will try to explain what I did now (just to make sure I didn't do something wrong):
- extracted RemoteMaster.v2.05build2.zip to a new folder
- extracted everything but "protocols.ini" from RMIR205build7.zip to the same folder overwriting existing data

So I have the "bad" protocols.ini now in build7, right?
Then:
Uploading YOUR .rmir -> RF works
Uploading MY .rmir -> RF does not work

But after I replaced protocols.ini with the good one then my .rmir works too

So the problem seems also to be my .rmir file. My .rmir file only works with the good protocols.ini, yours also works with the bad one.

Sorry, I think that is also the reason why my yesterday's test failed since my .rmir file was not "right" in the first place.

I hope this makes sense to you

How can I make my .rmir file also a working one (I did some changes on my remote recently). Should I just create a new file download from my remote using build7?

Thanks!

Post by **mathdon** » Tue Oct 10, 2017 1:11 pm

You did nothing wrong, other than upload a .rmir that carried the error. No guarantees, but you can try the following to fix a bad .rmir:

1. Open it with a text editor such as Notepad.
2. Search for the line

Code: Select all

Protocol.name=pid\: 00 FD

3. I think the two following lines will be

Code: Select all

ProtocolParms=129 0 0 0 0 null null
FixedData=81 00 00 00

or something like this with even more 00's. Replace those lines by

Code: Select all

ProtocolParms=129 0 null null
FixedData=81

and save the file.

It should now open in build 7 with a "bad" protocols.ini and give a setup in which RF works when uploaded to the remote. It will of course also do this with a "good" protocols.ini but the acid test is that it does so with a bad one.

Try it and report back, please.

vbs_ · Post by **vbs_** » Wed Oct 11, 2017 11:31 am

Hey great, that did the trick!

So I think we can consider this thing fixed now!
Great work (again) and big thanks!!

unclemiltie · Post by **unclemiltie** » Wed Oct 11, 2017 12:01 pm

just chiming in on the firmware upgrade. Successfully plugged in my Nevo C2 to my mac using RemoteMaster and the upgrade went smoothly and finished pretty quickly.

Great work Graham in figuring this stuff out and getting all of the support in. Now I just need to figure out how I want to use the remote since I'm so used to the JP1.3 remotes with extenders.

michaeljc70 · Post by **michaeljc70** » Thu Feb 22, 2018 5:01 pm

I have several Nevo c2 remotes. I programmed 2 successfully quite a while ago using RMIR (updating firmware with website when it worked). I want to program a 3rd one using the same .mir file. It is not recognizing the remote.

I am using 2.06. I set the remote->interface to CommHID/Auto-detect but still no luck. As I understand it, I can update the firmware from RMIR now. I am trying to do a download before anything to get the firmware updated.

I am foggy if I need any drivers or what else I need to do.

I'm using Windows 10.

EDIT: I tried adding the registry keys from here ( http://www.hifi-remote.com/forums/dload ... e_id=25048 ) but that didn't work.