KM Broken for Dishplayer protocol using OBC's

jon_armstrong · Post by **jon_armstrong** » Sun Aug 01, 2004 5:57 am

In this thread it became obvious that KM was using the bottom 6 bits of the OBC rather than the top 6-bits. It's MSB first and a 6-bit OBC. I suspect it's been that way a long time since I think Dishplayer is rarely used.

Mark Pierson · Post by **Mark Pierson** » Sun Aug 01, 2004 6:19 am

I'm confused, Jon.

Based on your reply here, is the latest KM (v8.25) handling it properly or is it still broken?

jon_armstrong · Post by **jon_armstrong** » Sun Aug 01, 2004 6:41 am

What is still broken is Dishplayer aka $010F.

I edited that answer in your link since I was using 8.24. I came here to report that problem too, saw the 8.25 announcement and tested it and $0002 Dishplayer_network seems fixed.

Just when you thought you had it competely under control ...

Post by **The Robman** » Sun Aug 01, 2004 10:00 am

I don't it's all as straightforward as that. I just opened up KM 8.25 and selected Dishplayer (with the 15-1994 selected as the remote) and the supplied protocol upgrade uses 5 bit commands (not 6 bit), so guessing that the code may have changed, I grabbed a newer copy (15-2138) and it now appears to use 8 bit commands (with a 5-bit device code), so we may need to do a massive version control to see which version is in which remote.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Sun Aug 01, 2004 11:18 am

I took a quick look, and there seem to be two different versions of this protocol. The older one has the flags set for 8 device bits & 5 command bits, while the newer one is 5 device bits & 8 command bits.

The older one is in: Balboa Dolphin, REM400-B01, RCU810, 15-2103, 15-2104, 15-2107, Toshiba CT90047, URC-4080 and URC-601x/801x/881x.
The newer one is in: 15-2116/7, 15-2133, 15-2138, URC-6131, URC-8910/9910 and URC-9960.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Sun Aug 01, 2004 11:54 am

Update: Upon closer inspection, the older version appears to be swapping the device & command bytes before transmitting them in dev-cmd order, so that explains why the bit lengths are opposite. I'd conclude that both versions will work with the same upgrade, using 8 command bits and 5 device bits.

jon_armstrong · Post by **jon_armstrong** » Sun Aug 01, 2004 12:29 pm

Just to be clear, the Dishplayer protocol does have 13 data bits and this is the protocol and the way John's decoder will decode it:

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

I know the first 6-bits are OBC, IIRC, John, Rob and I arbitrarily decided that the unit code would be 5 bits like the much more common Dishplayer_network protocol. I don't think we have ever seen anyting but 0 for U.

So we still need to pick off the top 6 bits to map to OBC.

I just edited out the part about U being considered lsb first. Decode IR does not decode it that way.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Sun Aug 01, 2004 12:43 pm

jon_armstrong wrote:So we still need to pick off the top 6 bits to map to OBC.

UEI also seems to have concluded that the unit code is 5 bits, since the protocol only uses the upper 5 bits of the fixed data.

If truly the OBC is only 6 bits, that still leaves 2 bits undefined, as the protocol transmits all 8 bits of the command byte. If I understand you correctly, then Mark will have to make KM put the OBC in the upper 6 bits, and mask the lower two bits to zero. Correct?

jon_armstrong · Post by **jon_armstrong** » Sun Aug 01, 2004 1:14 pm

Mike,

I think the 8-bits of variable data are 6-bits OBC and 2-bits of Unit. The fixed data maps to 3-bits of unit and 2 bits of device and 3-bits ignored.

I just tested that on the older version to confirm and perhaps someone else can do the newer version.

I also found that the Protocols.ini was off by one bit in RM here is the correction:

[Dishplayer]
PID=01 0F
DevParms=Device Code:2=3,Unit:5=0
DeviceTranslator=Translator(0,2,3) Translator(1,3)
FixedData=00
CmdTranslator=Translator(0,6) TranslatorFromDev(1,2,6,3)
CmdParms=OBC:6=0
Notes=The Device.Unit:OBC should match the decodes from DecodeIR.DLL, which does \
not match the Device and OBC used in KM. Use EFCs (not OBCs) to copy any \
functions between KM and RM. The Device value corresponds between KM and \
RM only for Device 0 to 3, Unit 0.
Code.S3C80=43 8B 11 8B 12 85 49 08 05 01 0B 02 F6 01 0B 05 1C 0B 93 01 0B 0B A6 18 04 E4 03 04 19 03 8D 01 46
Code.740=0c 18 11 80 0c e0 e2 00 15 08 05 02 ee 04 5b 06 4f a9 15 20 db 00 a2 d7 a0 06 22 44 a5 5d 85 54 a5 5e 85

5d a5 54 85 5e 4c 00 ff
Code.6805-C9=0C 19 11 20 0E E0 70 15 08 05 02 ED 04 59 06 9B 15 08 BC B6 5A B7 51 B6 5B B7 5A B6 51 B7 5B CD

01 83 12 7C 19 7C CC 01 83

jon_armstrong · Post by **jon_armstrong** » Sun Aug 01, 2004 1:37 pm

Come to think of it we need to fix KM for the fixed data too:

Where the bits are:

76543210

Variable Data bits 765432 map to OBC 543210 and Variable Data bits 10 map to Unit 43

Fixed data bits 765 map to Unit 210 and Fixed data bits 43 map to Device 10

Fixed data bits 210 are ignored.

gfb107 · Post by **gfb107** » Tue Aug 03, 2004 9:29 am

The protocols.ini changes will be included in RM v1.02