JP1 Remotes

I am trying to test Vicky's new Atlas PVR JP1.2 (10251025) extender, and to do so, I intended to start by setting up an UNextended 10251025 remote. This has been kicking my butt, as I have been getting scrambled buttons in NO apparent pattern. Vicky had alerted me to the presumably known"fact (?)" that if a setup code number's binary does NOT end in either 00 or 11, then the number buttons get scrambled. Trying to get to the bottom of this, I created a bunch of identical upgrades with different setup code numbers (1021 thru 1024) which should cover the four cases of last 2 bits (01, 10, 11, and 00). I then tested these in an Atlas PVR 101251025 remote. The results were, shall we say, inconclusive (except to convince me that this remote has a LONG way to go to be useful).

This zip file contains 5 identical device upgrades for a JVC TV using the JVC Combo protocol (I believe that info is immaterial, but provided for background).

These RM upgrades are, respectively:
TV/1021
TV/1022
TV/1023
TV/1024 and
AUD/1024

The IR file containing FOUR of those upgrades assigned to the non-CBL buttons (the CBL device mode behaves differently in this remote, so I didn't want to obscure my testing with it). When I saw the crazy results, I also took the TV/1024 variant and changed it to a AUD/1024 to see if not only the setup code number, but also the device type affected the scrambling. It did.

Examples:
The 8 button executed a 4 in TV/1021, a 5 in TV/1022, and 3 in TV/1023, TV/1024 and AUD/1024;
The CH+ button executed a Power Toggle in TV/1021, TV/VID input toggle in TV/1022 and Ch- in the other three;
The #/enter button (programmed with +100) executed TV/VID in TV/1021, Power Toggle in TV/1023 and TV/1024 and BLUE in AUD/1024.

Those functions that I could confirm are all listed in the xls spreadsheet included in th zip file. All I could deduce from this initially:

(1) NONE of the upgrades exhibited NO scrambling;

(2) The TV/1023 and TV/1024 had the SAME scrambling but scrambling was there was just the same;

(3) The AUD/1024 had many similarities to TV/1024, but still had differences, so I believe that not only the setup code number, but also the device type affects the scrambling;

(4) KEYMOVED functions worked correctly on the correct buttons.

There is something else going on with this remote. Although I avoided assigning anything to the CBL device, any upgrade assigned to the TV device mode was problematic. Presses of buttons frequently resulted in the CBL device button blinking instead of the TV (this never happened for the other devices), occasionally locking in an illuminated CBL light requiring battery removal to break the loop.

Also, the Power button sends no signals in any device mode aside from CBL.

Similarly, the A and B buttons didn't send the wrong signal, but sent NO signal at all in some cases (annotated on the spreadsheet).

I don't know whether this is a manifestation of a problem in IR.exe, in the RDF, or elsewhere, but it's driving me nuts and rendering this remote virtually useless at this point.

Hmm this is strange. I've got a 10251025 that I've been using for a couple weeks now and have had none of these problems. I've added 3 different upgrades to it control my TV, my receiver and my HD-DVD player. All of the buttons function as expected.

My TV upgrade code is 1610 which would end in 10 in binary.

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

My Receiver upgrade code is 0110 which would also end in 10 in binary is also fine.

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

My HD-DVD player is based on the following and just switched to the correct remote and playing with the button mapping some.

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

I had previously noted that all my device upgrades happen to use the NEC1 protocol. The Receiver happens to be the NEC4Dev combo because it uses 2 device/sub device combinations but it's still NEC1 protocol. Maybe the protocol does matter?

When I was setting up my receiver I originally tried the NEC2Dev combo but it required a protocol upgrade and didn't end up working at all it seemed. I switched to the NEC4Dev which was built in and everything was fine. Are your tests using a protocol upgrade or a built in protocol?

I haven't specifically tested for this but I've definitely made use of these buttons. For example my TV upgrade uses Shift 1-9 for the discrete input codes that I recently found for my TV. I use the HD Zoom/# key for my tv's zoom button that I use regularly to zoom in on letter boxed SD tv. My Receiver upgrade uses 1-4 to switch it's inputs. Those keys have all definitely been used and functioned as expected.

I don't have an IR file handy but could upload it later if that would be useful.

I'm glad yours works, but mine doesn't, so can one of the experts help?

I tried your IR file on one of my remotes and learning the 8 key to another remote resulted in the wrong OBC.

I tried creating a simple upgrade that used the JVC combo protocol. Defined only the 8 button and uploading that as the only upgrade in a new IR file for the atlas 1025 to the remote and it failed to work as expected. As I understand the upgrades RM has to automatically define all the number keys since they are all handled as one group and it seems to fill them with OBC of 0.

I tried changing the upgrade code to 1610, the same I've been using for my TV and it still failed.

At this point I'd guess it is protocol related and since it seems to be sending a button that I assume is in the upgrade earlier that we have too much information someplace in the start of the upgrade pushing the info for that button father down than the remote expects to find it.

I looked at your .IR file and the hidden upgrade area at F200 should be F2 04 F2 04 00 00. I believe speaker.guy had this same issue.

IR does allow you to create multiple macros assigned to the same tunein button. I was able to clone macros on the TuneIn buttons.

That should be changed in the official RDF, how do we get that done?

You can't really add it to the RDF in the [FixedData] section because the cable companies sometimes put device/protocol upgrades into this section.

binky123 wrote: I looked at your .IR file and the hidden upgrade area at F200 should be F2 04 F2 04 00 00. I believe speaker.guy had this same issue.

So I manually make this change on the Raw Data page in IR? How is that change "remembered?" I mean next time I open an instance of IR and want to build an IR image for this remote from scratch, I will have to make this change manually again, right? Is there a change I can make to the rdf to "retain" this info? Or if I do a 981 reset, will those data no longer be required?

binky123 wrote: IR does allow you to create multiple macros assigned to the same tunein button. I was able to clone macros on the TuneIn buttons.

How?

Well, I entered those values at F200 through F205 and the buttons are still scrambled. Any other ideas?

I also have a problem with the TV device on the remote. If I select the TV device, any button I press resluts in continuous illumination of the CBL button until I remove a battery.

Help?

So Binky

What you are saying is that the Hidden file area contains cable company specific protocols, so if a person is using there JP1.2 software to set up their remote, they should never do a NEW Atlas from IR because they may no longer be able to control their cable box.

and,

if people own their own Atlas and are doing a NEW from IR they need to initiate the Hidden area to have an empty device/protocol table in the hidden area. For the 1025 JP1.2 model, the hidden upgrade area at F200 should be F2 04 F2 04 00 00. And then the user will have to press APPLY for these changes to be remembered.

So my extender should be installed via extintall-2 or their cable company specific information will be lost.

Is this hidden file area visible ANYWHERE? Is its data at least identifiable in the Raw Data display?

As I mentioned above, entering those data in the Raw Data page did NOT fix the button scrambling problem.

Working on my OCAP remote right now. When I return to this, if there is no answer, then I guess I'll try making a single change (upgrade) at a time, and try various protocol upgrades to see when things break.

From the Atlas 10251025:

Take the base address and add #Upgrade Addr , $EA00+$0800= $F200 and you'll see the protocol device table for the Atlas 1025.

The upgrade area always start with 2 pointers that point to the upgrade tables.

DeviceTablePointer, ProtocolTablePointer
Device Upgrades
Protocol Upgrades
DeviceTable
___Device Count
___Array of Device upgrades
___Array of Device upgrade addressses
Protocol Table
___Protocol Count
___Array of Protocol upgrades
___Array of Protocol upgrade addressses

Are these readily identifyable in the raw data?

Not by me, that's for certain. However, in the Atlas that I started from the upgrade area was padded out with zeros. Maybe the experts can do it, I certainly can't.

Well, I remain at a standstill, unable to fix the scrambled button issue.

Out of curiosity,

Does the JVC upgrade work on your Atlas OCAPs?
Does the JVC upgrade shift when you change the setup code?

Just wondering if this carries into the JP1.3 too?

One more thing

I also have a problem with the TV device on the remote. If I select the TV device, any button I press resluts in continuous illumination of the CBL button until I remove a battery.

Using your IR this didn't happen with me. Have you done a manufacturer's reset -981 to try and correct the situation? One of the things that make JP1.2 remotes a little tricky is that they retain some settings even after removing the batteries.