Dish Network Pronto Hex conversion Help!

[mdavej]

Hey guys and gals. I need some help converting Dish network codes to Pronto Hex for Logitech. They've asked me for all 32 remote addresses. But I have no idea how to do it using our tools, like Make Hex. I hope it's something simple.

Starting with an upgrade like THIS, I can change the remote address to any value (1-32) and see the first byte of the fixed data change. How do I account for this in Make Hex, the IRP or the raw pronto hex itself?

EDIT: A little more info. I noticed that for address 1, the code I get from Make Hex is slightly different than THESE codes someone posted at remote central. Any idea which is more correct or if it makes any difference? For example 0018 00A5 I get from make hex is 0017 00A3 in the posted codes. The codes I get from IRP Master are very different, so I'm not sure I can trust them. I'd like to stick with make hex if I can.

Thanks

[3FG]

According to DecodeIR.html, the unit number (or, more likely, the unit number - 1) should be put into the sub device in MakeProntoHex. The RC samples you gave decode as sub device 0, but I suppose that the unit numbers actually start at one.

The MakeHex output and the RC ProntoHex are very similar, with the same modulation frequency. The RC learns have durations which on average are shorter by 2 or 3%. The IRP given in DecodeIR.html shows a basic time period of 400uS, while the irp file gives 410.

If it were me, I would edit the irp file to have a basic period of 400, since that would agree with the RC learns and the IRP notation in DecodeIR.html.

[mdavej]

Thanks. I still see that different bytes change in the fixed data depending on if you change a subdev or the remote address in RM. As a sanity check, can you look at THIS file, which I think confirms changing the second subdev (not the first) will do the trick? That file contains various captures from my RCA remote and my original Dish remote using different addresses and capturing commands for num 1, 2 and 3 (OBCs 4, 5, and 6). It does appear that what Dish calls remote address is 1 based and the actual subdev codes are 0 based. Also do the captures confirm that 400 in the IRP is still the best value to use?

[3FG]

I'll look at it tonight.

[Barf]

The codes I get from IRP Master are very different, so I'm not sure I can trust them. I'd like to stick with make hex if I can.

The IRP, both in DecodeIR.html and IrpProtocols.ini, says (1,-15,(...)+ ). I.e., the inner parenthesis is sent at least one time. Therefore, at least how I interpret things, the intro sequence (in Pronto terminology) consists of one copy of the parenthesized expression. Thus, it starts 0000 0048 0012 0011 while Makehex obviously interprets the "IRP" as (1.-15,(...)*...), starts 0000 0048 0001 0011 and does not contain the parenthesized expression in the intro.

IMHO, the Makehex rendering is senseless; sending just one pulse and one gap does not make any sense at all.

Having understood this, one can observe that the Makehex and the IrpMaster renderings otherwise differ only in rounding errors. If the (...)* interpretation is desired, just change your copy of IrpProtocols.ini, or persuade us that IrpProtocols.ini and DecodeIR.html should be changed accordingly.

[mdavej]

I'm the wrong person to ask since I have almost no understanding of pronto hex or IRP. I just observed a significant difference. The pronto hex generated from the learns in IR Scope is pretty close to that from makehex. I have no idea what might be wrong or what may need to change.

Perhaps I don't know how to use IR Master, but here's one example using Dish_Network 0.0, function 4.

Code: Select all

IrpMaster results in
{57.6k,400}<1,-7|1,-4>(1,-15,(F:-6,S:5,D:5,1,-15)+) [F:0..63,S:0..31,D:0..31]:
0000 0048 0012 0011 0017 015A 0017 00A1 0017 00A1 0017 00A1 0017 005C 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 015A 0017 00A1 0017 00A1 0017 00A1 0017 005C 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 015A

MakeHex results in:
0000 0048 0001 0011 0018 0162 0018 00A5 0018 00A5 0018 00A5 0018 005E 0018 00A5 0018 00A5 0018 00A5 0018 00A5 0018 00A5 0018 00A5 0018 00A5 0018 00A5 0018 00A5 0018 00A5 0018 00A5 0018 00A5 0018 0162

IRScope from learn results in 
(8 frames with lead-in on only the first frame 
{57.1k,141,msb}<3,-12|3,-20>(3,-44,(A:16,3,-44)+){A=$EFFF}; Alt leadout form: ^58m):
0000 0049 0001 0011 0018 015E 0018 00A1 0018 00A1 0018 00A1 0018 005F 0018 00A1 0018 00A1 0018 00A1 0018 00A1 0018 00A1 0018 00A1 0018 00A1 0018 00A1 0018 00A1 0018 00A1 0018 00A1 0018 00A1 0018 015E

[Barf]

Your latest post does not contradict mine in any way. Repeating myself, to mimic MakeHex' (IMHO incorrect) behavior, replace "+" with "*" in the IRP. (Yes I have tried it.)

[3FG]

I've gone through the signals more carefully, estimating the total period of each signal, and then dividing by the number of unit times contained in each signal. I have access to more recorded signals from URC and RTI learning hardware and I've included those in the estimate. The unit time estimates vary from 402 to 408 uSec, with an average of about 406 uSec. The UEI remote is typically 403, while the Dish remote is typically 408. As is often the case with signals represented in IRP, the real signals deviate from the implied 4:7 ratio for 0 and 1 signals-- that looks to be closer to 4:6.8 (or so). I'd use something between 400 and 410; 406 is reasonable.

Some of the other learns I have confirm that remote address equals subdevice + 1, just as you've seen.

The IRP

Code: Select all

 {57.6k,406}<1,-7|1,-4>(1,-15,(F:-6,U:5,D:5,1,-15)+)

is correct.

Regarding the Pronto Hex representation, I believe the form preferred by Barf is legal, and would be correctly handled by most remotes. However, it isn't the normal representation, as one can see by examining published Pronto Hex for Dish Network IR signals. As mdavej has observed, the form produced by Make Hex is the usual format. It too is legal and is simpler and shorter.

The point of Pronto Hex (the type that begins 0000) is to represent learned or imported signals. When viewed from that perspective, any real Dish Network signal is a single burst pair 1,-15, followed by some number of (F:-6,U:5,D:5,1,-15) signals.

Theoretically, a remote programmed with the shorter Pronto Hex could produce a stub signal consisting only of 1, -15. But any real remote has debounce circuitry that will prevent this, and of course a real person can't press a button for less than 6 mSec.

[mdavej]

Thanks, Barf. I see your point now.

Thanks, 3FG for the detailed analysis. I want to also confirm that the zero-based remote address goes in the Sub b field in MakeHex, not Main a. Is that correct?

Sorry for being so dense.

[3FG]

Yes, that's right. You can verify that by using the Import feature of IRScope, and check that the output of MakeHex is decoded as expected.

[mdavej]

Sweet. I didn't know you could do that with IRScope. Spot checking my codes with Import, they look good. Thanks for all the help.

[Barf]

I have implemented an IrpMaster option that makes IrpMaster behave the (possibly in strict sense incorrect) way mdavej expects. In order not to "threadnap" his thread, it is described here.

The IRP
Code:
{57.6k,406}<1,-7|1,-4>(1,-15,(F:-6,U:5,D:5,1,-15)+)
is correct.

Thanx. I will update IrProtocols.ini for the next release.

Sweet. I didn't know you could do that with IRScope.

You can do it all within IrMaster too. I.e. rendering with Makehex (java version) alternatively IrpMaster, and sending to DecodeIR, all without leaving the program. See screenshot below.
(Generated by selecting Makehex, selecting protocol and parameters (0 0 4), pressing "Render" and then "Decode".)

[mdavej]

Thanks for the follow up and the effort Barf. I'll check it out. I love your program BTW. I've barely scratched the surface so far.