JP1 Remotes

Unable to resist, I bought one of the Potenza ST remotes from ebay
http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... 2317471829 for $8.60. It shipped the next morning and arrived Thursday.

I promptly plugged it in to my trusty Tommy Tyler cable, and it worked right off the bat.

The big shocker:

It is neither a new signature, nor the classic RCA one (which I will now refer to as just RCA). It is yet another Atlas JP1.3 variant in RCA clothing. The signature is 30333033. This unfortunately means it is only 5 devices internally, not 8 like the RCA. The good news is, the Atlas extender should work (with suitable RDF).

The overall shape and back half of the case is identical to the RCA except has the rubbery coating. The battery covers are interchangeable. The JP1 is oriented the same way. The battery compartment label reads 66950BA0-009-R. The front only differs in the shape of the buttons and corresponding holes and lack of the RCA's oval groove in the surface.

This particular version has obviously been customized for an ADB IPTV box, so I will call it the ADB version. It has buttons labeled for functions on that box, and the color buttons have no symbols or letters and are in a different order. It also includes a preloaded upgrade for it. Interestingly, the booklet that comes with it shows and refers to the buttons all the same as the RCA. It also mentions "Tune-In" buttons that don't exist on either remote, nor appear in the illustrations.

One of the UEI-branded cheap batteries that came with it was already leaking, so I chucked them.

I have built a new RDF/map/jpg which I will upload after some more testing to make sure I haven't mixed up keys or anything else isn't different from the Atlas.

The memory size/mapping appears correct. Any suggestions on what to check and how to easily do it are welcome. For one thing, in the Atlas RDF there is a section with "MultiMacro" keys. I'm not familiar with how this is supposed to work and it isn't mentioned at all in the booklet, so I don't know whether it should be removed from the RDF. Other things I wonder about are the protocol and device code lists.

Does learning work on this remote?

Yes, it learns just fine. It flickers the device LED when it is ready for a signal, which is nice.

I just uploaded the RDF etc to http://www.hifi-remote.com/forums/dload ... e_id=25031

It seems to work in my testing. I am able to configure, up- and download the remote, and all buttons seem to work as expected. I removed MultiMacro which I could not get to work. I'm also wondering about the button mapping because what is now the Skip (->|) key is only mapped in the CBL type, which means using it in a Video or Audio device results in a keymove.

It also includes a 3.03 extender version RDF but I have NOT tried the extender at all, and don't know if the rdf or the extender itself needs adjustment for this specific remote.

Old Thread But I found i had one of these laying around
RDF seems fine have only tested for tv though
also found that mine responds to manually putting in a a dsm
so i added DSM=Internal:0 into the rdf and works as expected
Have no need to test extender
Nice remote Wish it was backlit though

After trying to load this up to replace an RCA that has dead buttons, I just ran into a weird problem with this remote.

Keymoves don't work properly with the NEC1-f16 protocol. Other protocols work fine, but this one sends wrong signals from keymoves. Looks fine when downloaded into RMIR, but the buttons don't operate the device and learning to another remote shows the codes sent are incorrect, the ones I tried are showing 0 as OBC1 and nonsense as OBC2.

I got it to work by using the NEC 4DEV Yamaha Combo instead, but this bugs me anyway. Ideas?

Just a guess, but perhaps the remote does not support commands that are 4 bytes. NEC1-f16 is unusual in needing 4-byte commands, the Yamaha Combo protocol only uses 2-byte commands.

When you did the keymoves, which format were you using? There are 2 formats, one where you enter the hex code and one where you tell it which button you are copying. As you now know, this protocol requires 4 bytes of data, which is too much for most keymoves, but if you have the function programmed into an upgrade, you may be able to copy that function to another button using a keymove.

Now, I know what you'll say next, if you can program the button using an upgrade, why would you need a keymove? What I'm suggesting is that you create a 2nd upgrade, one which isn't assigned to a device button, and have the keymove come from that upgrade.

Having said that, I had someone else try that recently with this very protocol and it didn't work on their remote, so your mileage may vary.

Makes sense. The directly mapped buttons work, it's just the keymoves that don't. The keymoves are 9 bytes each in the output, seems pretty likely it can't handle that for whatever reason.

When you say "directly mapped", do you mean the buttons in the upgrade, or keymoves created using a button as the source rather than a hex code?

Sorry, I meant buttons in the upgrade. I will play with this more later, although as I say I have it working using the other protocol.