Updated RDF's Maps, and Images Version 1.28

kupakai · Post by **kupakai** » Wed Jan 30, 2008 1:45 am

There seems to be a slight mix up with the RDF and image/map files for Comcast remotes. I had created a new image file for the URC-1067 and modified the RDFs for the URC-1067 and URC-1068 to be a bit more consistant with the generic button names. However, the current image/map file for the URC-1068 in version 1.28 points to the original URC-1067 image/map files and doesn't quite work with them because the button names don't quite match (namely, rew, ff, rec). I've revised the RDF, jpg and map files from version 1.28 for URC-1067 URC-1067 Extender, URC-1068, and URC-1067BX3 so they all work with one set of image/map files and have consistent generic button names for the RDF spec. They are all pointing to "URC-1067.map" file, which is a revised original version for URC-1067. I also revised the files for URC-1058 so that the button names are consistant with the other files.

I've zipped and uploaded the files here:
http://www.hifi-remote.com/forums/dload ... le_id=5346

Nils_Ekberg · Post by **Nils_Ekberg** » Wed Jan 30, 2008 5:32 am

Thank kupakai.

I will take a look at it and include it in the next distribution. I think the RDF's in the 1.28 had changed because of the extender under development but since you used the ones in 1.28 we should be good.

Mike and I have updated the [Protocols] since then so I will have to apply that before including them. Not a big deal I am just saying it here so I don't forget to do it.

mdavej · Post by **mdavej** » Fri Mar 07, 2008 7:45 am

Nils,

I'm not sure if this is worthy of a new thread or not, but I have a question about RDF updates. I'm wondering if I should add special protocols to my new non-extended 15-135 rdf. The threads I've seen on this seem contradictory to me. On one hand, you are adding special protocols to most rdfs with each new update, IIRC. On the other, the special protocols tab in IR still doesn't handle them correctly in non-extended remotes, i.e., most require key moves to work properly. My limited testing, just with the pause protocol confirms this. Simply adding the protocol to the rdf and configuring it on the special protocols tab doesn't function. However configuring it with a key move works fine. So the bottom line is, does the special protocols tab in IR serve any purpose for a non-extended remote?

Thanks

Mark Pierson · Post by **Mark Pierson** » Fri Mar 07, 2008 7:57 am

mdavej wrote:Simply adding the protocol to the rdf and configuring it on the special protocols tab doesn't function. However configuring it with a key move works fine. So the bottom line is, does the special protocols tab in IR serve any purpose for a non-extended remote?

IIRC, the special protocol code has to actually be present in the IR configuration (Protocols tab) for the Special Protocols tab to work.

gfb107 · Post by **gfb107** » Fri Mar 07, 2008 8:39 am

Also, IR doesn't use the [Protocols] section of the RDF file. That is only used by RM (and RMIR).

Nils_Ekberg · Post by **Nils_Ekberg** » Fri Mar 07, 2008 8:40 am

Mark is correct. If a special protocol is available for an unextended remote the protocol needs to be in the protocols tab and also enabled in the RDF. A good example is the MultiPlexer which is available for a lot of remotes. If you go into the special protocol tab and do an add you will see which ones are available for that remote. It will be grayed out if the protocol is not also there.

So, you can add the sp to the rdf and add the sp to the protocol tab and it should work.

mdavej · Post by **mdavej** » Fri Mar 07, 2008 10:34 am

Mark Pierson wrote:IIRC, the special protocol code has to actually be present in the IR configuration (Protocols tab) for the Special Protocols tab to work.

Got it. I'll go ahead and add them to the RDF.

I'm still a little confused though. In the case of the pause I tried, by simply entering a byte for the duration, i.e., $10, the pause would not function on the remote. If, however, I looked at the old key moved pause that did work, it had 2 bytes, one for duration, and one for something else. I don't know what the second byte represented, but I entered both bytes in the pause special protocol config, and voila, it worked. So, my point is, if the config for non-extended remote special protocols isn't really straight forward, what's the value of having it available at all?

EDIT: I finally figured out how the 2 byte pause work on the 15-135 and likely other JP1.2/JP1.3 remotes. It requires the hex value of the Duration followed by the hex value of the EFC. These are the last 2 bytes of the calculated key move on the Output sheet. For example, a 1 second pause has a duration of 1 times 16, which equals $10. It's corresponding EFC is 146, which equals $92. Therefore $10 $92 would be entered in IR, rather than just $10.

Post by **vickyg2003** » Fri Mar 07, 2008 11:15 am

I'm still a little confused though. In the case of the pause I tried, by simply entering a byte for the duration, i.e., $10, the pause would not function on the remote. If, however, I looked at the old key moved pause that did work, it had 2 bytes, one for duration, and one for something else. I don't know what the second byte represented, but I entered both bytes in the pause special protocol config, and voila, it worked. So, my point is, if the config for non-extended remote special protocols isn't really straight forward, what's the value of having it available at all?

On the JP1.2 remotes all Keymoves have to be more than 1 byte in length, that is the hex cmd field must show 2 or more bytes. If its 1 byte the protocol never fires. The Jp1.2 remotes a keymove that is exactly 1 byte long as a EFC and it fires the current protocol instead of the special protocol. I'd be very surprised if that was not true of a JP1.3 remote.

Capn Trips · Post by **Capn Trips** » Fri Mar 07, 2008 11:39 am

mdavej wrote:So, my point is, if the config for non-extended remote special protocols isn't really straight forward, what's the value of having it available at all?

The value is that it IS straightforward and DOES work for many, many remotes and users out there (I would wager the majority of forum subscribers). You just have happened upon a newer remote, which just happens to exhibit slightly different behaviour and has slightly different limitations/requirements, all of which perhaps have not yet been fully documented in the various tools.

The volunteers who develop and maintain those selfsame tools update them as their time and inclination permits.

Pointing out such limitations (as you have done) in these fora is helpful. Disparaging the efforts of the volunteers is somewhat less so.

mdavej · Post by **mdavej** » Fri Mar 07, 2008 12:16 pm

I'm sorry. I haven't been clear. Of course this functionality is of tremendous value. I didn't mean what's the value of this aspect of IR. I meant what's the value of adding a line to my RDF if it may confuse other users like myself. If I was pointing out a flaw, it was quite by accident and a result of my own ignorance. I realize and appreciate the enormous efforts of the volunteers, and didn't mean to be disparaging at all. Please accept my sincerest apologies.

Post by **vickyg2003** » Fri Mar 07, 2008 12:54 pm

I meant what's the value of adding a line to my RDF if it may confuse other users like myself.

It alerts the RDF user, that there is a Pause protocol available for this remote.

mdavej · Post by **mdavej** » Fri Mar 07, 2008 1:09 pm

Very good. I'll add it then.

Last question, hopefully. I know pause works, but how do I know which others will work? Does device multiplexor work with any S3F80? How about LKP, DSM, etc?

Capn Trips · Post by **Capn Trips** » Fri Mar 07, 2008 1:20 pm

To my knowledge, there are not "non-extender" versions of Multiplex, ToadTog, LKP and DSM for S3F80 at this point. I've only ever seen them bundled with extenders. Pause is the only one supported directly in KM and RM.

mdavej · Post by **mdavej** » Fri Mar 07, 2008 1:33 pm

Thanks.

investability · Post by **investability** » Sat Mar 08, 2008 11:49 am

As a brand newbie, I am wondering how RDF files are created? I have just received Tommy Tyler's USB cables and successfully hooked up one of my remotes for which the RDF was in your listings. How are RDFs created? Can I create my own RDF files? Is there a means of getting an RDF if it is not in your file listings?

Thanks for the newbie assistance.....

JP1 Remotes

Updated RDF's Maps, and Images Version 1.28

Creating RDF files