JP1 Remotes

mdavej · Expert Joined: 08 Oct 2003 Posts: 4501

This is a very special case we're talking about. Most protocols are built in. In that case you can load as many device upgrades as you want, and they will work fine with the built-in protocols. You can use them in keymoves by simply picking the unassigned device and function.

The current problem is loading a device that needs a new protocol that's not already built into the remote. We don't have that working on these remotes yet. That's my understanding at least.

ruidosobruce · Joined: 04 Jan 2015 Posts: 91 Location: New Mexico

Yes, that seems right to me too.

mathdon · Posted: Fri Feb 13, 2015 1:50 pm Post subject:

ruidosobruce · Joined: 04 Jan 2015 Posts: 91 Location: New Mexico

Thanks Graham. I understand.

I have two different recent remotes that use MaxQ610 processors and JP2 interface, the URC-8820bc1.3 and the URC-1060bc3.

The Dish upgrade works fine in the URC-8820, so I thought maybe I could look through the segments to learn something about why. But, the segment configurations are completely different: URC-1060 uses type 0E segments for upgrades, and the URC-8820 uses the familiar type 10 segments.

Both remotes are so close to a solution: But the 8820 doesn't support keymoves and the 1060 won't support Dish. Bummer!

mathdon · Posted: Fri Feb 13, 2015 4:38 pm Post subject:

It is pure speculation, but I wonder if the URC-1060 has a type 0F segment for protocol upgrades, i.e. they have split hex type 10 into 0E and 0F. It doesn't help a lot, though, as although we know the format used for protocol upgrades, I suspect there are too many possibilities for how a new segment type is constructed from such an upgrade for us to find it just by trial and error.
_________________
Graham

mathdon · Posted: Sat Feb 14, 2015 8:43 am Post subject:

3FG · Expert Joined: 19 May 2009 Posts: 3367

This post is responding to a couple of posts which I wrongly placed in another thread. Those post showed that the 1060 doesn't choke on a possible Type 0F segment format. That doesn't mean it will work, but at least it means the basic form is correct.

I think to test if the format is correct you would in the short term need to revert to Graham's earlier .jar file which allowed you to specify an upgrade which also needed an executor. (He removed that capability in Build 10.) With that version I think you could include your Dish upgrade, manually edit in the 0F device (or if you download from the remote, it will probably still be there), and see if the remote will shoot the Dish IR protocol.

ruidosobruce · Joined: 04 Jan 2015 Posts: 91 Location: New Mexico

Yes of course, I want to try anything.
I presumed that you meant create the new segment in RMIR's segment editor. I did that, and uploaded to the URC-1060 remote, and then downloaded it again with this result.

So in the RMDU editor, how do we reference this new type-0F protocol?

3FG · Expert Joined: 19 May 2009 Posts: 3367

When the remote processes any upgrade segment, it will look for for the specified PID, which might be built into the remote or, with most remotes, one that is embedded in a Type 10 segment. In your above upgrade code, the first two bytes are 00 02, and that is the PID the upgrade has specified as the desired executor. Your remote apparently specifies (we hope) any Upgrade Protocol Code (an added executor) with a Type 0F segment, and the one you have manually entered is labeled with PID 0002. I made it like that to match your expected Dish upgrade. We're describing an executor, which has PID 0002, using a Type 0F segment.

So I hope that the remote will process your Type 0E segment, see that a PID 0002 executor is needed by the upgrade, and will then search for a Type 0F segment which describes a PID 0002 executor. If the remote has the above upgrade, and your manually entered Type 0F segment, I think it should work. Just ignore the above Upgrade Protocol Code in your screen capture--the same info is in the Type 0F segment.

ruidosobruce · Joined: 04 Jan 2015 Posts: 91 Location: New Mexico

OK, here's the thing... There may well be big problems in the remote with processing the Dish upgrade. But as I have said before, we don't know that because we never send the upgrade to the remote. RMIR never creates the type-0E file for the Dish upgrade. Graham has said that was intentional for any device upgrade that requires a protocol upgrade. So, how do we get past that?

3FG · Expert Joined: 19 May 2009 Posts: 3367

Ok, try editing the RDF file so that 0002 is included in the list of protocols. That's a temporary fix.

3FG · Expert Joined: 19 May 2009 Posts: 3367

I tried adding 0002 to the RDF, and then opened one of your RMIR files. I had to delete the Dish upgrade (because the 0002 had an asterisk, indicating a non-built in executor) , but after making a new upgrade, RMIR made a 0E segment for Dish.

mathdon · Posted: Sun Feb 15, 2015 7:22 am Post subject:

I am eagerly awaiting the next instalment - did it work???
_________________
Graham

ruidosobruce · Joined: 04 Jan 2015 Posts: 91 Location: New Mexico

I did try the forced protocol right away last night, and it appeared to satisfy RMIR, but not to produce the desired result after upload. The process and results were confusing enough that I thought I should go through the steps again this morning. I modified the URC-1060BC3 RDF to add the 00 02 protocol. Then, using that RDF, RMIR created a type 0E segment for the Dish upgrade, assigned to the (CBL) button. I uploaded that RMIR file to the remote. It is posted here:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13165
After upload, blinkback shows that the remote accepted the 1775 Dish upgrade on the cable device button. A download from the remote shows the same thing, and that the type 0F file was in place. That download file is posted here.
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13166
Button presses blink the (CBL) button, but the Dish receiver does not seem to respond to any button presses. ??