JP1 Remotes

Here is my RDF. Everything works, except some settings stored in a non-standard way, see next paragraph.

Is there any way of having [Settings] entries that are inside a specified segment, as the URC174000 uses segment 0xC8 to store a couple of settings, including the VPT setting? This would be useful for the SkyHD rev.9F URC1672 as well, which keeps several non-standard settings in segment 0xCA.

Has any consideration been given to my suggestion of a per-remote "help text" field in the RDF?

Knuckx wrote:Is there any way of having [Settings] entries that are inside a specified segment, as the URC174000 uses segment 0xC8 to store a couple of settings, including the VPT setting? This would be useful for the SkyHD rev.9F URC1672 as well, which keeps several non-standard settings in segment 0xCA.

There is no way at present, but anything can be done if we have enough info. As far as I am aware, we haven't previously seen segment types 0xC8 or 0xCA in any previous remotes. Indeed, I don't think we have seen any 0xCn types for any value of n. So please give us as much detail as you can about these segment types and I will see what we can do.

Knuckx wrote:Has any consideration been given to my suggestion of a per-remote "help text" field in the RDF?

I quite like the idea, but haven't yet done anything further.

9xx Commands do work on these remotes, but you have to push OK afterwards - so *+TV, 9, 8, 1, OK does a MFR Reset. This works on both the URC174000 and the URC174001.

Segment C8 on the Virgin Media URC174000 is 4 bytes, which on reset is The 4th byte is the VPT setting (changed to 01 by the remote on setting a TV code):
00 is VPT off OR volume source = STB
01 is VPT on OR volume source = TV
The other bytes are never set by the remote (apart from reset), and changing them has no noticable effect. This remote has a Segment 13 as well, but I have not noticed the contents change at any point.

The Virgin Media URC174001 has a Segment 13 as well, once again, never seen the contents change.

Segment CA on the SkyHD rev.9F URC1672 is 24 bytes, which on reset is The 4th and 5th bytes are some sort of address select or protocol version setting; they are configurable from the keypad, and instructions from Sky that change these are to prevent multiple boxes being controlled by one remote.

The 6th byte is a setting that changes the keymapping in TV mode, setting it swaps the Up/Vol+ and Down/Vol- keys for each other, putting up/down on the volume control, and the volume control on up/down. This is settable from the keypad, and documented by Sky as the way to use the AMP device as the volume control.
00 is the default, normal behavior, with the keys as you would expect.
01 swaps Vol+ and Up; Vol- and Down.

The 7th byte is a setting that causes the power button to send codes for all setup devices. Sky call it "Global Power".
80 is the default, global power disabled.
40 is global power enabled.
20 is settable via undocumented key combination.
10 is settable via undocumented key combination.

I have not seen the other bytes change, but have not experimented with changing them manually. This remote can also have a Segment 03, created when making a "Sky channel macro", which causes RMIR to fail to download when present.

mathdon wrote:I quite like the idea, but haven't yet done anything further.

I would suggest a readonly, scrollable textbox; like that used for Protocol Notes in the Device Upgrade Editor. It could be placed above/below the General Notes textbox on the General tab.

Thank you for the info, Knuckx. I hope to post within a few days a trial build of RMIR for you to test that supports both a Notes field and segment-specific Settings in the RDF. I think both these are good suggestions. I assume from your Settings suggestion that you understand the syntax of Settings entries for non-segmented remotes. This will save me some effort in explaining the segment-specific Settings syntax, so please let me know if it is not so.

Here is the jar file for build 5 of RMIR v2.04. It now supports a multi-line Notes field in the [General] section of the RDF, which displays in the General tab of RMIR. As an example,
displays as which shows that \ is a line continuation character and \n is newline. Leading spaces in continuation lines are ignored, to allow some freedom of formatting, but leading spaces after the = form part of the data.

It also supports Settings for segmented remotes. An example for the Virgin Media URC174000 is which references the data field of the $C8 segment that on reset is The dot-separated values are 3 (0-based index of byte concerned, here the last byte), 0 (index, 0-7, of the highest bit of the field), 1 (number of bits in field), 0 (initial value on reset), 0 (if nonzero, complement the value). The names in brackets are the names attached to field values 0, 1. So the value of the final byte is 00 for Off, 01 for On.

I haven't tested this example as I don't have this remote, but have tested similar ones. The syntax is that of the RDF spec with one addition and one change. The dot-separated setting is preceded by the segment type, and the first bit of the setting is the offset in the segment data, not an absolute address.

Knuckx, please try this and report if it meets your needs.

Thanks mathdon. It's working fine, but I'm having trouble with creating a settings entry for the SkyHD rev.9F Global Power - I have got to this: Which works, but the entries that are just numbers shouldn't be there. How can I make entries for values 1,2,4,8 and no others?

Also, on long notes, the starting position for the scrollbars on the remote Notes textbox is the end of the last line of the notes. Surely this should default to the beginning of the notes, not the end (so scrollbars in the top left by default).

I should have a few updated RDFs for you guys soon.

Sorry for the delay in replying, Knuckx, but my JP1 time has been taken up trying to sort out another new remote, the URC7980. It isn't possible to list only non-consecutive values in a bitfield within a byte, but it is possible to set only specific values for the whole byte. I think the following should work: You will find the syntax in the RDF Spec addendum in the Docs subfolder of your RMIR installation, under "New [Settings+] section". I haven't tested this, not having the remote, but I've tested similar so it should work.

I may need to create a new section name, such as Settings+2, for the segment settings to avoid causing problems for earlier versions of RMIR but I haven't tested their behaviour yet. You can continue with [Settings] but I may need to edit this in any RDFs you submit that use segment settings.

As for the scroll bars in Notes, that's what happens when Java writes the text box. It is not something I have done, but I will see if I can get Java to scroll them back to the top.

Here's some updated RDFs. Sorry about the delay.

Interesting behavior in v2.04build5 with the URC174000 and URC1672 RDFs - the new function doesn't work, but without the "RMIR cannot create a new remote image for this remote" message. Both of these RDFs have the new "settings inside segment" settings, which appears to be the issue.

I've posted a build 6 for RMIR v2.04, see this post, that should resolve the File/New problem. It includes what I believe are your latest RDFs, with a minor tweak by me. The "Notes" items have been moved to a new [General+] section rather than being in the [General] section. This is to preserve backward compatibility for earlier RMIR versions, which will ignore a [General+] section but which crash when line continuation characters appear in a [General] section. Do please check that they are, otherwise, your latest versions.

You don't appear to have uploaded build 6; the zip is still named 5, and the only RDF in there is an old one of mine.

Apologies. Something seems wrong with the upload process. I have just tried again to upload build 6, I get a message saying that the upload has succeeded, but what is there remains build 5. I have also tried to create a new upload containing build 6, again I get the success message, but no new upload has been created.

EDIT: This post referred to above now contains a valid link to build 6. It has continued to be impossible to upload it to the File Section of these forums.