OARUSB04G Questions

[The Robman]

Graham, I'd be interested to know some of the technical details behind this. If Lurker was overwriting his backlight settings using his old rmir file, I assume that means the value is stored in the rmir file somewhere, but having added the new entry to the RDF, when I try changing the value, I don't see any changes in the raw data, in fact the checksum remains the same.

[mathdon]

having added the new entry to the RDF, when I try changing the value, I don't see any changes in the raw data, in fact the checksum remains the same.

Strange, it should change. If you look in the Segments panel (Options > Advanced > Show Segment Editor if you don't already have it enabled), what should change is the 3rd byte in the data of the Type DF segment. The Address column will tell you where to find that segment in the Raw Data.

In the [Segments+] entry:
Backlight=$DF 2.0.0.2.0 (Off:$2C; 3sec:$22; 6sec:$23; 9sec:$24)
the $DF is the segment type. Of the 2.0.0.2.0, the first 2 is the 0-based offset of the byte to change in the data of that segment (so the 3rd byte). The next two 0's are required for this use of the segments entry, as is the final 0. The second 2 is the 0-based offset of the default setting in the options list. The options list entries give the text displayed in the drop-down and the byte value for that option. In this case the byte values are the keycodes for the digit keys 0,1,2,3.

When I said that backlight setting was not supported in RMIR, I had forgotten that I had extended the [Settings] section with [Settings+] to support settings in segmented remotes. These entries are rarities in RDFs for segmented remotes and completely slipped my mind.

[mathdon]

Ed mentioned another setting to enable/disable backlight on pickup. I didn't need it, but add that one too if you can.

Thanks for pointing this out. I had to go and read my own extender documentation to find out about this . Here's a revised [Settings+] section that does that as well:

Code: Select all

[Settings+]
Backlight timeout=$DF 2.0.0.2.0 (Off:$2C; 3sec:$22; 6sec:$23; 9sec:$24)
Backlight on pickup=$E0 2.0.1.1.0 (Off; On)

My experiments indicate that the timeout applies on pickup as well as on button press, so that if timeout is Off then backlight on pickup is also off, regardless of its separate setting. So the backlight on pickup setting is only relevant when the timeout is a nonzero value.

[The Robman]

having added the new entry to the RDF, when I try changing the value, I don't see any changes in the raw data, in fact the checksum remains the same.

Strange, it should change. If you look in the Segments panel (Options > Advanced > Show Segment Editor if you don't already have it enabled), what should change is the 3rd byte in the data of the Type DF segment. The Address column will tell you where to find that segment in the Raw Data.

As Lurker hasn't posted his rmir file, I was just trying it after having RMIR create a new remote image, so I didn't have the DF segment. I don't know if that's something you need to consider? Should RMIR create the DF segment for you?

[Ed]

Ed mentioned another setting to enable/disable backlight on pickup. I didn't need it, but add that one too if you can.

Thanks for pointing this out. I had to go and read my own extender documentation to find out about this . Here's a revised [Settings+] section that does that as well:

Code: Select all

[Settings+]
Backlight timeout=$DF 2.0.0.2.0 (Off:$2C; 3sec:$22; 6sec:$23; 9sec:$24)
Backlight on pickup=$E0 2.0.1.1.0 (Off; On)

My experiments indicate that the timeout applies on pickup as well as on button press, so that if timeout is Off then backlight on pickup is also off, regardless of its separate setting. So the backlight on pickup setting is only relevant when the timeout is a nonzero value.

Graham,

I've been watching this thread, and I want to add my thanks to you for adding this functionality. I will try it myself next time I make a tweak to my remote.

[mathdon]

As Lurker hasn't posted his rmir file, I was just trying it after having RMIR create a new remote image, so I didn't have the DF segment. I don't know if that's something you need to consider? Should RMIR create the DF segment for you?

There is not enough information in the RDF for it to create the DF segment. The RDF only says what one byte of it should be. It is a general issue with all remotes, even non-segmented ones, that there is not enough info in the RDF for it to create a factory reset state. This was a relatively minor issue with JP1.3 and earlier, as at least all data bytes were there, even if some corresponded to inappropriate settings. It is much worse with segmented remotes where there are so many different segment types. There are many that may be present in a factory reset state that RMIR cannot create due to lack of information.

This is why the warning appears when users do File > New, though you will not get it if you have comfirmation prompts suppressed. I can post a URC6440 setup for you if you want to look at this further.

[Lurker]

As Lurker hasn't posted his rmir file, I was just trying it after having RMIR create a new remote image, so I didn't have the DF segment. I don't know if that's something you need to consider? Should RMIR create the DF segment for you?

I didn't ignore you, I just would rather not post my rmir file because I would have to redact all the personal information out of it first. It is full of notes to myself about what I did and why, etc. I need this because otherwise I'd be starting all over every time after forgetting everything. When I need to change something, usually months (or years) have passed without thinking about jp1 at all.

I am very impressed at the power and flexibility of RMIR to program so many different remotes just by defining them with rdf files. What I don't understand is how Graham knows where the backlight settings (or anything else) should go in the remote memory.

[The Robman]

I'd be happy with a raw download of your remote, I don't need to see your personal notes.

[mathdon]

What I don't understand is how Graham knows where the backlight settings (or anything else) should go in the remote memory.

Mostly it is a question of doing a download, changing something through the facilities on the remote, doing another download and seeing what has changed. That is what I did to find the backlight settings.

[Lurker]

I'd be happy with a raw download of your remote, I don't need to see your personal notes.

http://www.hifi-remote.com/forums/dload ... e_id=25927
http://www.hifi-remote.com/forums/dload ... e_id=25928

[Lurker]

Just to follow up, it has been over 3 months since I turned off the backlight, and I have needed no battery changes since then.

My batteries finally died after 5 months with the backlight disabled, which is a huge improvement. I was only getting 1 month with the backlight enabled.

[Ed]

My batteries finally died after 5 months with the backlight disabled, which is a huge improvement. I was only getting 1 month with the backlight enabled.

That's about what I get. As a comparison, I used to use the RCRP05B for the devices I currently control with the OARUSB04G. A set of batteries in it lasted at least 2 years.

[Lurker]

My batteries finally died after 5 months with the backlight disabled, which is a huge improvement. I was only getting 1 month with the backlight enabled.

That's about what I get. As a comparison, I used to use the RCRP05B for the devices I currently control with the OARUSB04G. A set of batteries in it lasted at least 2 years.

Yes, me too. The RCR was my favorite remote for many years, but it was not very durable. I usually had to replace the whole remote every 2 or 3 years because one or more buttons would start failing. I went through quite a few of them until recently when it became impossible to find, so I switched to the OAR, and was surprised by the poor battery life.