Protocol for the Cosmic D268

alanrichey · Post by **alanrichey** » Fri Dec 14, 2012 5:14 am

Running this through IRScope the protocol is decoding as:

??Kaseikyo-84.87

Does this map to a standard protocol in RM ? or do we need to do a full learn and build a new protocol ?

I've done a sample of 4 buttons at http://www.hifi-remote.com/forums/dload ... e_id=11582

Post by **The Robman** » Fri Dec 14, 2012 7:51 am

In the end you will need to learn all the buttons anyway, so could you make an ICT file that includes all of them now? The thing is, it's the same amount of work for us to decode 4 buttons as it is to decode 24, but to do 4 now and 20 later is twice the work.

Post by **The Robman** » Fri Dec 14, 2012 11:42 am

I decided to take a look anyway and this was was tough because 2 of the buttons wouldn't export and none of them would import into IR.exe, so I had to decode them all by hand.

Anyway, these look like standard Kaseikyo signals, except for the fact that the checksums aren't in the right place. I haven't tried to figure out the checksums yet, but that shouldn't be needed to get these into the $00F8 executor, but we would need a new protocols.ini entry that doesn't do any checksum calculations for you and instead lets you supply the 2 variable bytes of data.

Here's what I got from the 4 learns presented...

Code: Select all

M        N        X   D    S        F        E   C
00101010 11101010 11001010 00011010 00001010 11101010 = power
00101010 11101010 11001010 00011010 00001100 00001100 = num 0
00101010 11101010 11001010 00011010 10101010 00001010 = ch+
00101010 11101010 11001010 00011010 01001010 10100010 = red

Post by **vickyg2003** » Fri Dec 14, 2012 12:22 pm

Is this post related to the last time we did the Kaseiko with a seed?
http://www.hifi-remote.com/forums/viewt ... 056#104056

3FG · Post by **3FG** » Fri Dec 14, 2012 1:12 pm

Here's the IRP for ??Kaseikyo: {37k,432}<1,-1,1,-3>(8,-4,M:8,N:8,X:4,D:4,S:8,G:8,F:8,1,-173)+

IRScope displays M, N, D, S, F, and G, so it already gives us a complete decode (X is always determined by XORs of the nibbles of M and N). I agree with Rob that this protocol will require a different entry in protocols.ini, but no decoding is necessary.

I think we should change the existing Kaseikyo entry in protocols.ini so that it doesn't attempt to calculate the check sum, since it varies among implementations of Kaseikyo. We do need to verify the operation of the variants of the F8, 1F, C9, and CD executors, so that RM can select a suitable executor (if available) depending on the individual remote.

alanrichey · Post by **alanrichey** » Fri Dec 14, 2012 1:58 pm

Actually the OBC codes were giving discrete, logical values. That was why I thought we might get away with just 4 to figure out the protocol and I could then use the OBCs.

Right or wrong ?

3FG · Post by **3FG** » Fri Dec 14, 2012 2:12 pm

I don't understand. How do you get the OBCs? From capturing, right?

Anyway, both the OBC values and the "G" value that IRScope returns in the Misc field will be needed to make an upgrade. Also, we need an revised entry in protocols.ini. I should be able to do that tonight.

Post by **The Robman** » Fri Dec 14, 2012 3:22 pm

alanrichey wrote:Actually the OBC codes were giving discrete, logical values. That was why I thought we might get away with just 4 to figure out the protocol and I could then use the OBCs.

Right or wrong ?

Until we do the decode, you can't know that for sure. And my point is, you're going to have to learn all of the buttons at some point in order to get the rest of the OBCs, so it's better to learn them all in advance so we can decode the complete set at once. The reason being, we have to do a lot of global edits to get the data, so it's easier to do it once.

alanrichey · Post by **alanrichey** » Fri Dec 14, 2012 3:23 pm

The 'G' value varies with each button. So I assume that you still need a full ICT file ?

alanrichey · Post by **alanrichey** » Fri Dec 14, 2012 3:34 pm

OK, I'll get on it.

3FG · Post by **3FG** » Sat Dec 15, 2012 1:16 am

Here's the protocols.ini entry that will generate these signals. Your captures seem to show a lead out time of 50mS. The 00F8:3 executor can send 4 different lead outs, and it looks like you have a choice of 44 or 70mS. I suspect either one will be fine.

Code: Select all

[Kaseikyo-G]
PID=00 F8
DevParms=OEM1=84,OEM2=87,Device:4=5,Sub Device=88,Leadout(mS):20|33|70|44=3
DeviceTranslator=Translator(4,8,0)  \
                 Translator(lsb,comp,0,8,8)   \
                 Translator(lsb,comp,1,8,16)  \
		                  XorCheck(4,24,15,4) \
                 Translator(lsb,comp,2,4,28)  \
                 Translator(lsb,comp,3,8,32)                      
FixedData=03 D5 15 35 E5
CmdParms=OBC=0, G=0
DefaultCmd=00 00
CmdTranslator=Translator(lsb,comp,1,8,0) Translator(lsb,comp,0,8,8)
Notes=Use this for a decode of ??Kaseikyo-wx.yz.  For example, for a decode of ??Kaseikyo-84.87, device 5.88, OBC=31, G=71, enter 84 as OEM1, 87 as OEM2, \
5 as Device, 88 as SubDevice, 31 as OBC, and 71 as G    
Code.S3C80=45 91 52 8B 18 8F 45 08 08 00 DA 00 C6 00 DA 02 7D 27 70 06 D1 03 40 40 F8 92 68 55 26 20 01 08 03 37 03 0B 37 00 13 56 28 F7 C4 22 1C 8B 0B 37 00 05 C4 26 1C 8B 03 C4 24 1C 8D 01 46
Code.6805-RC16/18=11 24 52 20 18 8F 45 08 08 00 63 69 01 63 3A 13 C2 00 31 25 A8 49 3E 20 86 13 28 2A 9D 3C 58 03 5A 0B 00 5A 22 B6_79 B7_64 B6_7A B7_65 01 5A 0A B6_77 B7_6F B6_78 B7_70 17_7B 03 5A 12 B6_75 B7_6F B6_76 B7_70 20 08 A6 2A B7_6F A6 80 B7_70 CC 01 B2
Code.HCS08=20 1B 23 4A 52 8F 45 08 08 00 D5 00 DE 00 D5 02 95 27 84 06 D0 03 54 41 0C 92 7C 55 3A 3C AC B6 60 A4 03 27 0F A1 01 26 02 17 A2 4A 48 8C 97 9E CE 7A 35 74 CC FF 5C
Code.MAXQ610=34 6D 52 14 10 00 10 00 10 00 30 00 E9 02 81 00 3F 00 CA 04 C9 0A 46 06 02 03 03 01 0B 42 54 06 71 72 73 74 75 76 01 0A 42 56 05 71 72 73 74 75 81 10 04 52 38 40 02 42 54 06 71 72 73 74 75 76 80 04 52 38 42 02 42 54 06 71 72 73 74 75 76

alanrichey · Post by **alanrichey** » Sat Dec 15, 2012 3:39 am

Thanks, I've added it to my Protocols.ini. But now I am even more confused

This looks as though I can now build the BIN files myself without having to post a full ICT file ?

And having put it in to the Protocols.ini I see that were already 3 entries for [Kaseikyo] although only one option shows up in RM.

Why the duplication ? Have I done it or does the standard Protocol.ini have 3 in as well. If so, why ?

Al

3FG · Post by **3FG** » Sat Dec 15, 2012 3:24 pm

Al,
You haven't made a mistake.

Blame history for the confusion, both from the JP1 community and from UEI. UEI has built numerous variants of the 00F8 executor, and we have chosen to categorize these as variant 1, 2 or 3. All of the variants use the same 5 byte fixed data organization, and most of them can select among 4 leadout times, but a subset of variant 1 can only send 20mS or 72mS, and some variant 2 remotes can only send 20, 43 or 75mS. The good news for most of us is that any remote made in the last 7 or 8 years is variant 3, and these all act the same way.

Protocols.ini thus needs three different entries for 00F8; one entry per variant. RMIR will only display one instance of these executors, and selects the entry based on the variant specified for the target remote in its RDF file.

Next piece of history: In the beginning, there was Panasonic. Over time, it was realized that Panasonic is just one example of the Kaseikyo class of protocols: Fujitsu, SharpDVD, Denon-K, Mitsubishi-K, Teak-K, and JVC-48. However, we tried to describe a generic Kaseikyo protocol before all of these protocols were known, and also tried to describe it with just 8 bits of variable data, while actually valid Kaseikyo allows 16 bits of variable data.
So the Kaseikyo entry in protocols.ini is only suitable to describe a subset of Kaseikyo class protocols. Similarly, DecodeIR shows Kaseikyo if the protocol fits a narrow definition or ??Kaseikyo if it fits the more general structure.

The Kaseikyo-G entry posted above has two bytes of variable data, so it is usable with ??Kaseikyo. In fact, it could be used to make an upgrade for any of the Kaseikyo class protocols, if one wants to go to the trouble of re-arranging the device, subdevice, etc numbers.

For this particular case, we don't need the full ICT file, because ??Kaseikyo is a robust decode, in spite of the name.

alanrichey · Post by **alanrichey** » Sat Dec 15, 2012 3:48 pm

Amazing stuff. incredible you actually figured it out

alanrichey · Post by **alanrichey** » Mon Dec 17, 2012 5:20 am

Good news with a slight caveat

The user reports it works well so the protocol is fine and the codes are all correct. Unfortunately he is getting the 'double-skipping' with the Channel and Number buttons. Can you tell me which byte(s) need changing in the S3C80 setting to set the repeat to zero ? I can then add a [Kaseikyo-G (no repeat)] prototcol to my special collection in the Slingbox file area.

Code.S3C80=45 91 52 8B 18 8F 45 08 08 00 DA 00 C6 00 DA 02 7D 27 70 06 D1 03 40 40 F8 92 68 55 26 20 01 08 03 37 03 0B 37 00 13 56 28 F7 C4 22 1C 8B 0B 37 00 05 C4 26 1C 8B 03 C4 24 1C 8D 01 46

Cheers

Al