RMIR v3.0 Major new release!

[mathdon]

@davecs:

I'm requesting a minor change to JP1EEPROMSupport/instructions.txt

Although the connectors we use for the 6-pin connector are normally not "keyed", the UEI remotes appear to be designed for keyed connectors that only fit one way round. There have been two styles of "keying". Older remotes, including as far as I am aware all JP1 remotes, have a cut-out on one of the long sides. Newer remotes have a smaller cut-out on one of the short sides. Pin 1 can always be identified from the position of the cut-out. Here are the two layouts, where X marks the cut-out.

Code: Select all

2   4   6    or   2   4   6
                            X
1   3   5         1   3   5
    X

You don't suggest any wording for your proposed change, so if I add a description of this keying to identify pin 1, does that meet your need?

[davecs]

@davecs:

I'm requesting a minor change to JP1EEPROMSupport/instructions.txt

Although the connectors we use for the 6-pin connector are normally not "keyed", the UEI remotes appear to be designed for keyed connectors that only fit one way round. There have been two styles of "keying". Older remotes, including as far as I am aware all JP1 remotes, have a cut-out on one of the long sides. Newer remotes have a smaller cut-out on one of the short sides. Pin 1 can always be identified from the position of the cut-out. Here are the two layouts, where X marks the cut-out.

Code: Select all

2   4   6    or   2   4   6
                            X
1   3   5         1   3   5
    X

You don't suggest any wording for your proposed change, so if I add a description of this keying to identify pin 1, does that meet your need?

Just something to say that if you get the pins the wrong way round, it's necessary to disconnect the Arduino from the computer and reconnect it, or close and reopen RMIR, before trying with the pins the other way round. Otherwise RMIR will just assume you're trying the same thing again and will report "No remotes found". Just to show how difficult it can be to guess, here is a photo of the pins on a URC-8910.

[mathdon]

@davecs:
I have changed your photo to a link to it, as the image was so large that it made this page of the thread almost unreadable.

I expect to post RMIR v3.0.8 tomorrow, which will include the amended instructions as well as fixes for the bugs posted by rh100605, kerryland and stama. I hope I haven't missed any other bugs posted while I was away on holiday.

[davecs]

@davecs:
I have changed your photo to a link to it, as the image was so large that it made this page of the thread almost unreadable.

I expect to post RMIR v3.0.8 tomorrow, which will include the amended instructions as well as fixes for the bugs posted by rh100605, kerryland and stama. I hope I haven't missed any other bugs posted while I was away on holiday.

Fine by me. Is there a way inside the img tag to restrict the size of the photo in the display?

[The Robman]

Is there a way inside the img tag to restrict the size of the photo in the display?

I don't believe so, not with this version of the phpbb software. I re-sized the image, loaded it to IMGUR and replaced it in the previous post.

Btw, most (but not all) remotes have the corner cut out of the box around the pins showing pin 1, which is evident in your pic too.

[mathdon]

Just to show how difficult it can be to guess, here is a photo of the pins on a URC-8910.

Now that Rob has re-sized your photo, the cut-out for the key is clearly visible at the bottom of the picture, shaped thus:

Code: Select all

 __________
 |         |
 |         |
 |__     __|
    |____|

so pin 1 is bottom left, in agreement with the corner cut off on the PCB outline.

[mathdon]

I have now replaced RMIR v3.0.7 in the RMIR Development folder with v3.0.8. This build fixes several issues that occur in particular specialized situations. They are:

1. In RMPB or the Protocol Editor of RMIR, numerical values that are shown in both the Protocol Data and PD Details tabs now always remain synchronized if the value is changed in either of the tabs. Previously there were circumstances in which this did not happen.

2. The Buttons tab of the Device Upgrade Editor with XSight remotes can now handle entries where the Function is an Activity Macro. Previously such entries would cause the Device Upgrade Editor to crash.

3. The Layout tab of the Device Upgrade Editor with XSight remotes now handles Alias entries correctly. Previously the Alias field was permanantly disabled.

4. In RMDU, imported External Functions can now be assigned to unshifted buttons. Previously they could be assigned to shifted buttons but a bug prevented them from assignment to unshifted ones.

5. The Instructions in the JP1EEPROMSupport subfolder have been amended concerning connection to the remote, to clarify how to identify pin 1 and how to correct it if the connector is inadvertently connected the wrong way round.

I should be grateful if the users who notified me of those issues could test that my fixes do resolve their problems.

@davecs:
Apologies as I forgot your request about "Confirmation Prompts". I will deal with this in the next build.

@kerryland:
You will find that you can only set an alias on functions from a different device. Functions that are macros, shown in Functions as "Macro: ...", do not support an alias. What shows on the device is the macro name, so you can set a different name by re-naming the macro. Aliases worked differently in RMIR versions prior to v3.0. This now fits more easily with the internal structure of the remote software.

[mathdon]

Is it possible to separate the option to suppress "Confirmation Prompts" so that the one about Invalid Device Codes is considered separately? I'd like to suppress that but not the others!

I can't find a prompt about invalid device codes that is suppressed by the option to suppress "Confirmation Prompts". Messages about invalid device codes are determined by the entry SetupValidation in the RDF. This is normally set to Warn. Try changing that to Off to see if that suppresses the prompts you mean.

[davecs]

I can't find a prompt about invalid device codes that is suppressed by the option to suppress "Confirmation Prompts". Messages about invalid device codes are determined by the entry SetupValidation in the RDF. This is normally set to Warn. Try changing that to Off to see if that suppresses the prompts you mean.

I could try that, but will that setting mean that other potentially damaging warnings would not be given?

[davecs]

Just to show how difficult it can be to guess, here is a photo of the pins on a URC-8910.

Now that Rob has re-sized your photo, the cut-out for the key is clearly visible at the bottom of the picture, shaped thus:

Code: Select all

 __________
 |         |
 |         |
 |__     __|
    |____|

so pin 1 is bottom left, in agreement with the corner cut off on the PCB outline.

Thing is, whereas that may be true for the 8910, for the 7560/2, which I think is earlier, there is no cut-off corner, and pin 1 is marked by having a number "1" next to the pin. I think that's why our convention is to start counting at the top right pin. Incidentally, "JP1" is below it at pin 2. If you get a Dupont 3x2 connector, it has an arrow above the top left pin, if that were pin 1, that's a mirror image of our convention.

The conclusion is that there isn't really a rule, and it's up to the user to see what works and mark the item accordingly. Which is why I made the request about guidance when the Arduino interface doesn't work, in the first place.

[3FG]

I found a picture of a URC7510 ( UK eBay) with the battery cover removed, and it has a cut-out which matches Graham's description. Even if the pin #1 label had been damaged, you could correctly see which pin is #1. So I think there is a rule which UEI has always followed.

[davecs]

Hi Graham — the paragraph you added about connecting the Arduino interface the wrong way round is great. I wonder if it's an idea to add the link to the wiki about wiring it up.

Hi 3FG — I have ended up with two 8910s, due to connecting one the wrong way round, then turning it round the other way and getting another error. I also have two 7560s (one's a 7562 but they're identical, just a different colour). The markings inside the battery cover aren't the same. There is a slight corner cut-off drawn next to pin 1 on the 7560 but it's not as clear as the one on the 8910, and everything else is totally different, even the overall orientation of the 6 pins. The important thing is to know what to do if you put it in the wrong way round, and that is now covered in the instructions.

[mathdon]

@davecs:

Everything you talk about concerns the markings on the PCB. Perhaps you don't realize it, but what 3FG and I are talking about is the aperture on the case, nothing to do with the PCB. The connector has to fit through this aperture and its shape, with a cut-out along one edge, makes the connector only fit one way round. We don't have such connectors but UEI clearly does, so all their remotes have to have such a cut-out. Initially they had large connectors with the cut-out on a long edge. The later ones were smaller with a cut-out on a short edge. In either case, pin 1 can be determined from the case, whatever the markings on the PCB.

[davecs]

@davecs:

Everything you talk about concerns the markings on the PCB. Perhaps you don't realize it, but what 3FG and I are talking about is the aperture on the case, nothing to do with the PCB. The connector has to fit through this aperture and its shape, with a cut-out along one edge, makes the connector only fit one way round. We don't have such connectors but UEI clearly does, so all their remotes have to have such a cut-out. Initially they had large connectors with the cut-out on a long edge. The later ones were smaller with a cut-out on a short edge. In either case, pin 1 can be determined from the case, whatever the markings on the PCB.

With you now. I wish that had been obvious to me a month or so ago!

[mathdon]

I can't find a prompt about invalid device codes that is suppressed by the option to suppress "Confirmation Prompts". Messages about invalid device codes are determined by the entry SetupValidation in the RDF. This is normally set to Warn. Try changing that to Off to see if that suppresses the prompts you mean.

I could try that, but will that setting mean that other potentially damaging warnings would not be given?

No, SetupValidation only concerns checking setup codes against those listed in the RDF, which I take it is what you mean. Setting it to Off makes all setup codes be considered as valid. If this is what you want, I could add an option to override the RDF setting for SetupValidation.