JP1 Remotes

Rob, by your numbering:
1. That is already in build 4 but I forgot to mention it. Check the menu item "Options > Suppress Messages > Timing summary info" and it won't appear. Build 4 also mentions this as a final line added to that info panel.
2. If you hide the info panel as above, the Timing Summary will be smaller when you first open it. The current constraint is that it shows 30 lines of text in the summary panel on opening, regardless of the presence or otherwise of the info panel. For build 5 I've now made it so that if you re-size the Timing Summary and close it, then it will keep that size when you reopen it in the same RMIR session. Is this sufficient?
3. I've done that for build 5.
4a. There is no "Delete All" button but you can still delete all, as you can make a multiple row selection. Click the top row, scroll to the bottom, hold Shift and click the bottom row to select all rows. If you then press Delete it will delete the lot. Again, is this sufficient?
4b. On needing to pick an RDF on each download, how is RMIR to know that it is the same remote? You are only offered a choice when there is more than one remote with the same signature. You might have more than one such remote and have swapped it between downloads. So I don't see how to do this reliably.
5. It does this for an individual signal in the Advanced Details panel, but on the Timing Summary the Parity and Round To values may vary between signals, especially if the set-up has learns from more than one device. I have previously thought it a deficiency that it doesn't say, for each signal, what decode is showing (uni- or bi-polar, rounding, parity) but I haven't seen how to display that info. More columns in the table, perhaps? I ruled that out as there are already rather a lot of columns but it is do-able if it is considered worth while.

vickyg2003 wrote:I'd really like the "show sling protocols" to remain checked. Every time i need one i have to check the option, close rm, reopen rm. so it is designed to be a persistent setting, it just isn't.

Yes, it is persistent. I've just tried it. If it wasn't persistent then after checking the option, closing RM and reopening it, it would be unchecked.

Persistent options are stored in the RemoteMaster.properties file in the RMIR installation folder. If you use copies of RM in different folders then each will have its own settings. If this isn't the cause of your problem, can you give me a sequence of actions that reproduces it?

mathdon wrote:Rob, by your numbering:
1. That is already in build 4 but I forgot to mention it. Check the menu item "Options > Suppress Messages > Timing summary info" and it won't appear. Build 4 also mentions this as a final line added to that info panel.

Lol, I guess that just proves that I never actually read the thing. I still think it would be nice if there was an "X" or something that one could use to clear it away, but as I just selected the Suppress option, it won't bother me any more.

mathdon wrote:2. If you hide the info panel as above, the Timing Summary will be smaller when you first open it. The current constraint is that it shows 30 lines of text in the summary panel on opening, regardless of the presence or otherwise of the info panel. For build 5 I've now made it so that if you re-size the Timing Summary and close it, then it will keep that size when you reopen it in the same RMIR session. Is this sufficient?

I still think it would be a good idea to start it off smaller (you have a scroll bar) as it's a lot easier to drag it to make it bigger than it is to make it smaller when the bottom of the screen if outside of your computer screen. But yes, now that I've got rid of the annoying thing at the top, it's not an issue for me any more.

mathdon wrote:4a. There is no "Delete All" button but you can still delete all, as you can make a multiple row selection. Click the top row, scroll to the bottom, hold Shift and click the bottom row to select all rows. If you then press Delete it will delete the lot. Again, is this sufficient?

Not really, this is all about making the tools efficient. When you're writing a new executor, you might go through 50 or more cycles of loading something into one remote, learning it with another and then downloading the learned signals from that remote, and I like to clear out the learned signals before the next cycle to make sure they're all new learns. Using IR.exe this is really simple, I just click "Delete All" and then click the "upload" button, so that's 2 clicks. What you're proposing not only involves many more clicks, but I would have to use 2 hands in order to hold shift and click the bottom row, so in all honesty, this is the sort of thing that would keep me using IR.exe, at least for executor writing.

mathdon wrote:4b. On needing to pick an RDF on each download, how is RMIR to know that it is the same remote? You are only offered a choice when there is more than one remote with the same signature. You might have more than one such remote and have swapped it between downloads. So I don't see how to do this reliably.

Again this is about efficiency, writing executors is a very time consuming process, so I'm looking to reduce as many un-necessary steps as possible. When I download the remote for the first time, I expect to have to make a selection if there are multiple RDFs, but when I download it for a second time, and the signature of the download matches the signature of the RDF that I'm already using, to me it's a no-brainer. I get Vicky's point about maybe opening multiple RMIR files that you've been sent from someone else, but that's not relevant because RMIR files have the correct RDF encoded into them, it would only be relevant if you were downloading from several different remotes in a row which all have the same signature, which I think is a lot less likely then you downloading from the same remote. And there's a workaround for the previous case, just open an RMIR file for a different remote in between.

mathdon wrote:5. It does this for an individual signal in the Advanced Details panel, but on the Timing Summary the Parity and Round To values may vary between signals, especially if the set-up has learns from more than one device. I have previously thought it a deficiency that it doesn't say, for each signal, what decode is showing (uni- or bi-polar, rounding, parity) but I haven't seen how to display that info. More columns in the table, perhaps? I ruled that out as there are already rather a lot of columns but it is do-able if it is considered worth while.

I see your point. For me personally, and I imagine for most people who would use this screen, I'm only analyzing one protocol at a time, and after all, if I make a change to the parity or rounding it will affect all the signals in the screen. So how about this, show the parity and rounding used for the first row on the screen in those boxes, and if that first row uses the wrong protocol, I'll probably delete it and start over.

Just FYI, developing new executors is one area where all the old tools are still essential. I write the code using PB then use a spreadsheet to generate the right button codes which I then copy/paste into KM, because cut & pasting is much easier in Excel than RM.

And I absolutely have to use IR.exe to load these into a remote, because RMIR doesn't allow direct access to the protocols, and I have personally never quite figured out how to do manual protocols in RM.

So for this last development session, I had IR.exe open with the new executor to be loaded into my 6131 remote, and RMIR open to download from my 8910 remote, which I used for the learning, but I did still use IR.exe to delete the learns.

So far, I've decided on the following:
2. Java tends to have a mind of its own on sizes. I tried changing the initial number of rows from 30 to 25 or less, but I got about 26 and a half rows. I'll look into that further.
4a You get your Delete All button.
4b I will add a new entry in the Options > Advanced menu called "Same sig = same remote". I understand both your and Vicky's cases and indeed have had a similar issue when repeatedly loading the same .ir file into RMIR and been asked each time to pick a remote. The option will affect both downloads and the loading of .ir files.
5. I can't set the boxes to show the values for the first row, that would cause them to be acted upon for all signals. I'll either do nothing or add one further column, Format, with entries like "Bi/200/Odd" or "Uni/100/Even". What do you think of this possibility?

"RMIR doesn't allow direct access to the protocols". I don't know what this means. There is an Edit Protocol button for this purpose and you can paste any protocol code into the code table. But it's probably better to let this rest, there are things about RMIR that I will never persuade you to like .

mathdon wrote:So far, I've decided on the following:
2. Java tends to have a mind of its own on sizes. I tried changing the initial number of rows from 30 to 25 or less, but I got about 26 and a half rows. I'll look into that further.
4a You get your Delete All button.
4b I will add a new entry in the Options > Advanced menu called "Same sig = same remote". I understand both your and Vicky's cases and indeed have had a similar issue when repeatedly loading the same .ir file into RMIR and been asked each time to pick a remote. The option will affect both downloads and the loading of .ir files.

I like all of the above.

mathdon wrote:5. I can't set the boxes to show the values for the first row, that would cause them to be acted upon for all signals. I'll either do nothing or add one further column, Format, with entries like "Bi/200/Odd" or "Uni/100/Even". What do you think of this possibility?

Nah, just leave it how it is, because the moment I enter a value myself it will act upon all of the signals anyway.

mathdon wrote:"RMIR doesn't allow direct access to the protocols". I don't know what this means. There is an Edit Protocol button for this purpose and you can paste any protocol code into the code table. But it's probably better to let this rest, there are things about RMIR that I will never persuade you to like .

Yeah, well part of it is, IR.exe was written to our exact specifications, so it does exactly what we (experts) want, whereas RM/RMIR was written to try and make things easier for newbies, so they sort of had different goals right from the start. What I'm referring to is how RM treats the protocol and the device upgrade as one. When I'm developing an executor, I don't need to keep updating the upgrade part of it, just the protocol part, so I just click on the protocols tab in IR and edit the one in question. The protocols tab in RM is typically empty, even when the upgrade is using a handmade protocol. Also, and this is probably just because I haven't spent enough time trying, but I have never been able to figure out how to use the Manual settings option in RM (and I have tried), it just seems so convoluted. KM is much easier for this, plus of course, cut & pasting is generally easier in Excel. Another thing that has always been a bit irritating to me in RM is the way, even if I move a column into a new position (I like OBC to be the first column after the function name), if I leave the tab and come back, it's moved back to its old position, or if I sort the functions in a certain way, it keeps reverting to how it was, whereas if I do this in Excel, things stay where I left them. But, once I've finished developing a new upgrade/protocol, the last step that I do is open the KM file using RM and save it as an RMDU file, so things are easier for the next guy.

I've now uploaded build 5 of RMIR v2.05 to the RMIR development folder. This does what I proposed in my previous message. On point 2, I think I have sorted the size issue and have reduced the height of the summary panel when first opened. It should now be 25 lines when the info panel is hidden, and somewhat less than that when the info panel is displayed. Also, if you change the size of the summary, close it and then re-open it in the same RMIR session, it will reopen with the changed size.

Rob, please test the new "Options > Advanced > Same sig = same remote" menu option. I've emulated this for testing, but I don't have a real remote which needs to offer a choice of RDF on downloading.

I think (or hope ) that this brings the learned signal development to an end, at least for now. On the other matter:

IR.exe was written to our exact specifications, so it does exactly what we (experts) want, whereas RM/RMIR was written to try and make things easier for newbies, so they sort of had different goals right from the start. What I'm referring to is how RM treats the protocol and the device upgrade as one.

All new remote types since JP1.3 really DO combine the protocol and device upgrade into one. If the same protocol upgrade is used in more than one device upgrade then it is included separately in each one. So whatever the origins of this feature of RMIR, it would not have been possible to extend RMIR beyond JP1.3 without it. More generally, RMIR has a level of abstraction that is not present in IR. That has made it extensible even to things such as the XSight and Nevo remotes that have a totally different internal structure from even JP1.4 and JP2, but at the expense of giving less control over the JP1 to JP1.3 remotes than IR, which is tied tightly to the internal structure of those earlier remotes.

I hope you think that what we have been able to achieve with RMIR makes the reduced control over JP1 to JP1.3 remotes worth while.

vickyg2003 wrote:Recently I worked on a bunch of learns from an xsight remote. When I transferred them to my Atlas, the learns crashed IR. I tried to import the learns into IRScope and they wouldn't go there either.

It's a long time since this thread started, but I realise I never properly answered this original query from Vicky. I said that RMIR can transfer learns between any two remotes. I didn't say about transferring them between RMIR and IR.exe.

The learned signal as displayed in the Edit panel of IR includes the 3-byte header of JP1 to JP1.3 remotes that gives the device and key that holds that signal. Remotes beyond JP1.3 do not use this header, so for consistency the signal is displayed in RMIR without it. You might think that the header should be included in JP1 to 1.3 remotes and omitted for the later ones, but that would make it more difficult to copy learns between an early and a later remote. I'm sure you remember the structure of this header better than I do. So from IR to RMIR, leave out the first three bytes. From RMIR to IR, add in the header. You can probably just put in 00 00 00, as I think the bound device and key settings in the New panel will overwrite them in any case, though I haven't tried it.

As to the different learn formats, that it irrelevant in the copying process. The learn from, say, a Nevo is displayed in RMIR in the Edit panel in the original format, whatever format is used internally in the remote, and is converted to the internal format if you are copying to a Nevo rather than from it.

mathdon wrote:

vickyg2003 wrote:Recently I worked on a bunch of learns from an xsight remote. When I transferred them to my Atlas, the learns crashed IR. I tried to import the learns into IRScope and they wouldn't go there either.

It's a long time since this thread started, but I realise I never properly answered this original query from Vicky. I said that RMIR can transfer learns between any two remotes. I didn't say about transferring them between RMIR and IR.exe.

The learned signal as displayed in the Edit panel of IR includes the 3-byte header of JP1 to JP1.3 remotes that gives the device and key that holds that signal. Remotes beyond JP1.3 do not use this header, so for consistency the signal is displayed in RMIR without it. You might think that the header should be included in JP1 to 1.3 remotes and omitted for the later ones, but that would make it more difficult to copy learns between an early and a later remote. I'm sure you remember the structure of this header better than I do. So from IR to RMIR, leave out the first three bytes. From RMIR to IR, add in the header. You can probably just put in 00 00 00, as I think the bound device and key settings in the New panel will overwrite them in any case, though I haven't tried it.

As to the different learn formats, that it irrelevant in the copying process. The learn from, say, a Nevo is displayed in RMIR in the Edit panel in the original format, whatever format is used internally in the remote, and is converted to the internal format if you are copying to a Nevo rather than from it.

I was trying to copy them into an JP1.3 Atlas, IN RMIR and then save it as an IR file, but it crashed IR when I tried to open it..

mathdon wrote:

vickyg2003 wrote:I'd really like the "show sling protocols" to remain checked. Every time i need one i have to check the option, close rm, reopen rm. so it is designed to be a persistent setting, it just isn't.

Yes, it is persistent. I've just tried it. If it wasn't persistent then after checking the option, closing RM and reopening it, it would be unchecked.

Persistent options are stored in the RemoteMaster.properties file in the RMIR installation folder. If you use copies of RM in different folders then each will have its own settings. If this isn't the cause of your problem, can you give me a sequence of actions that reproduces it?

So far so good, it hasn't flipped on me yet, since you fixed the EDIT button. I am checking regularly. Hopefully if I check often enough I might find what I do to cause it to flip.

vickyg2003 wrote:I was trying to copy them into an JP1.3 Atlas, IN RMIR and then save it as an IR file, but it crashed IR when I tried to open it.

Can you post the relevant files, so I can try this myself and investigate what is happening?

I had some interesting results testing this build, and I think I just got lucky that one of the learns in my remote triggered this, because the others all act normally.

I've uploaded this RMIR file so you can look at what I'm looking at. The #17 button is not well learned, which is what prompted me to take some of the steps that I took, so here goes.

First, I go to the Learned tab and click on Timing Summary, then I go to the Analysed selection, enter 300 and select ODD. This affects all learns including #17. Then I click OK and go back to check if my settings persevered, but they didn't, I had to enter them again. It would be really nice if they persevered.

Then, to take a closer look at #17, I selected that individual learn and clicked EDIT, and selected 300/bi-phase/Odd, then went back to the Timing Summary screen, which defaults to Raw, which is how I noticed that the raw time for this button shows the rounded options that I entered in the previous screen. Next I select Analyzed and try to enter 300, but the cursor doesn't move, so even though I type 3-0-0 what I get is 0-0-3, the only way I can enter 300 is to click after the number that I entered, but even then it doesn't work, so I clicked OK and tried again. I closed RMIR and started it up again, re-opened the file and went back to the Timing Summary, entering 300 in the Raw screen works, but when I switch to Analyzed and enter 300, after entering the 3rd digit, the cursor moves to between the 2nd and 3rd digit. Now, it doesn't do this for all numbers, if I enter 123 or 234, it's ok, but if the first digit is 3 or higher, it seems to trigger it, so if I try to enter 3456, what I get is 3465 because the cursor is causing the 6 to go between the 4 and 5.

Then I tried to do the individual bi-phase thing again and went back to the Summary and sure enough, the 003 thing happened again, so I can re-create it.

Ok, not when I go back to try and edit the #17 button, it won't let me, but I can still edit the others. So, I re-opened the file again, if I select 300/raw/odd, I can close and re-edit, but if I select 300/bi/odd, once I close I cannot re-edit.

Also, once you enter something in the individual screen, even if you reset it back to 1, when you go to the Summary screen, the controls at the bottom of the screen have no impact on that particular learn.

Yeah, after several re-opens of the file and several restarts of RMIR, there is definitely something screwy going on whenever you edit an individual button and then go to the Summary, so best to leave the individual edit alone for the time being. Also, the weird thing with the cursor also happens on that screen. Plus, even though the signal has been pre-decoded as bi-phase and there's even text saying that the bi-phase unit is 300, the pre-populated Round To number shows up as numbers like 50 or 60, not 300. And it says it's EVEN even though I know it's ODD.

But, in other news, I can confirm that the Summary screen opens within the frame of my laptop screen, I can confirm that the Delete All button is there and works, but after using it, I went to click the Upload button and got a pop-up telling me that an upload overwrites the entire memory, so I hit cancel and went to Options > Suppress Messages but all of the suppression options were already selected, so why did I get this warning? Anyway, when I repeated and clicked Upload, RMIR just crashed. So I restarted it and downloaded again to see if the learns were still present and they are.

Now, I should point out that I am using a JP1/USB cable (ie, not JP1.x, etc) with a URC-8910 remote. It has previously been my experience that RMIR doesn't work with this cable or with these old remotes, so I was surprised that I was able to download from them in the first place. I used to have to download using IR.exe and then open the file using RMIR.

rmaster.err wrote:Starting upload
Interface Name = NULL
Port Name = NULL
Testing interface: JP1.X Serial
Port Name = NULL
Testing interface: CommHID
HIDManager com.codeminders.hidapi.HIDManager@ef545d devices are:
Device 0: HIDDeviceInfo [path=\\?\hid#vid_046d&pid_c52f&mi_00#8&39a0201b&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}, vendor_id=1133, product_id=50479, serial_number=?, release_number=8705, manufacturer_string=Logitech, product_string=USB Receiver, usage_page=1, usage=2, interface_number=0]
Device 1: HIDDeviceInfo [path=\\?\hid#vid_046d&pid_c52f&mi_01&col01#8&5f6592&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}, vendor_id=1133, product_id=50479, serial_number=?, release_number=8705, manufacturer_string=Logitech, product_string=USB Receiver, usage_page=12, usage=1, interface_number=1]
Device 2: HIDDeviceInfo [path=\\?\hid#vid_046d&pid_c52f&mi_01&col02#8&5f6592&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}, vendor_id=1133, product_id=50479, serial_number=?, release_number=8705, manufacturer_string=Logitech, product_string=USB Receiver, usage_page=65280, usage=1, interface_number=1]
Device 3: HIDDeviceInfo [path=\\?\hid#vid_046d&pid_c52f&mi_01&col03#8&5f6592&0&0002#{4d1e55b2-f16f-11cf-88cb-001111000030}, vendor_id=1133, product_id=50479, serial_number=?, release_number=8705, manufacturer_string=Logitech, product_string=USB Receiver, usage_page=65280, usage=2, interface_number=1]
Failed to open remote
Port Name = NULL
Testing interface: JP1 USB
Port Name = \\?\usb#vid_0fc5&pid_1222#6&e72cee4&0&1#{cafa8e93-7c32-4c27-b088-d8c36aaf4ebf}
Opened on Port \\?\usb#vid_0fc5&pid_1222#6&e72cee4&0&1#{cafa8e93-7c32-4c27-b088-d8c36aaf4ebf}
Opened interface type 0
Interface opened successfully
Base address = $0
Read first 10 bytes: E3 1C 50 56 52 30 50 56 52 30

I can confirm that only the first download asks me to select an RDF, the next download did not. However, even though I haven't changed anything, I do get a pop-up telling me that the data has changed, which I need to click away in order to continue (and again, I have every suppress messages option selected).

Regarding the JP1.3, etc comment about RMIR, sure I get it. So, I remember you saying that there is an option to edit the protocol, so I opened the last IR file from my 6131 with the new MCE executor that I wrote in it, and as expected, the protocols tab is empty, so I went to the Devices tab, selected the upgrade, clicked EDIT and then looked all over for the edit protocol option and couldn't find it. Ok, just now I noticed that, after I exited the upgrade, there is an Edit Protocol button on the main device tab (hint: it would be nice to have a copy of it in the pop-up RM screen) and I can see now how to paste a protocol upgrade. There's a lot of other stuff on this screen, is there a guide somewhere as to how to use it? I remember somebody saying that they could actually develop an executor from within either RMIR or RM, and this looks like it could be it, but it says "not editable", so how were they doing that?

Hopefully, this detailed analysis is what you are looking for.

mathdon wrote:

vickyg2003 wrote:I was trying to copy them into an JP1.3 Atlas, IN RMIR and then save it as an IR file, but it crashed IR when I tried to open it.

Can you post the relevant files, so I can try this myself and investigate what is happening?

Wow, I've been 3 weeks that I've been working on that awful MCE keyboard mouse. No wonder my garden is dead.


I copied some learns from the xsight into an Atlas
https://www.hifi-remote.com/forums/dload ... e_id=14659

This was the Resulting Atlas remote that I was trying to open in IR so I could get a timings summary.
https://www.hifi-remote.com/forums/dload ... e_id=14718

Rob, many thanks for all your investigations. I will look into all the issues but probably won't have time today to do it.

Vicky, thanks for the files. Again, I will look into it.

Rob, all the issues you raised before concerned bi-phase signals. These also have a valid uni-phase analysis. Until now, I didn't look at uni-phase signals that do not have a valid bi-phase analysis. This is the situation with your current issues. I find that Vyrolan made a real mess of this, it causes "null pointer exceptions" all over the place. I am trying to sort it out.

Well that sucks, sorry to hear that.

I've now uploaded build 6 of RMIR v2.05 to the RMIR development folder.

@Rob
As far as I can tell, I have resolved the latest lot of bugs found in Vyrolan's code.

I go to the Learned tab and click on Timing Summary, then I go to the Analysed selection, enter 300 and select ODD. This affects all learns including #17. Then I click OK and go back to check if my settings persevered, but they didn't, I had to enter them again. It would be really nice if they persevered.

They should now be preserved.

Also, once you enter something in the individual screen, even if you reset it back to 1, when you go to the Summary screen, the controls at the bottom of the screen have no impact on that particular learn.

I have now added an Unlock button to the Advanced Details panel to resolve this.

I went to click the Upload button and got a pop-up telling me that an upload overwrites the entire memory, so I hit cancel and went to Options > Suppress Messages but all of the suppression options were already selected, so why did I get this warning?

None of the Suppress Messages options were intended to suppress confirmation messages. They only do what their names, and tooltips, say. I have added a new option that will suppress these. It won't suppress all the confirmation messages as I think some are important, so if you find any others that you think it should suppress, let me know.

Anyway, when I repeated and clicked Upload, RMIR just crashed. So I restarted it and downloaded again to see if the learns were still present and they are.

That is nothing to do with the Delete All button, it is to do with the upload crashing and that is caused by driver problems. See the thread RemoteMasterv2.04 crash on upload to device for information on how to install the WinUSB driver so that it works on Windows 8.1 and later. I have just re-tested this with my URC-8550 and a cable with a Delcom chip and have done both a download and upload without issue.

I remember somebody saying that they could actually develop an executor from within either RMIR or RM, and this looks like it could be it, but it says "not editable", so how were they doing that?

I still have the info on this that I e-mailed to you when you asked this two years ago, and also have the question and answer session that we followed that with. So I will e-mail it to you again. I should probably make a Sticky out of it, when I have time.

@Vicky
Your problems with copying learns from an XSight to an Atlas are issues for IR, not for RMIR. As you know, the first six learns open in IR but IR rejected the next one (and so also all following ones). Learn #7 is badly formed. RMIR can handle it, IR could not. To see what is wrong, open in RMIR the Missing Learns file you posted for me. Click the Timing Summary button, select the Analyzed Data radio button, then without doing anything else, select the Analyzed Coded radio button. If you look at #7 you will see that its sections are named Once, More, Repeat. The first two sections are sent once, the third one repeats while the key is held. This is malformed. There should only be one section sent once before the repeat section. There can be three in total, the first sent once, the second repeats while the key is held, the third is sent when the key is released. IR can only handle this structure, RMIR can make sense of ones with extra sections.