Unknown protocol in Dish UHF Pro remote

[Tommy Tyler]

Recently Dish discontinued support for my old Model 710 DVR Receiver and made me upgrade to a Model 522. This is a dual tuner receiver, and Dish supplies two remotes with it, an IR type and a UHF type. The IR protocol and commands are unchanged (DishNetwork) and my old Dish remotes will operate the new receiver. But the UHF system (which seems to be much improved) is not compatible with old remotes, and requires what Dish calls their "UHF Pro" model remote. I decided to investigate to try and determine what they had changed, and whether I might adapt my older Dish remotes somehow, since I need their UHF capability for controlling the DVR from other rooms.

The original Dish remotes were combination IR/UHF, with a little PCB built-in that contained the 384MHz UHF transmitter, consisting of 27 components and a small loop antenna. The transmitter is gated on and off by a separate signal from the processor that is a demodulated version of the IR carrier signal that drives the LEDs. There are only three connections to the transmitter board, power, ground, and data signal.

The transmitter board in the UHF Pro remote is much more complex. It uses the same loop antenna, but there are over 40 components on the board, including a 24-pin IC and a 5.772MHz crystal. It is attached to the remote's main PCB with an 8-conductor ribbon cable. Other than power, ground, and a signal, I can't imagine what the other five connections might be for. I probed around and found the only connection that seemed to have a data signal on it, and recorded a sample while pressing the GUIDE button of the remote. I had expected (hoped?) to find some minor variation of the standard DishNetwork signal, but I'm completely baffled by what I found. The drawing below shows the signal.

http://img133.imageshack.us/img133/2730 ... idepw9.gif

Code: Select all

10 01 11 10 01 11 10 10 01 10 01 10 10 10 10 10 10 10 10 10 10 10 01 10 10 01 01 01 01 01 01 10

The signal goes high when the transmitter is gated on, and the ON periods are precisely 1/2, 1, or 2 milliseconds. I've put a "1" everywhere the signal is ON, and a "0" where off. It seems to me as if there is some kind of pairing of the signal (my green lines), perhaps RC5 or RC6, but I'm not well versed in those protocols.

This looks like really bad news for old remotes, as it looks like Dish has decided to transmit a completely different protocol over the UHF link than that on the IR link. For the life of me I don't know why anyone would want to make them different, unless the chip on the transmitter board has its own built-in protocol that is matched by a chip in the UHF receiver.

Can anyone make any sense of this signal?

Tommy

[vickyg2003]

Hi Tommy,

As you know, I'm just a student when it comes to protocol decodes, but I don't think anybody can make sense of just one signal. Protocol decodes are really a pattern study. The bigger the sampling the better the understanding.

I think with this particular situation, finding out whether the command is the same in IR and UHF would also be important.

Vicky

[Tommy Tyler]

I was afraid someone would say that. Let me go back and get the number keys.

[unclemiltie]

Tommy

If you figure this out, there are a ton of people who will thank you! (myself included). Dish changed over from the old UHF/IR remotes with the two-ouptut tuners (522, 622, etc) and I have been playing with upgrades for quite a while trying to figure out how to make the TV2 output IR controllable.

My contacts at Dish tell me that it can't be done but it seems to me silly that the receiver has an IR receiver in it and the software would have to take and do extra work to ignore an IR coming in that mimics the RF protocol, but hey I didn't design the silly things.


(and yes, they made me get rid of my 721 which had both IR and UHF from the remote and replace it with a 522 as well)

[The Robman]

It does appear to be similiar to the RC6 format. Take a look at the ReplayTV signals, which are a variant of RC6. Their format is as follows:

Code: Select all

Off +6 -2 1110 -2 +2 00000001 00000000 00001110 -0f64
On  +6 -2 1110 -2 +2 00000001 00000000 00001101 -0f64

Here's the pronto hex:
http://www.remotecentral.com/cgi-bin/fi ... ytv&dv=dvr

[Tommy Tyler]

Here are the numeric keys.

http://img258.imageshack.us/img258/2869 ... itebg2.gif

Tommy

[The Robman]

The numeric buttons are one pair longer than the GUIDE button that you learned earlier (ie, 33 vs 32).

Here are the signals in binary form, where "10" is represented as 1, "01" is represented as 0 and the double wide bit "11" is represented as x.

Code: Select all

G = 10x10x11010111111111110110000001

0 = 10x10x110111011111111111010101010
1 = 10x10x111101111111111110000100011
2 = 10x10x111101011111111110011010100
3 = 10x10x111100111111111110111001101
4 = 10x10x111011111111111111100101110
5 = 10x10x111011011111111111111011001
6 = 10x10x111010111111111111011000000
7 = 10x10x111001111111111110011110010
8 = 10x10x111001011111111110000000101
9 = 10x10x111000111111111110100011100

[Tommy Tyler]

Well it doesn't look like a simple binary coding because there is not a "1" (or "0") in the same position for all odd numbered keys, nor likewise for all even numbered keys. Plus there are way too many bit changes than would be required just to represent the numerical keys. The first seven and last ten bits almost seem to be random sequences.

[vickyg2003]

Well it doesn't look like a simple binary coding because there is not a "1" (or "0") in the same position for all odd numbered keys, nor likewise for all even numbered keys. Plus there are way too many bit changes than would be required just to represent the numerical keys. The first seven and last ten bits almost seem to be random sequences.

It appears to me that the first 7 bytes are the command bytes. I think you are not seeing the 1's and 0's in the same postion for all odd numbered keys because the obc's that would be a multiple of 4 are skipped. What baffles me is why the guide is shorter than the other signals.