JP1 Remotes

Mark Pierson wrote:KM v7.55 is now available.

Changes include:

• Updated '15-1925', 'URC-7070', and 'Navigator URC-43000' remotes.
• Added 'Atlas DVR', 'Intuitive', 'Navigator URC-44000B00' and 'Navigator URC-44000B02' remotes.
• Added provisions for 'M6805-C9' and 'M6805-RC16/18' processor types.

For those of you who will need updated RDFs for these remotes, they are available now in the JP1 Files section. Please be sure to delete any old versions of these RDFs from your IR and/or RM folders.

P.S. To Greg, John & the rest of the RM crew: These RDFs do not yet differentiate between the two protocol types.

mr_d_p_gumby wrote:

Mark Pierson wrote:KM v7.55 is now available.

Changes include:

• Updated '15-1925', 'URC-7070', and 'Navigator URC-43000' remotes.
• Added 'Atlas DVR', 'Intuitive', 'Navigator URC-44000B00' and 'Navigator URC-44000B02' remotes.
• Added provisions for 'M6805-C9' and 'M6805-RC16/18' processor types.

For those of you who will need updated RDFs for these remotes, they are available now in the JP1 Files section. Please be sure to delete any old versions of these RDFs from your IR and/or RM folders.

P.S. To Greg, John & the rest of the RM crew: These RDFs do not yet differentiate between the two protocol types.

Mike

I tried these new RDF's and 4 of them have compatability problems with RM. I should have time tomorrow to see what I can do to make them work in RM. If anyones else tries them in RM and have or don't have problems let me know.

Nils,

Lemme guess, the 7070 was one of the four? Just selecting it crashes RM. (No biggie since I don't have one, just deleted it from "preferred list")

Jim

Nils_Ekberg wrote:

mr_d_p_gumby wrote:

Mark Pierson wrote:KM v7.55 is now available.

Changes include:

• Updated '15-1925', 'URC-7070', and 'Navigator URC-43000' remotes.
• Added 'Atlas DVR', 'Intuitive', 'Navigator URC-44000B00' and 'Navigator URC-44000B02' remotes.
• Added provisions for 'M6805-C9' and 'M6805-RC16/18' processor types.

For those of you who will need updated RDFs for these remotes, they are available now in the JP1 Files section. Please be sure to delete any old versions of these RDFs from your IR and/or RM folders.

P.S. To Greg, John & the rest of the RM crew: These RDFs do not yet differentiate between the two protocol types.

Mike

I tried these new RDF's and 4 of them have compatability problems with RM. I should have time tomorrow to see what I can do to make them work in RM. If anyones else tries them in RM and have or don't have problems let me know.

I fixed all of them with some input from Jim G and will upload them later today (need to mow the lawn before it rains). There was nothing serious wrong with any of them and they would work fine in KM and IR but needed adjustments for RM. It was nice to see the button map fixed on the 1925+

Nils

Nils_Ekberg wrote:There was nothing serious wrong with any of them and they would work fine in KM and IR but needed adjustments for RM.

Just an FYI, but KM does NOT use the RDF's at all. There is a ton of stuff in KM derived from them, but they're not needed.

Nils_Ekberg wrote:I fixed all of them with some input from Jim G and will upload them later today (need to mow the lawn before it rains). There was nothing serious wrong with any of them and they would work fine in KM and IR but needed adjustments for RM. It was nice to see the button map fixed on the 1925+

Let me know what was wrong and I'll try to avoid doing that in the future...

Sorry I did not have time to test with RM before releasing them. Sorting out the protocol issue was soaking up most of my spare time at that point.

Not being all-inclusive, but RM "complained" about buttons being included in the buttonmaps that weren't in buttons. ie. in both 08a's for devices "0" and "1" were $8b,d,c,e,and f. Note the "8" in each. Typo? CAOO had a $97 in every buttonmap, but no $97 defined in buttons.

There were others, Nils can fill you in on them.

Nils and i went thru them seperately and I shared what I found, and he said they mostly agreed with what he found. I'll be interested to compare what he posts and compare with what I made.

Just a question: Can a missing button or phantom (like discreteon) be "legally" included in a buttonmap? I can understand where it'd have to be included in buttons so IR can use it for keymoves, macros, etc. Or is this a special 6805 thing?

Jim

jamesgammel wrote:$8b,d,c,e,and f. Note the "8" in each. Typo?

Those are shifted versions of $0b, $0c, $0d, $0e, and $0f.

CAOO had a $97 in every buttonmap, but no $97 defined in buttons.

That's the shifted version of $17.

Remember, shifted buttons add $80 to the base button code.

Can a missing button or phantom (like discreteon) be "legally" included in a buttonmap?

I think IR will show that as "Button$##". Perhaps RM can't handle that particular scenario?

I couldn't remember how RM deals with this, so I went and looked. Rm expects every button in every button map to be explicitly named in the buttons section.

I'll take a look at changing the code so that RM will handle these situtations better.

jamesgammel wrote:Not being all-inclusive, but RM "complained" about buttons being included in the buttonmaps that weren't in buttons. ie. in both 08a's for devices "0" and "1" were $8b,d,c,e,and f. Note the "8" in each. Typo? CAOO had a $97 in every buttonmap, but no $97 defined in buttons.

As Mark has pointed out, these are "shifted" versions of buttons already defined. No, this is not a typo. By convention, most RDFs do not give a new name for a shifted button when the remote does not have a different label for the shifted function. If RM complains about it, then it's because RM is still under development and this sort of thing is still being worked out.

jamesgammel wrote:Just a question: Can a missing button or phantom (like discreteon) be "legally" included in a buttonmap? I can understand where it'd have to be included in buttons so IR can use it for keymoves, macros, etc. Or is this a special 6805 thing?

No, this is not a 6805 "thing". As to the legality of including these phantom buttons in a keymap, you'd have to direct that question to UEI, since the RDF is only reflecting the way the remote is set up internally. In the case of the 15-1925 vs. the URC-7070, it is because both of these remotes use the same firmware, even though the complement of buttons is different for each. Just because UEI chose to omit a physical button on one remote it does not mean it's key code has been removed from the keymap. Many people would find it useful to be able to assign an IR code to these phantom buttons within an upgrade, because it saves the keymove that would be required otherwise.

Mark Pierson wrote:

jamesgammel wrote:$8b,d,c,e,and f. Note the "8" in each. Typo?

Those are shifted versions of $0b, $0c, $0d, $0e, and $0f.


CAOO had a $97 in every buttonmap, but no $97 defined in buttons.

That's the shifted version of $17.

Remember, shifted buttons add $80 to the base button code.

I know that. In this last case $97 was shifted-music. RM's complaint was Shift-music wasn't defined as such in [Buttons], and therefore not allowed to be included in the buttonmap. None of the $8x were defined in [Buttons] either and RM came up with the same complaint. Mike asked what he had to do or what went wrong to make the rdf's RM compliant. One obvious rule is if it ISN'T listed in [Buttons], it can't be used in [Buttonmaps] or RM will complain and crash. I don't think IR even recognizes [Buttonmaps] so it wasn't a factor with IR.


Jim

jamesgammel wrote:One obvious rule is if it ISN'T listed in [Buttons], it can't be used in [Buttonmaps] or RM will complain and crash.

I don't think that's obvious at all (see Greg's reply above). I also think there are some other cases like this with other remotes.

I don't think IR even recognizes [Buttonmaps] so it wasn't a factor with IR.

Think again... of course IR uses [ButtonMaps].

jamesgammel wrote:
One obvious rule is if it ISN'T listed in [Buttons], it can't be used in [Buttonmaps] or RM will complain and crash.

"I don't think that's obvious at all (see Greg's reply above). I also think there are some other cases like this with other remotes.
Mark "

Hmmmmm, I just read Greg's post:

"I couldn't remember how RM deals with this, so I went and looked. Rm expects every button in every button map to be explicitly named in the buttons section.

I'll take a look at changing the code so that RM will handle these situtations better.
_________________
-- Greg "

Sorry, but I don't see a difference.

Jim

jamesgammel wrote:Sorry, but I don't see a difference.

Whatever...

I can't remember the specifics, but there were a few other remotes that had buttons defined in the [ButtonMaps] that weren't explicitly listed in [Buttons]. Either they have all been modified, or nobody has tried their RDF's with RM yet.

In any event, I think RM needs to allow for this the same way IR does, and Greg seems to acknowledge that as well.

jamesgammel wrote:One obvious rule is if it ISN'T listed in [Buttons], it can't be used in [Buttonmaps] or RM will complain and crash. I don't think IR even recognizes [Buttonmaps] so it wasn't a factor with IR.

Jim

Actually, IR does use the [ButtonMaps] (it must, 'cause otherwise they wouldn't be in the pre-RM RDFs).

So, since IR doesn't have an issue with ButtonMaps including buttons that aren't defined in the [Buttons] section, RM's failure to do the same should be considered a bug. The code in RM dealing with ButtonMaps was written with the assumption that the buttons would be pre-defined. That is clearly not the case, so the code will have to be changed.