DishPVR 721 questions

[jon_armstrong]

David I just posted a device and protocol upgrade using a Protocol created in PB, that is a mini combiner.

I also made my mini combiner do unit code 0 (system address 1) or unit code 1(system address 2), so depending on EFC you an do commands from device 0 or 16 for either system address. You can also create this with another device upgrade and set the unit code in sub-device. I have put the sub-device by system address under the notes in functions. One useful feature for the system address switch within EFC's is that Unit code 31 is apparently an all units code, if you want to turn off all dish gear with one command (assuming they all recognize the discrete codes).

It might be worth adding the paragraph above to the zip file.

I definitely want to make sure it's clear. We may want to work on a readme file together.

Couple of questions. You mention that the combiner does unit code 0 or unit code 1. But, on the functions page you list all the unit codes. So will the all work, or only after adding a new set of converted EFCs.

There are two possibilities here:

1. By EFC you can call the alternate unit code, if that has any practical value, OR

2. You just create a second device upgrade and put in the Device 2 value that I put in the remarks of the functions tab by system address.

I think 2 is the easiest to explain and if you have two dish units you would need a second device upgrade. You only need one copy of the protocol however. Also in option two, you don't need to change any EFC's in the device upgrade, just change the device2=unit code(bits backwards).

You also say that the alternate unit code is selected with the sub-device field. Is that the device 2 field on the main page?

Yes, per the explanation above that would be option 2

My originaly goal here was to find a easy DishNetwork upgrade for the jp1 newbies. Witch considering the two Device Codes combined with 6131 keymove difficulties really didn't exist (the 1994 burying the unit code in the EFC doesn't help either).

I think we just fixed that part, is there anything different about a device upgrade for the 6131. IIRC, keymoves are done differently.

I'll get this guy tested on the 1994 and 6131 ASAP. I also have a URC9800 (which won't work), RCA 810, & Millenum 4 floating around, but those don't seem to be as much in the mainstream.

For the URC9800, I think if you open the protocol upgrade using Protocol Builder, you should be able to switch to the 740 remote and replace the protocol. You copy paste|special values into the notes section on the setup tab.

Let me know if you need any help.

[unclemiltie]

jon

I tried last night the mini-combiner on both an RCU810 and a 2117 with my DishPVR 721 and it works great. The only thing I haven't been able to figure out is how to set the satellite ID in this thing.

But, my issues with some Macros not working on the extended 2117 have been resolved AND it's a good bit smaller than the previosu upgrade.

(my previous RCU810 upgrade was 181 bytes, this one is 107.

[The Robman]

I haven't been following this thread for a while (so forgive me if any of this has already been covered), but someone asked me to create an upgrade for the PVR721, so now I'm here.

AFAIK, the current version of the $0002 protocol is a mini-combo protocol, which lets you combine up to three device codes into one upgrade. Therefore, if you set the first device code to 0 and the second device code to 16, you can then use the byte2 column to select one or the other when you're entering the OBCs. Is this correct?

I've downloaded a CCF file for the PVR721 and used DecodeCCF to extract the data, and I then used this data to build an upgrade for the URC_6131, which is here: Dish_Network_PVR721.txt. Would this work?

As for KM and RMs support of the Dishplayer (Old) protocol, while we have gone to great efforts to follow a "one fits all" approach, maybe we need to have a second entry where the user can positively select the combo version, and if their remote has one of the older versions, we just provide a protocol upgrade. Thoughts?

[jon_armstrong]

Rob,

I realized that PB could create a Dishplayer (old) combo protocol with one variable byte. So I wrote that and modified David's device combiner device upgrade to use the new protocol. I made it compatible with the existing EFC's. I also had it do a minimum of 5 repeats. By coincidence, if you add 16 to the EFC you call the alternate device 16.

If you go back a few posts, I have links to the modified device upgrade with the new protocol ($0102) and the PB file too. In PB (since the OBC is only 6-bits) I have also hard coded an alternate unit code 1, so with one protocol you can call either unit 0 device 0 or 16 AND unit 1 device 0 or 16. I don't know how much practical value that is, but it doesn't make the protocol any larger. You can also enter the unit code in the sub-device in the Setup tab and make a second device upgrade, (but you have adjust in order to enter the bits backwards). I put that conversion in the remarks in the functions tab.

This seemed easier than using the $0002 version in the newest remotes that IIRC is a pretty big protocol because it can do Dishplayer and Dishplayer (old) (and I gave away my 8910 to David Vasquez to write the extender and I didn't have one to test and it still took two variable bytes).

So, at the end of the day we can solve the entire problem with a master device/protocol upgrade and people can use the buttons tab to put the commands where they want. This should work for anything using Dishplayer (old) protocol.

[The Robman]

But I'd still like to know if the upgrade I created, using the URC-6131's built in protocol, would work. Do you think it would?

[David_Levin]

Rob,

I can try your 6131 upgrade with my 921 tonight. I'm pretty sure the 721 and 921 are the same.

I assume you still need to keymove in the PIP keys at the remote?

EDIT:
Wow, the light bulb is turining on. So protocol 002 is not the same on all the remotes? They don't all support the dual devices?

I didn't realize switching to OBC mode activates the "byte 2" column. Assuming it works, this certainly looks to be the simplest for the remotes with the newer Protocol. And, poping up a protocol upgrade for the remotes that need it makes sense (1994?). I sure can't keep track of what needs what.

PS: I'd try to get the view key in there somewhere. It's handy to kill all menus and get back to watching TV. Since the 6131 has so many keys available, I like leaving the channel up/down where they belong (duplicate the up/down arrows), and using chaper skip and/or thumbs for page up/down (because of the thumbs key position I reversed the right-most thumb for page down).

Also, you'd get a few more available keys if you make is a PVR device (instead of SAT). Still not sure about keymoves? Does KM and RM now support the special 6131 keymoves?

I have a 2nd (guest) room that accesses the 921. I'm currently using a Millenium 4 in there. Which version of the 02 prococol does this have? Is jon_armstrong's new mini-combiner the protocol the one we would use, or does a new one need to be developed?

[David_Levin]

Rob,
I'm not sure it matters, but your EFC codes don't seem to match what I would expect.....

Again, I can try it with my 6131 (from you) when I get home.

[The Robman]

David,
While the file I posted uses SAT mode, the one I created for the user actually uses PVR mode. With the extra buttons available, I used Audio, Subtitle and Angle for the 3 PIP commands. Don't worry about the EFCs with this code, as these will differ based on how you set things up, it's the OBCs that matter.

I just took a closer look at the current official UEI version of the $0002 protocol (which is what's in the URC-6131) and it's very well written and very efficient. It's only 5 bytes longer than the one Jon generated using PB, but that's because it also supports a different carrier frequency in addition to the 3-dev combo feature.

If we decide not to support the alternative frequency, we could strip out 17 bytes from the code, reducing it to just 38 bytes.

[David_Levin]

Even on the 6131, I'm nowhere near running out of memory - so a few bytes here or there....

I really like having keys where they belong when ever possible. As such, I'm good to keymove in the pip keys.

Guess the problem is that if the keymove needs to be done at the remote, the keys must be assigned somewhere (then they're wasted if they are part of the main upgrade). We used to be able to enter keymoves with (setup button+EFC), but I'm guessing this will not work here because of the 2 byte command.

Personally, since I heve plenty of memory, I'd still upload a 2nd device to act as a source for the key moves.

[The Robman]

When the URC-6131 is fitted with a 2k EEPROM, it's by far the best JP1 remote as far as upgrade memory goes. The normal upgrade memory is 0.75k but in the URC-6131 it's 1.75k.

However, we still like to keep our upgrades as tiny as possible because somebody somewhere is running out of memory and will appreciate it.

I was limited to using keymapped buttons for the application I was programming because I was creating 10 upgrades each with a different unit code and then using the device multiplexor to switch between them. Keymoves are not good for this situation because they can only be tied to one setup code (and therefore, one unit code).

Even though you have tons of upgrade memory in the URC-6131, you only have the normal amount of keymove/macro memory. If you create the keymoves (on the remote itself) using advanced codes this will result in 6-byte keymoves, but if you create them by copying the buttons from one place to another it will result in 5-byte keymoves. For the latter style of keymove, the hex byte is the keycode of the button that the code comes from, so you could easily figure this out and program them by hand in IR.exe (if you want).

I was able to program every single PVR721 button that was in the CCF file into an upgrade using the VCR device type, so you'd only need one upgrade. If you have discovered a couple of extra buttons that aren't in my upgrade file, you could always program them to the volume buttons for the sole purpose of including them in keymoves.

[johnsfine]

I was limited to using keymapped buttons for the application I was programming because I was creating 10 upgrades each with a different unit code and then using the device multiplexor to switch between them. Keymoves are not good for this situation because they can only be tied to one setup code (and therefore, one unit code).

I'm sure you know how to tweak a protocol to get the unit (subdevice, I assume) from a spare register rather than from the device upgrade. Then you could do it all with a single setup code, supporting KeyMoves. Then use the advanced select special protocol (instead of device multiplexor) to operate the selection process.

[jon_armstrong]

But I'd still like to know if the upgrade I created, using the URC-6131's built in protocol, would work. Do you think it would?

Unfortunately, I don't think that upgrade will work. KM Master still thinks dishplayer (old) is LSB first. DecodeCCF thinks that everthing is MSB first, except Unit code, that is LSB first. So using DecodeCCF decoding and plugging in OBC's into KM won't work.

The EFC's are correct from DecodeCCF. To use KM you would need multiply OBC's by four and reverse the bits for "OBC". The Unit code would be correct. I don't know if KM correctly sets up fixed data correctly for the latest variation of $0002.

[David_Levin]

Ok, I see (but then much of johnsfine (expert) is over by head.

Rob - It may not be important, but your upgrade is missing the TV/VCR key. One the 721 this button selects a pass-thru select for the coax-in to coax-out). Most probably don't use this.

On the 921 this button becomes HD/SD select which is important because the hi-def (dvi and component) and std-def outputs aren't active at the same time.

I'm not sure how to add this to your spreadsheet since the EFC and OBC don't seem to match anything I'm used to (it was EFC 176).

[The Robman]

Unfortunately, I don't think that upgrade will work. KM Master still thinks dishplayer (old) is LSB first. DecodeCCF thinks that everthing is MSB first, except Unit code, that is LSB first. So using DecodeCCF decoding and plugging in OBC's into KM won't work.

Why does DecodeCCF treat it as MSB? If a 5 bit device code field alternates between 00000 and 10000 I would assume it was LSB and the codes were 0 and 1, rather than MSB with codes 0 and 16.

[jon_armstrong]

AFAIK, there are only two device codes 0 and 16 MSB. The unit codes are clearly LSB. However, the numerals line up pretty much as as MSB and there are a several other Dish protocols that aren't used as much any more that have 5-bit OBC's that line up with the first 31 commands of the lower 5-bits MSB of the 6-bit versions. KM has always treated the Dishplayer protocol as MSB (many of the OBC's are also the same as Dishplayer (old)).

IIRC, when John wrote the new decoder we discussed this all about a year ago and DecodeIR.dll has always worked that way. The original version of ccf2efc called it JVC-A and the One/Zero defitions were reversed and it was LSB first.

I believe the RM is also setup to work with DecodeIR.dll as I described it earlier.