JP1 Remotes

The latest IRhelp PDF file is very informative and filled in a lot of missing holes for me. I have been searching for something similar for RDF mod/generation, and can't find that (maybe for good reason).

I have spent a fair amount of time working on this remote and could use a little help. This model was an EOM cable remote that probably saw little to no mass production, so I'm not surprised that it doesn't have a set of files in the RDF distribution.

The remote itself is in a Millenium 4 housing, but was branded as 'Millenium Interactive' by UEI (and I have the manual for it). The remote shares a signature (UMIAUMI0) with a Charter URC-4393 OEM remote, for which Rob made a starter RDF, labeled as a work in progress. The remote itself is in a Millenium 4 housing, but was branded as 'Millenium Interactive' by UEI (and I have the manual for it). I Opened the remote and extracted the model number (URC41xxxB00) from the PCB silkscreen.

I used this (Robs starter RDF) as a base and made some changes to adapt to the remote, and get it load in RM without causing java null exception errors. Knowing that the masses are probably not interested in this remote, I also built my own image map/jpg combo and have that working in RM, so I can assign function keys etc.

Using the macro method, I decoded all the keycodes and named the keys to match the remote in the new RDF 'Millenium Interactive (URC41xxxB00).

Three of the keys that are giving me a little trouble are the 'macro keys', labeled DAY-, LOCK, and Day+. Since the manual calls these out as 'macro keys', it may mean that they are device independent (they don't appear in a device ButtonMap, and attempts to add them in weren't successful. (I know, don't mess with buttonmaps). In the original RAW dump of the remote, these keys had Macro EFCs assigned to them, to generate the equivalent codes for DAY-, LOCK, and DAY+ in GI Protocol.

I am attempting to just directly assign/map the functions to these keys, using a GI device upgrade (also included in my zip file). This doesn't appear to work, but that may be because the keys themselves cannot be assigned to a device via button map. I do have these keys identified in the keycode list in the RDF. (so RM and IR know the total count), but not sure if this is the right move.

In the GI protocol device upgrade, RM seems to recognize that these three keys aren't in a device button map, and when I associate the keys to their respective functions, RM automatically assigns keymoves for these three keys (keycodes $18, $20, and $28).

When I copy the device upgrade over to IR and upload to the remote, all the codes work as expected. However, a few issues:

1) When I looked at the key map in the 'devices' tab in IR, the keynames weren't matching up with the right hex codes, after I got past the grouped keys (number) ,(volume), (channel).

2) And sometimes the last three keys in the IR key map showed 'unassigned' (even though they weren't), which I assumed was due to this issue with the three macro keys being counted (or not counted) properly. All the keynames and functions matched up correctly in RM though. AND, all the keys on the remote were functioning properly, so the final mapping seems to be right.

As I open the files now to point out a few examples (after preparing them for zip and uploading them), this discrepancy has vanished. I did go through the process of copy/pasting the upgrades back in, so maybe there is sync issue or some operator error. I could have sworn I read something similar in an old post, but cannot find that now for the life of me.

Questions:

1) So does that issue ring a bell (key map in IR not in sync in RM)?

2)And is there a way to directly assign a function to the macro keys without a keymove?

3) Can you tell me what the right way to handle the macro keys is in the RDF definition? Anything else I need to fix in the RDF?

4) I'd also like to be able to directly assign functions to the number keys. I realize that right now those keys are driven by a table; but could find nothing in readme or post to decipher the DIGITMAP section. Aside from the "Anatomy of an upgrade' post by Rob, where he mentions that setting the second byte to zero will enable the keymap bitmap for the number keys, I couldn't locate anything to describe how I could effect that change in the RDF



I have included all the files in my upload to the analysis section, at this link:

https://www.hifi-remote.com/forums/dload ... le_id=9104

The milleniuminteractive(URC41xxx).zip file contains the RAW dump of the remote before any changes, the jpg and map files, the starter and modified RDF, the millenium interactive upgrade IR file, and the GI protocol device upgrade file that I built.


Thanks,

Joe

Joe Kane wrote:1) So does that issue ring a bell (key map in IR not in sync in RM)?

Joe Kane wrote:As I open the files now to point out a few examples (after preparing them for zip and uploading them), this discrepancy has vanished. I did go through the process of copy/pasting the upgrades back in, so maybe there is sync issue or some operator error. I could have sworn I read something similar in an old post, but cannot find that now for the life of me.

From the above, it sounds like you were editing the RDF file while IR was open. IR caches the (parsed) RDF file when it is first loaded, and so it would not see the changes you made until the next time it was loaded, for example, the next time you ran IR, or if you changed remotes within IR. (The latest version of IR does have the ability to refresh the RDF, but all prior versions do not.)

Joe Kane wrote:2)And is there a way to directly assign a function to the macro keys without a keymove?

This question relates to the ButtonMaps section of the RDF, right? The purpose of this section of the RDF is to tell IR & RM how the buttons are mapped within the remote. It cannot create a mapping that is not in the remote, so if those three keys are not in the remotes mapping, adding them to the RDF will not help, it will only trick IR & RM into thinking they are mapped.

To directly answer question 2, no. If the button is not in the map in the remote, then the only way to assign a function is with a keymove.

Joe Kane wrote:3) Can you tell me what the right way to handle the macro keys is in the RDF definition? Anything else I need to fix in the RDF?

That's hard to answer. In most remotes, there is nothing special about a "macro" button (other than it is not in any button map). Some remotes do have special features for some macro buttons. What we refer to as "MultiMacros" are sometimes present, and such buttons can have more than one macro assigned. But without more info, I can't really say what type of buttons are in your remote.

Joe Kane wrote:4) I'd also like to be able to directly assign functions to the number keys. I realize that right now those keys are driven by a table; but could find nothing in readme or post to decipher the DIGITMAP section. Aside from the "Anatomy of an upgrade' post by Rob, where he mentions that setting the second byte to zero will enable the keymap bitmap for the number keys, I couldn't locate anything to describe how I could effect that change in the RDF

There is little you can do in the RDF to affect this.

Referring to Rob's post, setting the second byte of an upgrade to zero is only the first step. it tells the remote that the upgrade does not use a built-in DigitMap for the number keys. You have to set the "numbers" bit of the first keymap byte. Then the remote will expect that the first ten function codes in the upgrade are to be assigned to the number keys. If you were to enter some arbitrary function codes in RM for the number keys (such that all 10 do not match a built-in digit map), you would see that RM will change the upgrade in this manner.

If you want to force this to happen, you could temporarily delete the entries in the DigitMaps section of the RDF.

In most remotes, there is nothing special about a "macro" button (other than it is not in any button map).

Thanks, I think that was the main point I was trying to confirm.

Thanks also for other RDF info. Yes, I also knew that the keymap bitmap needs to be adjusted (since first byte is $7F) to enable the digit group. But I was trying to find the RDF linkage to effect that change. I assume that RM would automatically set that if the number keys were remapped. But I didn't try simply deleting the entire DIGITMAP section. I can give that a try.

A somewhat related question:

Are the DEVICETYPE mappings in the RDF also hard-coded in the remote?

It would seem that they are. I started with the WIP starter RDF , where all the DEVICEMAP settings were originally set to zero.
While the Cable Device does line up with ButtonMap 0, Audio does not seem to line up with this buttonmap. I am inferring this after finding that my key assignments were not taking hold on all keys for the audio device. Changing the Audio Devicetype to 1 (and subsequently seeing RM create a long series of keymoves) fixed the key assignments.

This does eats a lot of memory as I still want to use nearly all the buttons on the remote for my audio mode device. Through trial/error I suppose I can work out the rest of the devicetype to buttonmap linkages.



[/code]

Joe Kane wrote:Are the DEVICETYPE mappings in the RDF also hard-coded in the remote?

Yes. It would be very unusual for a remote to only have one device type. Each device type will potentially have its own button map, though often there will be fewer button maps than device types.

Joe Kane wrote:Through trial/error I suppose I can work out the rest of the devicetype to buttonmap linkages.

That sounds like you are on the right path.