|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
dairiki
Joined: 06 Nov 2003 Posts: 8 Location: Seattle, WA |
Posted: Thu Nov 06, 2003 12:11 pm Post subject: Trouble with code 0775 |
|
|
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 |
|
|
dairiki
Joined: 06 Nov 2003 Posts: 8 Location: Seattle, WA |
Posted: Thu Nov 06, 2003 1:58 pm Post subject: More information |
|
|
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 |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Thu Nov 06, 2003 2:17 pm Post subject: |
|
|
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 |
|
|
dairiki
Joined: 06 Nov 2003 Posts: 8 Location: Seattle, WA |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Thu Nov 06, 2003 4:48 pm Post subject: |
|
|
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 |
|
|
dairiki
Joined: 06 Nov 2003 Posts: 8 Location: Seattle, WA |
Posted: Thu Nov 06, 2003 5:08 pm Post subject: |
|
|
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 |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Thu Nov 06, 2003 5:18 pm Post subject: |
|
|
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 |
|
|
dairiki
Joined: 06 Nov 2003 Posts: 8 Location: Seattle, WA |
Posted: Thu Nov 06, 2003 7:08 pm Post subject: Working Hackaround |
|
|
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.
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 |
|
|
dairiki
Joined: 06 Nov 2003 Posts: 8 Location: Seattle, WA |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Thu Nov 06, 2003 8:31 pm Post subject: |
|
|
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 |
|
|
dairiki
Joined: 06 Nov 2003 Posts: 8 Location: Seattle, WA |
Posted: Fri Nov 07, 2003 2:31 pm Post subject: |
|
|
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 |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Fri Nov 07, 2003 6:26 pm Post subject: |
|
|
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 |
|
|
dairiki
Joined: 06 Nov 2003 Posts: 8 Location: Seattle, WA |
Posted: Fri Nov 07, 2003 6:44 pm Post subject: I really wan't [i]two[/ii] lead-out bursts... |
|
|
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 |
|
|
|
|
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
|