Using the Kaseikyo protocol

[vickyg2003]

Your right. I miscalculated the third byte of fixed data.
That's what I get for taking a short cut. I picked 10 up as the device, and stuck it in as that byte without ever decoding that portion by hand, and without thoroughly understanding the Kaisekyo protocol as to where the device would be in the code. X:4,D:4, I just assumed the whole byte would be the device of 10 and I was getting a bit lost when I reached the middle of the signal from either end. I made the same mistake on NoirFire's Skyperfect when I plugged in 8 for the device and it should have been 128. At that time I just chalked it up to a typo, where I should have looked deeper into the decode and I would have seen that I made the same error there.

Sky perfect
01000101 162
01010100 42
00000001 128
11101000 23

desired xor with function
11101001


1000 0000 0101 0101 1000 0101 0100 1000 1100 0000 1101 1000 IRscope from Alan


Humax - Alan
10000000 1
01010101 170
10001010 X4:1, d4:10
01001000 18

desired xor with function to get final bit
00011000


But I don't see how xoring bytes 1 to 4 would get you the '00011000' to xor with bit 5 to get the xsum we are looking for.

[The Robman]

Neither of those XOR groups give the desired result

Code: Select all

01000101	162
01010100	42
00000001	128
11101000	23
--------
11111000	actual XOR
	
10000000	1
01010101	170
10001010	X4:1, d4:10
01001000	18
--------
00010111	actual XOR

[The Robman]

I just used the Pronto export function to get the binary signals for the Humax, and if you XOR the 1st 4 bytes you do get the desired 00011000 pattern.

Code: Select all

10000000 01010101 10000101 01001000 11000000 11011000 num 1
10000000 01010101 10000101 01001000 00100000 00111000 num 2
10000000 01010101 10000101 01001000 10100000 10111000 num 3
10000000 01010101 10000101 01001000 01100000 01111000 num 4
10000000 01010101 10000101 01001000 11100000 11111000 num 5
10000000 01010101 10000101 01001000 00010000 00001000 num 6
10000000 01010101 10000101 01001000 10010000 10001000 num 7
10000000 01010101 10000101 01001000 01010000 01001000 num 8
10000000 01010101 10000101 01001000 11010000 11001000 num 9
10000000 01010101 10000101 01001000 00110000 00101000 num 0

[vickyg2003]

I just used the Pronto export function to get the binary signals for the Humax

Code: Select all

10000000 01010101 10000101 01001000 11000000 11011000 num 1
10000000 01010101 10000101 01001000 00100000 00111000 num 2
10000000 01010101 10000101 01001000 10100000 10111000 num 3
10000000 01010101 10000101 01001000 01100000 01111000 num 4
10000000 01010101 10000101 01001000 11100000 11111000 num 5
10000000 01010101 10000101 01001000 00010000 00001000 num 6
10000000 01010101 10000101 01001000 10010000 10001000 num 7
10000000 01010101 10000101 01001000 01010000 01001000 num 8
10000000 01010101 10000101 01001000 11010000 11001000 num 9
10000000 01010101 10000101 01001000 00110000 00101000 num 0

I didn't try that. Wouldn't know what to do with the Pronto hex even after that. I can decode by hand, and should have gone all the way to the middle, but was getting lost each time I transcribed it from either direction by the time I got to the middle byte. Just too much for me. I've got about a 16bit attention span.

[The Robman]

so, bottom line, the xsum pattern for the Skyperfect is an XOR of bytes 3 and 4, whereas for the Humax it's an XOR of all 4 fixed bytes. Therefore I agree with Dave that the custom executor should use a seeding byte rather than calculate the pattern.

The seeding byte for Skyperfect should be 11101001 and for Humax it should be 00011000, then XOR this byte with the OBC byte to generate the checksum. Also, don't accidentally include the seeding byte in the signal. My recommendation would be to make the seeding byte the 5th fixed byte, then in the code do this...

1) save the 5th byte (the seed) in a scratch register
2) load the 6th byte (obc) into the 5th byte
3) XOR the saved seed with the 6th byte (obc) to generate the xsum

here's a spreadsheet with both sets in it
http://www.hifi-remote.com/forums/dload ... e_id=11054

[The Robman]

I just used the Pronto export function to get the binary signals for the Humax

I didn't try that. Wouldn't know what to do with the Pronto hex even after that.

I went with the Pronto option because it made the rounding easier. Here's how you would handle the Pronto hex.

1) replace 000E, 000F, 0011, 0012 and 0013 with 0010.
2) replace 0031, 0032 and 0033 with 0030.
3) replace "0010 0030 " with 1^
4) replace "0010 0010 " with 0^
5) replace "^00" with " 00" (for the leadout pairs)
6) replace "^" with ""

Now you should clearly see the binary in the middle of the rest of the pronto hex. Now paste this into Excel as text and use the text to columns feature to eliminate the rest of the junk and break out the binary into bytes.

[vickyg2003]

so, bottom line, the xsum pattern for the Skyperfect is an XOR of bytes 3 and 4, whereas for the Humax it's an XOR of all 4 fixed bytes. Therefore I agree with Dave that the custom executor should use a seeding byte rather than calculate the pattern.

The seeding byte for Skyperfect should be 11101001 and for Humax it should be 00011000, then XOR this byte with the OBC byte to generate the checksum. Also, don't accidentally include the seeding byte in the signal. My recommendation would be to make the seeding byte the 5th fixed byte, then in the code do this...

1) save the 5th byte (the seed) in a scratch register
2) load the 6th byte (obc) into the 5th byte
3) XOR the saved seed with the 6th byte (obc) to generate the xsum

here's a spreadsheet with both sets in it
http://www.hifi-remote.com/forums/dload ... e_id=11054

Yes was thinking along those lines, but did remember one of the protocols you wrote that I had followed where you could put the seed in the first byte, and then get the xmit to ignore the first byte of the DCBuf. Don't remember how you did it though.

I am pretty busy today, cooking for the family gathering this afternoon, but I keep hopping down to my JP1 cave where its a frosty 68 degrees as opposed to the steamy conditions upstairs where it was 82 before I turned on the stove. I will have lots of time to get this out tommorrow.

[3FG]

Vicky,
I see that the SkyPerfect upgrade you made for noifire sets up 3 repeats. Maybe that's necessary for a Slingbox, but I suppose that a general upgrade wouldn't need a special number of repeats. So I guess that for most users, a custom executor isn't needed, and the 00C9 Panasonic executor will work with OEM1=162, OEM2 = 42, Dev = 128, and Sub = 23. It would save 36 bytes.

[vickyg2003]

Vicky,
I see that the SkyPerfect upgrade you made for noifire sets up 3 repeats. Maybe that's necessary for a Slingbox, but I suppose that a general upgrade wouldn't need a special number of repeats.

Well I don't know if the 3 repeats are necessary. The Kasiekyo that I started from had them, so I assumed they were necessary.

So I guess that for most users, a custom executor isn't needed, and the 00C9 Panasonic executor will work with OEM1=162, OEM2 = 42, Dev = 128, and Sub = 23. It would save 36 bytes.

In order to know that, I'd have to understand decodeIR, and all the protocols that you experts know. That would take a heavy dose of education. Now keeping in mind how long it took Rob just to get me to use PB to replicate a signal that decodeIR can't identify. Are you willing to tutor me on the ins and outs of known protocols, so that I can save those 36 bytes? Think long and hard before you answer that. Maybe take a look at all the tutoring Rob had to do to get me this far...

[The Robman]

Yes was thinking along those lines, but did remember one of the protocols you wrote that I had followed where you could put the seed in the first byte, and then get the xmit to ignore the first byte of the DCBuf. Don't remember how you did it though.

We have several executors that use a control byte of some sort. UEI typically uses the first fixed byte and then skips it in the code, they do this for Panasonic, NEC, etc. In S3C8 language, you skip the first byte by setting R01 to 0x01. I was suggesting doing it a different way as this would require less code. But, Dave's suggestion of using the C9 Panasonic executor is a good one.

[The Robman]

As Panasonic also uses a XOR of the 3rd and 4th bytes, you should be able to use the Panasonic entry in RM "as is" for the Skyperfect, if you supply OEM1=162 and OEM2=42.

For the Humax, we would need a new protocols.ini entry that does an XOR of all 4 fixed bytes. Here's my guess as to what that entry would look like...

Code: Select all

[Humax]
PID=00 C9
DevParms=Device=161,Sub Device=18,OEM Dev1=1,OEM Dev2=170
DeviceTranslator=Translator(lsb,comp,0,8,24) \
                 Translator(lsb,comp,1,8,32) \
                 Translator(lsb,comp,2,8,8)  \
                 Translator(lsb,comp,3,8,16) \
                 XorCheck(8,0,255,4,8)
FixedData=E7 7F AA 7A B7
CmdParms=OBC=0
CmdTranslator=Translator(lsb,comp)
Notes=Panasonic Executor
Code.S3C80=45 91 51 8B 12 8F 44 08 08 00 DA 00 C6 00 DA 02 7B 90 C9 06 D0 03 54 E6 0C E8 60 03 20 01 E4 08 09 B4 03 09 20 10 F6 01 46 F6 01 0A FB 0D 00 

0C EB F4 C6 3E 00 00 B0 4A F6 01 0A AF
Code.740=0B 1C 51 80 0E E1 72 10 08 08 01 7F 02 A1 5F 02 80 03 39 44 5D E6 5B A5 62 45 5D 85 63 E6 69 4C 00 FF
Code.6805-C9=0B 1D 51 B6 5D B8 5E B8 5F B7 60 A6 80 CD 00 B7 A6 03 AE 27 CD 01 9F AE 06 E6 5A E7 4F 5A 26 F9 A6 30 B7 61 A6 10 CD 00 B7 A6 86 4A 26 FD 

0E 50 07 A6 02 AE 1E CD 01 9F 39 55 39 54 39 53 39 52 39 51 39 50 3A 61 26 DC A6 10 CD 00 B7 A6 60 AE E0 CD 01 9E CC 01 89
Code.6805-RC16/18=11 26 51 20 10 8F 45 08 08 00 6C 6D 01 6C 48 48 6F 00 31 67 B4 33 5A 3C 58 B6 5F B8 5A B7 60 3C_66 CC 01 AF
Code.HCS08=20 15 23 4A 51 8F 45 08 08 00 D4 00 DA 00 D4 02 8F 90 DD 06 CF 03 68 3C AC B6 60 43 B8 65 B7 66 3C A9 CC FF 5F

[The Robman]

Here's an upgrade for the Skyperfect that uses the Panasonic executor:
http://www.hifi-remote.com/forums/dload ... e_id=11057

and here's one for the Humax that uses the new protocols.ini entry (above)
http://www.hifi-remote.com/forums/dload ... e_id=11058

both upgrades are completely un-tested, so any feedback would be appreciated.

[3FG]

Rob,
I guess I wasn't clear enough. The 00C9 executor will work for the SkyPerfect. But the executor, as implemented in the RCRP05B, and I suspect other remotes, won't work for the Humax because it doesn't actually use the seed byte. It seems to be hard coded to take the XOR of the 3rd and 4th byte.

[The Robman]

Right, but the version in most remotes, including the Slingbox, should work.

[vickyg2003]

Gee, while I was gone to one event, you guys went and had all the fun!

Here's an upgrade for the Skyperfect that uses the Panasonic executor:
http://www.hifi-remote.com/forums/dload ... e_id=11057

both upgrades are completely un-tested, so any feedback would be appreciated.

Rob,
I guess I wasn't clear enough. The 00C9 executor will work for the SkyPerfect. But the executor, as implemented in the RCRP05B, and I suspect other remotes, won't work for the Humax because it doesn't actually use the seed byte. It seems to be hard coded to take the XOR of the 3rd and 4th byte.

I have uploaded the skyperfect upgrade into the JP1.2 and JP1.3 Comcast remotes and both remotes shoot a signal with the bumps in all the right places, and same IRScope Decode as Noirfire's files. I pictures don't line up t 100% . The overall length of the signal is about 800 time units shorter than the upgrade that I wrote.

I'm not sure which remotes I should check this in to see if there is a failure. Do I need to check remotes where this is going to be an upgrade? What?

I'd be happy to test, as I have the day totally free, and its pouring outside, so can't do the yard work that needs to be done.