JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Dish Network Pronto Hex conversion Help!

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Protocol Decodes
View previous topic :: View next topic  
Author Message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Mon Apr 02, 2012 9:02 am    Post subject: Dish Network Pronto Hex conversion Help! Reply with quote

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
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Mon Apr 02, 2012 10:36 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Mon Apr 02, 2012 11:46 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Mon Apr 02, 2012 12:15 pm    Post subject: Reply with quote

I'll look at it tonight.
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon Apr 02, 2012 2:59 pm    Post subject: Re: Dish Network Pronto Hex conversion Help! Reply with quote

mdavej wrote:
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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Mon Apr 02, 2012 3:19 pm    Post subject: Reply with quote

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:

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
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon Apr 02, 2012 3:34 pm    Post subject: Reply with quote

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.)
Back to top
View user's profile Send private message Send e-mail Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Tue Apr 03, 2012 12:31 am    Post subject: Reply with quote

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:
 {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.
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Tue Apr 03, 2012 8:35 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Tue Apr 03, 2012 10:23 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Tue Apr 03, 2012 10:38 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Tue Apr 10, 2012 2:54 pm    Post subject: Reply with quote

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.

3FG wrote:
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.

mdavej wrote:
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".)

Back to top
View user's profile Send private message Send e-mail Visit poster's website
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Tue Apr 10, 2012 5:15 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Protocol Decodes All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control