JP1 Remotes

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.

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

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

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"

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.

Thanks John

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?

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.

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

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?

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.

johnsfine wrote: 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.

Less than a week late and I finally did it.

http://www.hifi-remote.com/files/tools/ ... IR_DLL.zip

http://www.hifi-remote.com/files/source ... eIRcpp.zip

Thanks John