JP1 Remotes

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

This is a raw download of the RF working and the not working state:
https://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!

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.

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.

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

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.

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!

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.

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

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.

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.

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!

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 3. I think the two following lines will be or something like this with even more 00's. Replace those lines by 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.

Hey great, that did the trick! So I think we can consider this thing fixed now!
Great work (again) and big thanks!!

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.

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 ( https://www.hifi-remote.com/forums/dload ... e_id=25048 ) but that didn't work.