Chicony keyboard?

[The Robman]

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.

[jon_armstrong]

Your keyboard uses a fairly different IR Protocol from the other Chicony KB. Try this device/protocol upgrade.

[digitalcujo]

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

[johnsfine]

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.

[jon_armstrong]

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.

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: Select all

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.

[The Robman]

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: Select all

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

[jon_armstrong]

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.

[johnsfine]

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.

[The Robman]

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.

[jon_armstrong]

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:

https://www.hifi-remote.com/forums/viewt ... 2921#p22921

[digitalcujo]

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

[mr_d_p_gumby]

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: Select all

LD   RC0,R07
LD   RC0,R03+4
LD   RC0,DCBUF+4

Hope this doesn't confuse things for you.

[jon_armstrong]

... 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.

[GameGod]

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 https://www.hifi-remote.com/forums/dload ... le_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.

[gfb107]

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.