202608 Charter OCAP C4000 URC-1060BC2

ruidosobruce · Post by **ruidosobruce** » Thu Feb 12, 2015 3:34 pm

more information:

This remote allows lots of other Setup Codes on the [CBL] device button: Vudu, Roku, Popcorn Hour, Apple, Microsoft MCE, Xbox, Sling, etc. Just not Dish.

mdavej · Post by **mdavej** » Thu Feb 12, 2015 4:04 pm

Just make your Dish upgrade match one of those codes and it will take precedence. Sounds like they don't want their cable remote being used with satellite.

The error you got isn't an error. It's a new feature to keep you from uploading accidentally.

3FG · Post by **3FG** » Thu Feb 12, 2015 5:19 pm

Bruce,
If trying the upgrade with a different setup code doesn't work, please post the RMIR file which isn't accepted by the remote. Perhaps we don't have the correct variant of the executor. I guessed about that in making up the RDF file. We also need to remember that this model of remote wouldn't accept any upgrades until this morning. We may not have it fully understood yet.

ruidosobruce · Post by **ruidosobruce** » Thu Feb 12, 2015 5:49 pm

I don't know what is required to spoof a device setup code, but just changing the setup number did not work. It is still trying to use the Dish protocol PID 00 02.

Believe me, I understand and am grateful to have a working remote that would not accept any upgrades this morning. Now it does a great job of operating my entire Home Theater System, except for the Dish Receiver.

The RMIR file I have been trying to upload (and which works for everything else) is here:

https://www.hifi-remote.com/forums/dload ... e_id=13148

mdavej · Post by **mdavej** » Thu Feb 12, 2015 5:53 pm

Is this similar to the issue we have with the 8820, where it simply won't accept any protocol upgrades? Since the Dish protocol isn't built in (I assume), no dice.

ruidosobruce · Post by **ruidosobruce** » Thu Feb 12, 2015 6:27 pm

I followed a couple of quotes in the URC-8820 thread. Were those references to a substantially different C4000 remote, maybe older?

Jim-W wrote:I have a Charter OCAP-4 C4000 ordered, be here tomorrow. I noticed in the Charter manual that it supports 994 keymoves, I would think it should support keymoves in RM.

mdavej wrote:I've had a few C4000's in service for years. Should be fine for your purposes.

ruidosobruce · Post by **ruidosobruce** » Thu Feb 12, 2015 6:51 pm

The URC-1060 C4000 really is a nice remote, with good key feel, if we can just manage to get everything working. I'm willing to try whatever I can.

3FG · Post by **3FG** » Thu Feb 12, 2015 7:06 pm

mdavej wrote:Is this similar to the issue we have with the 8820, where it simply won't accept any protocol upgrades? Since the Dish protocol isn't built in (I assume), no dice.

I think we some confusion here. This thread concerns the Charter URC-1060BCx, and until this morning we had never successfully upgraded these remotes. The URC-8820 MOTO does accept upgrades-- see the recent post by Bruce where he uploaded an Apple upgrade.

mdavej · Post by **mdavej** » Thu Feb 12, 2015 8:10 pm

3FG wrote:
mdavej wrote:Is this similar to the issue we have with the 8820, where it simply won't accept any protocol upgrades? Since the Dish protocol isn't built in (I assume), no dice.
I think we some confusion here. This thread concerns the Charter URC-1060BCx, and until this morning we had never successfully upgraded these remotes. The URC-8820 MOTO does accept upgrades-- see the recent post by Bruce where he uploaded an Apple upgrade.

Yes, the 1060BCx looks the same as the older 1060 which has been supported for sometime, but internally is quite different, hence the breakthrough this morning with upgrades. Understood.

3FG, you and I collaborated quite a bit on the 8820 MOTO a few years ago. That's when we also fleshed out the first straight 5-pin JP2 interface. While you were able to get device upgrades working (thank you very much for that), protocol upgrades never did. In other words it accepts device upgrades if a built-in protocol is present, but not if a protocol has to be loaded. My theory is a similar thing may be going on with the 1060BCx. Did the Apple require a protocol upgrade, or was the Apple protocol built in? If it accepted the protocol, then my theory is wrong.

3FG · Post by **3FG** » Thu Feb 12, 2015 10:10 pm

mdavej,
I think we gave up on the 8820 before we had any MAXQ executors put into protocols.ini, and we were trying to blindly load one. At least that's how I remember it. In any case, we need Bruce to try to load an protocol upgrade made by us. I think the only one not generated by UEI is the NEC1 Yamaha 4DEV Combo executor which is in the later builds of Alpha28

3FG · Post by **3FG** » Thu Feb 12, 2015 11:18 pm

mathdon wrote:Dave (3FG), I am somewhat confused by the version numbers for the Charter remote. The RDF repository contained one called "202608 (Charter OCAP C4000 URC-1060BC2).rdf". These recent posts speak of a signature 202608 but version BC3. I have assumed these are the same remote, and have updated that existing RDF to use the new support in RMIR for segment type 0x0E. I hope this is OK. The RMIR upgrade file contains this revised RDF, also your recent one for URC-8820BC1.3, as well as the new RMIR jar file.

Looking at the URC support page for the 1060, and also the archive page, I suppose the 1060BC1 is a much older JP1.3 remote. Presumably the BC2 and BC3 share firmware, as you suggest.

Graham, I've looked at Bruce's RMIR file which has a non-functioning Dish upgrade, and although the Device Upgrade Editor shows 5 devices, including the 1775 setup code, the Segment tab only shows four 0E segments. The missing segment is of course the one which doesn't function in the remote. I tried deleting the Dish upgrade, saving a RMIR file, and re-entering it, but it still doesn't show in the Segment tab. The obvious difference to the other upgrades is that this one has a PID0002 protocol upgrade. Of course a 0E segment presumably can't handle a protocol upgrade, or perhaps we don't understand the needed format, or there is yet another type of segment for protocol upgrades.

Bruce, perhaps Graham has some additional idea, but if not, we'll have to do some more sleuthing before you can use a Dish upgrade. I hop ewe can get it to work.

3FG · Post by **3FG** » Thu Feb 12, 2015 11:20 pm

mdavej,
It turns out that Bruce has already tried to upload a protocol executor, and it wasn't successful. So far, your surmise is winning.

ruidosobruce · Post by **ruidosobruce** » Fri Feb 13, 2015 12:11 am

I may have created some confusion by having 5 devices in the Device tab, since the URC-1060 is only a 4-device remote. So, I removed the unused device and posted a revised file:

https://www.hifi-remote.com/forums/dload ... e_id=13152

In the segments you can see that the Dish device 1775 (06 EF) is in the first type 00 segment (there are 4), but RMIR did not create a coresponding type 0E segment below (there are only 3). So, it looks like the upgrade never gets to the remote.

Post by **mathdon** » Fri Feb 13, 2015 4:46 am

ruidosobruce wrote:In the segments you can see that the Dish device 1775 (06 EF) is in the first type 00 segment (there are 4), but RMIR did not create a coresponding type 0E segment below (there are only 3). So, it looks like the upgrade never gets to the remote.

Yes, RMIR deliberately does not create a type 0E segment when the device upgrade needs a protocol upgrade, as we know of no way to handle the protocol upgrade.

It is not clear to me whether UEI is now separating device upgrades and protocol upgrades into two different segment types instead of the combined upgrade being in type 10, or whether this remote cannot handle protocol upgrades. The former would make good sense, but we need an example of a protocol upgrade to see how it is formatted. Until we have that, I think the present behaviour of excluding device upgrades that need a protocol upgrade is the safest thing to do.

BTW There is no problem having as many device upgrades as you like, so you did not need to delete the 5th one. Upgrades not assigned to device buttons can still be used in key moves.

ruidosobruce · Post by **ruidosobruce** » Fri Feb 13, 2015 8:54 am

mathdon wrote: BTW There is no problem having as many device upgrades as you like, so you did not need to delete the 5th one. Upgrades not assigned to device buttons can still be used in key moves.

That was my theory in the first file I posted: I had 5 devices in the Device tab, but then in the General tab, I only assigned 4 of them, one for each remote device type, thinking that the 5th device could just sit, ignored by RMIR. But, RMIR didn't work that way. When it skipped the 4th type 0E device for the reasons you said, it just went and got the 5th device and used it instead, making a confusing result