|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
Posted: Thu Apr 01, 2004 12:58 pm Post subject: Dishplayer (Old) protocol |
|
|
I take it we're all in agreement that the sub-device (aka "unit code") is LSB, and I think it should be obvious from the data that the device code is also LSB (ie, we've only seen 2 values and those are 00000 and 10000). So I would recommend that DecodeIR and RM treat the device code as LSB also.
As for the OBCs, I would agree that they appear to be MSB.
So my question is this, do we really want to start maintaining a protocol as a mixture of both MSB and LSB components? Given that the command codes only use 6 bits, the range of possible OBCs is 0 thru 63, and most of that range is already covered by known commands, leaving very few gaps. It seems to me that we are forced to recognize the fact that the sub-device is LSB because it's directly tied to what the user calls "unit code" (ie, it's one less than the user's "unit code"), and the evidence tends to indicate that the device code is also LSB, so therefore why not just treat the whole protocol as LSB?
I took a look at the protocols.ini file for this protocol and I see that it was a conscious decision to make RM & DecodeIR incompatible with KM, do you really think this was a wise decision? Are there any other examples where KM and RM have been made to be incompatible? I think it would be wise when an occassion arises where you want to change the way a protocol is treated, you should consult all the involved parties so an agreement can be reached, then ALL the tools can be adjusted at the same time.
I'd like to get all the tools in sync with each other, and here's what I suggest...
1) KM will need to be changed to start supporting protocols where the device codes and command codes don't share the same polarity.
2) I'd like to rename the protocol to "Dish Network". I gave it the "Dishplayer (Old)" name and I now think that was a bad idea.
3) I would like to support two different versions of this protocol, one simply called "Dish Network" and the other called "Dish Network Combo". The first version would only support 1 device code and 1 unit code. KM/RM would need to be smart enough to know which version of the protocol (if any) is installed in the remote, so it would know whether to format 2 8-bit bytes, or three 5/5/6-bit bytes (plus possibly the un-used combo fixed bytes). If a unit code is entered, KM and RM will need to know how to spread it across the variable and fixed byte.
There are logically 3 versions of the protocol floating around...
a) the old 8/8 version, where the unit code is spread between the fixed and variable data
b) the first 5/5/6 version
c) the current 5/5/6 version that supports the mini-combo logic.
There's actually 2 versions of (b), one that also supports the alternative carrier frequency and one that doesn't. All versions of (c) support the 2 carriers. The alternative carrier frequency matches the one used by the Dishplayer protocol, but the burst times do not match, and I cannot find an example of a setup code that uses $0002 with the alt carrier frequency, so I propose that we do not support that feature at this time.
If the protocol is to be presented as an upgrade, I don't see any point in including the (possibly redundant) logic for the alt carrier, so here's the 40 byte protocol code with that logic removed...
Upgrade protocol 0 = 00 02 (S3C8+)
2B 5C 51 8B 16 B6 59 05 06 00 C5 03 32 00 C5 05
73 0B F2 00 C5 0B F2 05 02 43 8C 18 08 56 C1 03
87 21 04 29 04 8D 01 46
End
The remotes that have the old 8/8 version installed are:
S3C8: 15-1994, Catalyst48, Millenium3, Millenium4, ReplayTV v1, ReplayTV v2, URC-7800, Outlaw, URC-5650, URC-7200,
740: 15-1935, 15-1995, URC-9800, URC-8090-B00, URC-8090-B02, Maestro II,
6805: Kenwood-R0805, Intuitive, URC-44XXXB00, URC-44XXXB02,
The remotes with the non-combo, 1 carrier, 5/5/6 version are (all S3C8):
15-2104, 15-2103, 15-2107, Toshiba-90047, RCU810, REM400-B00, URC-4080
The remotes with the non-combo, 2 carrier, 5/5/6 version are:
Balboa, REM400-B01, URC-8811,
The remotes with the combo, 2 carrier, 5/5/6 version are (all S3C8):
15-2116, 15-2133, 15-2138, URC-3440, URC-6131, URC-8040, URC-8060, URC-8910, URC-9960
I will try and see if there is an official version of the current protocol for either the 740 or 6805 remotes, but even if there isn't, it shouldn't be too hard to modify the old versions. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Last edited by The Robman on Fri Apr 02, 2004 7:55 pm; edited 1 time in total |
|
Back to top |
|
|
gjarboni Expert
Joined: 20 Sep 2003 Posts: 294 Location: Columbia, MD |
Posted: Thu Apr 01, 2004 2:58 pm Post subject: |
|
|
Re: an official 740 5/5/6 protocol -- Uwe already found it (downloaded it from OFA Europe). Here's what he posted (it was on the Yahoo group a while ago):
Upgrade protocol 0 = 00 02 (P8/740)
06 0D 51 80 10 B8 70 17 05 06 03 18 04 97 06 9C
17 08 F0 01 05 E6 5C 44 5D 07 5D 13 A9 0C 85 67
A9 19 85 68 22 28 3C 0F 6A 3C 0F 73 3C 02 77 A5
62 29 03 AA B5 5E 85 5E 20 00 FF 3C 62 7F 4C 00
FF
End |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
Posted: Thu Apr 01, 2004 4:07 pm Post subject: |
|
|
Thanks Jason, that appears to support the 2 carriers and the mini-combo logic. My guess is that we could delete the code from 014B to 015E if we decide not to support the 2 carriers, which would leave...
Upgrade protocol 0 = 00 02 (P8/740)
06 0D 51 80 10 B8 70 17 05 06 03 18 04 97 06 9C
17 08 F0 01 05 E6 5C 44 5D A5 62 29 03 AA B5 5E
85 5E 20 00 FF 3C 62 7F 4C 00 FF
End _________________ 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 |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
Posted: Thu Apr 01, 2004 11:25 pm Post subject: |
|
|
I've decided to go ahead and add logic to KM to treat the polarity of the device codes and command codes seperately, so we can treat the device codes as LSB and the command codes as MSB for this protocol.
As nobody (ie, John) raised any objections, let's go ahead and rename the protocol and change DecodeIR/RM to treat BOTH device codes as LSB, not just the "unit code" _________________ 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 |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Fri Apr 02, 2004 7:00 am Post subject: |
|
|
Sorry that I got busy and forgot to research/respond to the question of reversing the OBC. At first glance I didn't like it, but I wanted to investigate before complaining. IIUC you no longer want to. That makes it easier.
Reversing the bits in the device and changing the name in DecodeIR and its readme and RM are all easy. I should be able to do that later today. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
Posted: Fri Apr 02, 2004 8:35 am Post subject: |
|
|
Thanks John _________________ 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 |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Fri Apr 02, 2004 11:36 am Post subject: |
|
|
While we are at it should we have the sub-device come up as "system address" and enter 1 through 16 (rather than Unit 0 through 15).
For the non-combo version, do we want to force "OBC only" for the 8/8 remotes, so you can adjust EFC's for system addresses that need the bottom two bits as something other than 00? _________________ -Jon |
|
Back to top |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Sun Apr 04, 2004 1:05 am Post subject: |
|
|
Here's a version that should work for most of the 6805-RC16/18 remotes. (Known exception would be the SciAtl ER1.) This is an "unofficial" version I wrote based on the S3C80 version Rob posted earlier.
Upgrade Protocol 0 = 00 02 (M6805-RC16/18)
0B 18 51 20 12 B6 59 05 06 01 62 A4 02 62 C4 06
03 00 06 62 04 05 02 B6 5F A4 03 97 E6 5B B7 5B
CC 01 AF
End
Edit: I've highlighted in red the value that sets the number of repeats (which by default, is set to 02) in case you want to use a larger value. _________________ Mike England
Last edited by mr_d_p_gumby on Sat Apr 10, 2004 2:03 pm; edited 1 time in total |
|
Back to top |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Sun Apr 04, 2004 1:16 am Post subject: Re: Dishplayer (Old) protocol |
|
|
The Robman wrote: | ...so here's the 40 byte protocol code with that logic removed...
Upgrade protocol 0 = 00 02 (S3C8+)
2B 5C 51 8B 16 B6 59 05 06 00 C5 03 32 00 C5 05
73 0B F2 00 C5 0B F2 05 02 43 8C 18 08 56 C1 03
87 21 04 29 04 8D 01 46
End | You could shorten it to 38 bytes as follows
Upgrade protocol 0 = 00 02 (S3C8+)
2B 5C 51 8B 14 B6 59 05 06 00 C5 03 32 00 C5 05
73 0B F2 00 C5 0B F2 05 02 18 08 56 C1 03 87 21
04 29 04 8D 01 46
End
Just trying to be helpful _________________ Mike England |
|
Back to top |
|
|
aperry
Joined: 03 Apr 2004 Posts: 11
|
Posted: Mon Apr 05, 2004 11:43 pm Post subject: |
|
|
Just out of curiosity, where did the "Dishplayer (old)" name come from?
The codes for the non-PVR functions are basically the same going all the way back to the earliest Dish Network receivers, but the PVR function was added after the Dishplayer (which is I believe code 1005) came out. The Dishplayer was co-developed with Microsoft and was based on the WebTV interface. The IR for these was totally different than the other Dish equipment.
After that, Dish released PVR's using their standard IR codes.
One other thing, since I've got everyone's attention... What Dish receivers does 1170 support? |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
Posted: Tue Apr 06, 2004 7:27 am Post subject: |
|
|
aperry wrote: | Just out of curiosity, where did the "Dishplayer (old)" name come from? |
At the time, which was late 2000 I guess, we had the Dishplayer (which seemed to be all the rage then) and the older Dish SAT receivers. Both were made by the same company, so one got called Dishplay and the other got called Dishplayer (Old). This was before they came out with any of their Dish PVRs. _________________ 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 |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
Posted: Thu Apr 08, 2004 4:09 pm Post subject: |
|
|
Thanks John _________________ 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 |
|
|
|
|
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
|