|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Wed Jul 04, 2012 8:14 am Post subject: |
|
|
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. _________________ Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Wed Jul 04, 2012 8:30 am Post subject: |
|
|
Neither of those XOR groups give the desired result Code: | 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 |
_________________ 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: 21238 Location: Chicago, IL |
Posted: Wed Jul 04, 2012 8:51 am Post subject: |
|
|
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: | 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 |
_________________ 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 |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Wed Jul 04, 2012 8:59 am Post subject: |
|
|
The Robman wrote: | I just used the Pronto export function to get the binary signals for the Humax Code: | 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. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Wed Jul 04, 2012 9:17 am Post subject: |
|
|
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.php?action=file&file_id=11054 _________________ 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: 21238 Location: Chicago, IL |
Posted: Wed Jul 04, 2012 9:32 am Post subject: |
|
|
vickyg2003 wrote: | The Robman wrote: | 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. _________________ 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 |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Wed Jul 04, 2012 9:35 am Post subject: |
|
|
The Robman wrote: | 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.php?action=file&file_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. _________________ Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Wed Jul 04, 2012 10:20 am Post subject: |
|
|
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. |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Wed Jul 04, 2012 11:31 am Post subject: |
|
|
3FG wrote: | 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.
Quote: | 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... _________________ Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Wed Jul 04, 2012 1:00 pm Post subject: |
|
|
vickyg2003 wrote: | 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. _________________ 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: 21238 Location: Chicago, IL |
Posted: Wed Jul 04, 2012 1:27 pm Post subject: |
|
|
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: | [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 |
_________________ 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: 21238 Location: Chicago, IL |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Wed Jul 04, 2012 1:52 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Wed Jul 04, 2012 1:55 pm Post subject: |
|
|
Right, but the version in most remotes, including the Slingbox, should work. _________________ 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 |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Thu Jul 05, 2012 7:02 am Post subject: |
|
|
Gee, while I was gone to one event, you guys went and had all the fun!
3FG wrote: | 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. _________________ Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
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
|