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

Trouble with code 0775

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
dairiki



Joined: 06 Nov 2003
Posts: 8
Location: Seattle, WA

                    
PostPosted: Thu Nov 06, 2003 12:11 pm    Post subject: Trouble with code 0775 Reply with quote

Hi!

I've got a URC-8811 and have been happily using extender 3 (6012ex3_1.zip) on it for awhile. (Great work!)

Now we've just gotten hooked up with a Dish PVR-510 satellite receiver.

On a stock (non-extended) URC-8811, code 0775 works fine.

With extender 3 running, only every other key-press seems to work.

I suspect there is a "toggle bit" in the IR code which isn't toggling (or maybe
vice versa)?

Any hints?

Thanks!
Back to top
View user's profile Send private message Send e-mail
dairiki



Joined: 06 Nov 2003
Posts: 8
Location: Seattle, WA

                    
PostPosted: Thu Nov 06, 2003 1:58 pm    Post subject: More information Reply with quote

After looking at the transmitted IR (using xmode2 from the LIRC package),
I think I've concluded that the extender 3 is not the problem.

The stock remote sends one extra IR blip at the end of a command.

Here's some screencaps from xmode2.
Stock remote, a single press of the up arrow:


URC-8811, single press of the up arrow:


Note the extra blip at the end of the signal from the stock remote.


Again, the problem is: sending a single command from the urc-8811 doesn't
work. Sending the command twice does. I think the start blip of the second
command makes the first command "take".

Can this be fixed via device/protocol upgrades? How?

(I suppose this is posted in the wrong forum, now, since it doesn't seem to
have anything to do with extender 3. Should I repost in another forum?)

Thanks!
Back to top
View user's profile Send private message Send e-mail
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21211
Location: Chicago, IL

                    
PostPosted: Thu Nov 06, 2003 2:17 pm    Post subject: Reply with quote

No probs, I moved it for you.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
dairiki



Joined: 06 Nov 2003
Posts: 8
Location: Seattle, WA

                    
PostPosted: Thu Nov 06, 2003 4:12 pm    Post subject: Possibly related thread of RemoteCentral Reply with quote

This thread may be related (not that it contains any solutions):
http://remotecentral.com/cgi-bin/mboard/rc-one4all/thread.cgi?3283
Back to top
View user's profile Send private message Send e-mail
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21211
Location: Chicago, IL

                    
PostPosted: Thu Nov 06, 2003 4:26 pm    Post subject: Reply with quote

and this...
http://www.remotecentral.com/cgi-bin/mboard/rc-pronto/thread.cgi?23443
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Thu Nov 06, 2003 4:48 pm    Post subject: Reply with quote

I don't see how either of those threads explains the issue here. I think the waveforms here explain one of the issues there.

The notes I have for Dish say the structure (in the new IRP notation) is

{38.4k,535,msb}<1,-5|1,-3>(1,-11,(F:6,U:5,D:2,1,-11)+)

Your recorded 8811 waveform looks like it was generated by
{38.4k,535,msb}<1,-5|1,-3>(1,-11,F:6,U:5,D:2)+

I don't have time to check now, but I expect the 8811 just gets it wrong and it would be fairly easy to patch (with a "hacked protocol").

Since an extra frame seems to cover up the problem, it's easy to understand why you saw it in extender fast macros and not in normal slow macros.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
dairiki



Joined: 06 Nov 2003
Posts: 8
Location: Seattle, WA

                    
PostPosted: Thu Nov 06, 2003 5:08 pm    Post subject: Reply with quote

Thanks johnsfine!

Any quick pointers on how to go about hacking up a protocol? I've been web-surfing for awhile now and haven't really figured out much in that regard. Pointers to docs/tutorials would be appreciated.

(The thread I referenced indicated to me that perhaps recent firmware changes in the Dish receiver have made it pickier about the IR codes it receives. It appears there are many happy users of code 0775 for Dish PVRs. This may explain why I seem to be one of the few having trouble.)

(The second thread, I agree, is unrelated, I think.)
Back to top
View user's profile Send private message Send e-mail
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Thu Nov 06, 2003 5:18 pm    Post subject: Reply with quote

I certainly agree with John's analysis but only a minor technical correction since SAT_0775 is Dishplayer (old):

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


{57.6k,400,msb}<1,-7|1,-4>(1,-15,F:6,U:-5,D:5)+ What the 8811 is sending out

I wonder if the 8910/9910 and 2116/2117 have this problem?
_________________
-Jon


Last edited by jon_armstrong on Thu Nov 06, 2003 8:13 pm; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail Visit poster's website
dairiki



Joined: 06 Nov 2003
Posts: 8
Location: Seattle, WA

                    
PostPosted: Thu Nov 06, 2003 7:08 pm    Post subject: Working Hackaround Reply with quote

I've got something which works better (but is not yet just exactly perfect).

I've created an upgrade device (more or less a copy of the stock 0775 code -- I've given it device number SAT1775). Then I entered the following upgrade protocol (number 00 02) in IR.exe:

2B 5C 21 8B 14 B7 59 05 06 00 C5 03 32 00 C5 05
73 0B F2 00 C5 0B F2 05 03 8D 01 46

This I snarfed from RemoteMaster's protocols.ini, except that I replaced
the fourth from last byte, which was an $02, with the $03. This (from other
posts) I have ascertained to be the repeat count.

Now the remote sends three reps of each command (still without a trailing ping)
and the receiver seems to like that. Razz

It would be great if someone who understands this better can:
1. Check to make sure I've not done anything excessively stupid.
2. Tell me how to get two reps + 1 extra trailing ping, like the factory remote sends out.

Thanks for the help so far!
Back to top
View user's profile Send private message Send e-mail
dairiki



Joined: 06 Nov 2003
Posts: 8
Location: Seattle, WA

                    
PostPosted: Thu Nov 06, 2003 7:33 pm    Post subject: Another connected thread... Reply with quote

For yet another upgrade protocol which solves the problem in a similar fashion, see:
http://groups.yahoo.com/group/jp1/message/28739
Back to top
View user's profile Send private message Send e-mail
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Thu Nov 06, 2003 8:31 pm    Post subject: Reply with quote

Probably the easiest way is to use Protocol Builder. If you don't understand the irp notation that John invented, I have put together a series of John's postings on that subject and in response to some questions that I asked in the old JP1-KM Yahoo forum.

While you are at it you might use the mini-device combiner feature to allow for a call to device 16 that is needed for certain transport commands.

I'll be glad to help.
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
dairiki



Joined: 06 Nov 2003
Posts: 8
Location: Seattle, WA

                    
PostPosted: Fri Nov 07, 2003 2:31 pm    Post subject: Reply with quote

Thanks, Jon!

I think I more-or-less understand John's IRP notation, but I'd love to see your compilation of posts on it.

I've looked at Protocol Builder a bit. A problem is I'm a Linux-head, and the PB spreadsheet doesn't seem to work in OpenOffice (though it does open, and is more-or-less readable).

Also, after reading the PB readme, I'm not sure it will do exactly what I want anyway. Note that what I want (or rather what the receiver wants) is not


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

but rather

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

(I'm not sure about the trailing -15 --- but one extra blip is needed.)


And what's this now about about device 16? I think I've currently got all functions
working now with the hacked 00 02 protocol.

Thanks for the help.
Back to top
View user's profile Send private message Send e-mail
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Fri Nov 07, 2003 6:26 pm    Post subject: Reply with quote

The expression inside the (F:6,U:-5,D:5,1,-15)+ repeats one or more time, so you always get the last blip. The leading 1,-15 does not repeat since there is no + at the end of the entire expression.

I think that Star Office has problems with all the hex2dec, bin2hex, etc. functions so it probably will be an exercise in frustration to try to use PB. I think that once you get something to work unless it is unreleiable or very ineficient, it is probably better to leave it alone.

Best I can tell, (I don't have any Dish equipment) the device =16 is needed only on some PVR models when you are using a unit code >0. Most seem to ignore that requirement when the unit code=0.

BTW, unit code+1=system address in Dish documentation. The U:-5 also means those bits are backwards in comparison to the others that are first bit=MSB.

Let me know if you need anything, my email is in my profile.
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
dairiki



Joined: 06 Nov 2003
Posts: 8
Location: Seattle, WA

                    
PostPosted: Fri Nov 07, 2003 6:44 pm    Post subject: I really wan't [i]two[/ii] lead-out bursts... Reply with quote

jon_armstrong wrote:
The expression inside the (F:6,U:-5,D:5,1,-15)+ repeats one or more time, so you always get the last blip. The leading 1,-15 does not repeat since there is no + at the end of the entire expression.


Yes, but look carefully at the xmode2 traces I posted above.
If you look at the top trace:

There's a lead-in burst, followed by a long gap. [The leading 1,-15]
Then 16 fixed/data bursts [the (F:6,U:-5:D:5]
... followed by a lead-out/lead-in burst (and then a long gap) [the 1,-15)]
Then 16 more fixed/data bursts with] a lead-out burst. [ another (F:6,U:-5,D:5,1,-15)]
Then (after a long gap):
A final, second, lead-out burst [an additional 1,-15].

(I.e. there's seventeen bursts in each of the burst clusters:
lone lead-in, burst-of-seventeen, burst-of-seventeen, lone lead-out)

The final, second, lead-out burst is what's missing from the URC-8811's output.

See what I mean?
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum 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