|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
Posted: Mon Nov 08, 2004 9:56 pm Post subject: |
|
|
Jon Armstrong is usually the expert that helps out with keyboards, but he's out of town at the moment. So, if nobody else responds before then, bump this thread in a week or two. _________________ 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 |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Fri Nov 12, 2004 3:45 pm Post subject: |
|
|
Your keyboard uses a fairly different IR Protocol from the other Chicony KB. Try this device/protocol upgrade. _________________ -Jon |
|
Back to top |
|
|
digitalcujo
Joined: 04 Nov 2004 Posts: 6
|
Posted: Mon Nov 15, 2004 2:30 am Post subject: |
|
|
wow, thanks for creating this upgrade code!
It seems like some sort of "stop" sequence in the upgrade protocol is missing. Here is what I found:
I loaded the upgrade code into the remote, and when I press any key, the computer behaves as if I was holding the key down continuously. For example, after pressing the #2 key, a stream of "2"s continue on the screen. Even if I cover the IR transmitter part of the remote, the stream continues. If I press another key, like the number '4', the stream of numbers on the screen changes from "2"s to a never ending "4"s. If I change the remote to use my learned key #2, the stream of numbers then stop. This happens on all keys 0-9. Its worth mentioning that none of the learned keys exhibit this behavior.
Any ideas?
thanks.
-rusty |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Mon Nov 15, 2004 8:17 am Post subject: |
|
|
I assume Jon noticed that your keyboard signals had a press portion and a release portion, and decided to create a protocol for just the press portion.
Most keyboards have the press and release signals, but work acceptably with a remote that sends on the press portion. Your keyboard must be an exception to that pattern, and requires the release portion to work right.
Making the UEI remote generate the release part of the signal immediately (so all presses act like short presses) is moderate extra work. Making it generate the release part correctly at release of the key, is even harder.
I hope Jon knows how to do those things. I probably don't have time to help this one much. |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Mon Nov 15, 2004 1:24 pm Post subject: |
|
|
johnsfine wrote: | I assume Jon noticed that your keyboard signals had a press portion and a release portion, and decided to create a protocol for just the press portion.
Most keyboards have the press and release signals, but work acceptably with a remote that sends on the press portion. Your keyboard must be an exception to that pattern, and requires the release portion to work right. |
Yes, there are two frames with a lead-in, 11 bits, and a lead out (bits 10 -->0). The bit 10 is always 1, then seven bits 3 through 9 that vary, and bits 2,1,0 are 010 in the first frame and 000 in the second. Bit 1 is the release flag. The gap between frames in the learned commands are from 18 to 130 mS.
Quote: | Making the UEI remote generate the release part of the signal immediately (so all presses act like short presses) is moderate extra work. Making it generate the release part correctly at release of the key, is even harder.
I hope Jon knows how to do those things. I probably don't have time to help this one much. |
I know conceptually how to do it but don't have any practical experience. I assume we want to XOR the one bit release flag in where ever the fixed data is stored and run the sequence again. Here is the disassembly in PB of the first half:
Code: | Addr Code Label Op Op Args Comments
REMOTE S3C8+
FF00 43 89 DB 43H,89H ;38.5 kHz 33%
FF02 11 DB 11H ;1 dev, 1 cmd
FF03 8B 12 JR LFF17
FF05 B5 DB B5H ;pf0: 10110101=1-dev,1-cmd,cmd-dev
FF06 24 DB 24H ;pf1: 00100100=LI-same,LI-LO
FF07 03 DB 03H ;pd00: DevBits1=3
FF08 08 DB 08H ;pd01: CmdBits1=8
FF09 00 67 DW 0067H ;pd02/03: 1-burst on=206 uS
FF0B 01 3F DW 013FH ;pd04/05: 1-burst off=678 uS
FF0D 00 67 DW 0067H ;pd06/07: 0-burst on=206 uS
FF0F 00 7A DW 007AH ;pd08/09: 0-burst off=284 uS
FF11 91 A3 DW 91A3H ;pd0A/0B: Leadout off=74566 uS
FF13 01 90 DW 0190H ;pd0C/0D: Leadin on=800 uS
FF15 02 12 DW 0212H ;pd0E/0F: Leadin off=1100 uS
FF17 8D 01 46 LFF17: JP 0146H |
Any help would be appreciated. _________________ -Jon |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
Posted: Mon Nov 15, 2004 2:10 pm Post subject: |
|
|
Based on your comments, all you should need to do is:
a) convert the JP to $0146 into a CALL
b) XOR the variable byte (ie, register R04) with binary 00000010 (or hex "02")
c) JP to $0146
Here's the raw hex for the new protocol:
43 89 11 8B 12 B5 24 03 08 00 67 01 3F 00 67 00
7A 91 A3 01 90 02 12 F6 01 46 B6 04 02 8D 01 46
And here's a disassembly:
Code: | Addr Code Label Op Op Args Comments
FF00 43 89 DB 43H,89H ;38.5 kHz 33%
FF02 11 DB 11H ;1 dev, 1 cmd
FF03 8B 12 JR LFF17 ; jump over data block
FF05 B5 DB B5H ;pf0: 10110101=1-dev,1-cmd,cmd-dev
FF06 24 DB 24H ;pf1: 00100100=LI-same,LI-LO
FF07 03 DB 03H ;pd00: DevBits1=3
FF08 08 DB 08H ;pd01: CmdBits1=8
FF09 00 67 DW 0067H ;pd02/03: 1-burst on=206 uS
FF0B 01 3F DW 013FH ;pd04/05: 1-burst off=678 uS
FF0D 00 67 DW 0067H ;pd06/07: 0-burst on=206 uS
FF0F 00 7A DW 007AH ;pd08/09: 0-burst off=284 uS
FF11 91 A3 DW 91A3H ;pd0A/0B: Leadout off=74566 uS
FF13 01 90 DW 0190H ;pd0C/0D: Leadin on=800 uS
FF15 02 12 DW 0212H ;pd0E/0F: Leadin off=1100 uS
FF17 F6 01 46 LFF17: CALL 0146H ; send main signal
FF1A B6 04 02 LFF1A: XOR R04, #02H ; XOR toggle bit
FF1D 8D 01 46 LFF1D: JP 0146H ; send final part of signal |
_________________ 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 |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Mon Nov 15, 2004 5:49 pm Post subject: |
|
|
Thanks Rob. A couple of tweaks. I think you XOR 0x40 (01000000 it only uses the top thee bits) and I guessed register 03 since it was the FIXED byte that needed XOR-ing. My limited testing says this works:
Upgrade protocol 0 = 01 F0 (S3C8+) PB v3.10
43 89 11 8B 12 B5 24 03 08 00 67 01 3F 00 67 00
7A 91 A3 01 90 02 12 F6 01 46 B6 03 40 8D 01 46
End
Anyway Rob, how do you know which registers the fixed a variable data are in? What hapens when you have multiple bytes of fixed and or variable data? Does the order matter? dev-cmd or cmd-dev.
Rusty, I updated the device upgrade and it looks like should work now. Same link. _________________ -Jon |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Mon Nov 15, 2004 5:58 pm Post subject: |
|
|
jon_armstrong wrote: |
Anyway Rob, how do you know which registers the fixed a variable data are in? What hapens when you have multiple bytes of fixed and or variable data? Does the order matter? dev-cmd or cmd-dev. |
Regardless of transmit sequence the fixed data goes in registers before the hex cmd. The fixed data starts in R03 and takes however many registers as the protocol specifies fixed bytes. The hex command goes into registers immediately after the fixed data, so its position depends on the number of bytes of fixed data. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
Posted: Mon Nov 15, 2004 6:06 pm Post subject: |
|
|
If you look on line FF07 of your disassembly you'll see that the device code is 3 bits, and on line FF08 you'll see that the command code is 8 bits, which gives you a total length of 11 bits.
Bit1 needs to toggle, which means bit1 of the command code needs to toggle, which means bit1 of R04 needs to toggle.
EDIT: I just noticed that the protocol is setup as "cmd-dev" (see the wrap-aound comment on line FF05) rather than the normal "dev-cmd", so bit1 of the signal would actually end up as being bit6 of the device code, which in turn would mean that you should XOR R03 with binary 01000000 (or hex 40), which is what you did. Well done.
In S3C8 protocols, the input data always starts with the R03 register and there can be up to 10 bytes of input data. If the protocol is setup for 3 fixed bytes and 2 variable bytes (which would mean the 2nd byte of the protocol would be "32"), the fixed data would come in via registers R03, R04 and R05, and the variable data would come in via registers R06 and R07. _________________ 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 |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Mon Nov 15, 2004 7:41 pm Post subject: |
|
|
Thanks John and Rob. While we are on a roll there was an Acer keyboard that needed the same thing (adding the second frame and toggling a bit) although a more complex protocol written by John.
Could you take a look. This will really help me understand the mechanics. I'm slow but I generally understand the logic:
http://www.hifi-remote.com/forums/viewtopic.php?p=22921#22921 _________________ -Jon |
|
Back to top |
|
|
digitalcujo
Joined: 04 Nov 2004 Posts: 6
|
Posted: Tue Nov 16, 2004 1:34 am Post subject: |
|
|
the last post of upgrade code works great!
so in the future, if I want to learn more keyboard keys and update the function code, how do find the hex function code from the raw data?
thanks again!
-rusty |
|
Back to top |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Tue Nov 16, 2004 2:02 am Post subject: |
|
|
The Robman wrote: | In S3C8 protocols, the input data always starts with the R03 register and there can be up to 10 bytes of input data. If the protocol is setup for 3 fixed bytes and 2 variable bytes (which would mean the 2nd byte of the protocol would be "32"), the fixed data would come in via registers R03, R04 and R05, and the variable data would come in via registers R06 and R07. | A quickie PB tutorial for you Jon
In PB, I've pre-assigned the name DCBUF to the first address of the device/command buffer, R03 in the case of the S3C8. You can then refer to the various bytes within the buffer using an offset value. So, using Rob's example above, the buffer is laid out as follows:
DCBUF: 1st fixed byte
DCBUF+1: 2nd fixed byte
DCBUF+2: 3rd fixed byte
DCBUF+3: 1st variable byte
DCBUF+4: 2nd variable byte
Let's say you want to load the second variable byte into register C0. Any one of these would work (and produce identical code):
Code: | LD RC0,R07
LD RC0,R03+4
LD RC0,DCBUF+4 | Hope this doesn't confuse things for you. _________________ Mike England |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Tue Nov 16, 2004 6:26 pm Post subject: |
|
|
digitalcujo wrote: | ... in the future, if I want to learn more keyboard keys and update the function code, how do find the hex function code from the raw data? |
I'm on a trip, but when I get home, I can send you an Excel spreadsheet that will decode the learned commands, but it's really pretty easy:
This is the learned command for numeral 1:
+1014 -876 +208 -678 +208 -678 +208 -284 +208 -284 +208 -284 +208 -284 +208 -284 +208 -284 +208 -284 +208 -678 +208 -284 +806 -77224 +1014 -876 +208 -678 +208 -678 +208 -284 +208 -284 +208 -284 +208 -284 +208 -284 +208 -284 +208 -284 +208 -284 +208 -284 +806 -130264
You only need to worry about the first frame that is separated from the second by a -77224:
+1014 -876 +208 -678 +208 -678 +208 -284 +208 -284 +208 -284 +208 -284 +208 -284 +208 -284 +208 -284 +208 -678 +208 -284 +806 -77224
The
+1014 -876 is a lead-in
The first eight burst pairs are what I called the variable data
+208 -678 Logical 1
+208 -678 Logical 1
+208 -284 Logical 0
+208 -284 Logical 0
+208 -284 Logical 0
+208 -284 Logical 0
+208 -284 Logical 0
+208 -284 Logical 0
Or 11000000 that is 192 decimal or hex C0
+208 -284 Logical 0
+208 -678 Logical 1
+208 -284 Logical 0
This is the "device" code and the new protocol changes the 1 in the second frame to 0 that signifies a release. (But this has already been entered in KM Master and the protocol handles the middle bit.)
+806 -77224 is the Lead-out
So just calculate the first 8-bits and convert to hex. You need to add a "h" without the quotes to tell KM Master that it is a hex value or hC0.
Mike, thanks for the explanation, the disassembly/re-assembly feature in PB is really cool. _________________ -Jon |
|
Back to top |
|
|
GameGod
Joined: 24 Jan 2005 Posts: 48 Location: California |
Posted: Fri Jan 28, 2005 1:05 pm Post subject: Need help learning a Chicony keyboard with a URC-8811 |
|
|
I've been trying to learn a Chicony keyboard on a URC 8811 with the aim of using the learned signals on a modded 6131. With Jon's help, I've been able to get some of it working.
Here's the problem:
My setup uses a lot of combo keys (Alt + S, Ctrl + F) etc. Now, usually IR cannot decode the learnt signal and it shows up only as raw data. However, in this file http://www.hifi-remote.com/forums/dload.php?action=file&file_id=1259, one button shows up as raw and the other as an old panasonic protocol. The buttons are learnt correctly, in the sense that I am able to perform the function with the learnt remote.
So how do I get this on to the 6131? Is this common to have one device use multiple protocols? I would think not.
Is there a correct procedure for learning a compound key like Alt + S?
Thanks.
Edited: To fix typo on model number.
Last edited by GameGod on Fri Jan 28, 2005 10:57 pm; edited 1 time in total |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Fri Jan 28, 2005 10:18 pm Post subject: |
|
|
Most keyboards don't actually send a compound key. They generally send a key-down and a key-up for each key (sometimes called -make and -break).
So Alt-S is actually Alt-down;S-Down;S-up;Alt-up
I haven't kept up with the IR keyboard stuff, but that is something I picked up along the way. I don't know if there a protcol available that actually allows you create individual down and up commands so that you create Alt-S as a macro. _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
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
|