Acer Keyboard

[JPannell]

Hi,
I am using an Acer wireless keyboard to control my HTPC. I am trying to use the upgrade file in the yahoo group, but I have one problem., the number keys do not work for me. If I learn the number keys to my remote(15-1994 for now) everything works, but if I use the device upgrade, everything works but the number keys. Any ideas?
Thanks,
Jason

[JPannell]

I have just tried it with the 2117 I got from Rob(thanks!) and the results are the same.
Thanks,
Jason

[jon_armstrong]

Post the IR file with the learned commads that work. It's possible that the numerals have changed. There are many eyboards that use the same IR protocol but have different command variants.

[JPannell]

Hi Jon,
Here is the link,
http://groups.yahoo.com/group/jp1/files ... numbers.IR
Thanks,
Jason

[jon_armstrong]

Jason, I'm traveling for five days and will be out of touch. If no one else figures this out, bump this thread in a week.

[jon_armstrong]

I had a chance to look at this. The protocol upgrade included with the device upgrade only does the make key. As with many keyboards the true IR protocol has a "make" and "break" bit. One bit changes when the key is released.

The learned commands that work proberly, have both the make and break commands. The upgrade has only the make command.

When you say the numerals don't work, do you mean not at all or unreliably?

I am pretty sure in reading John Fine's explanation of this protocol that the make/break bit is not affected by altering fixed or variable data. Here is the contents of the relevant thread from the yahoo group:

Code: Select all

From:   "johnsfine" <johnfine@attbi.com> 
Date:  Wed Jul 30, 2003  9:38 am
Subject:  Re: ACER IR keyboard. Decoder kludge available

http://groups.yahoo.com/group/jp1-km/files/C%2B%2B/DecodeIRcpp.zip

Includes my initial kludge version of decoding this protocol. The OBC
and Hex are based on ideas described below

...

Bits
13 0001111110110
07 Key
01 Release flag
01 Check bit
03 110
07 ~Key
01 ~Release flag
01 Check bit

If we wanted a hand coded protocol, we would prefer to keep the
variable data down to 8 bits. The Check bit is a pain to compute in
S3C80 ASM code (though possible if necessary) and I think we can get
away with doing little or nothing with the Release flag, so in my
kludge decoder I made the OBC be just the 7 bit Key and I made the Hex
command be the 7 bit key plus the 1 bit check, skipping the release flag.
 

Call the 7 key bits tuvwxyz.
Call the inverted 7 key bits TUVWXYZ.
Remember a '1' is just gap, so we can add a '1' on the beginning
without changing anything.

Call the whole thing five 7-bit bytes (with an 8'th bit that won't be
transmitted shown on the right of each).

R03: 1000111#
R04: 1110110#
R05: tuvwxyzc
R06: 0c110TU0
R07: VWXYZ1c0

If we come in with just R03,R04 (fixed) and R05 (variable) set as
shown. I think the following code would set R06 and R07.

W0 0 ; Enable easier access to R00..R07
LD R06, 6 ; R06 = 00000110
LD R07, R05 ; R07 = tuvwxyzc
LDB R06.3, R07 ; R06 = 0000c110
RR R07 ; R07 = ctuvwxyz
ADD R07, R07 ; R07 = tuvwxyz0
COM R07 ; R07 = TUVWXYZ1
RLC R07 ; R07 = UVWXYZ1c
RLC R06 ; R06 = 000c110T
RLC R07 ; R07 = VWXYZ1c0
RLC R06 ; R06 = 00c110TU
RLC R06 ; R06 = 0c110TU0
W0 C0 ; Restore normal easy access to RC0..RC7

Then just increase fixed bytes from 2 to 4 and jump to the main engine.

This assumes we can send just press commands and never release. If
that's false we could call the IR engine (while key down) instead of
jumping to it, then invert the release flag:
XOR R06, C0
XOR R07, 6
and finally jump to the IR engine.

John, it looks like we need to add the break bit, too.

[JPannell]

Hi Jon,
I have done some experimenting with the remote, and I can get the numeral keys to work intermittently in notepad, so the signal is being received by the receiver, but other applications I am using (myHTPC, GotTv) do not respond at all. They do respond to the learned signals though.
Thanks,
Jason

[jon_armstrong]

Since I'm getting an education on how to program flipping make/break bits on keyboards today I'll try to get some exoert help here as well:

Here is the disassembly of John's Acer protocol:

Code: Select all

Addr	Code	Label	Op	Op Args	Comments
			REMOTE	S3C8+	
FF00	43 89		DB	43H,89H	;38.5 kHz 33%
FF02	21		DB	21H	;2 dev, 1 cmd
FF03	8B 0F		JR	LFF14	
FF05	87		DB	87H	;pf0: 10000111=devs,1-cmd,dev-cmd
FF06	80		DB	80H	;pf1: 10000000=-LO
FF07	40		DB	40H	;pf2: 01000000=LOb16=1
FF08	07		DB	07H	;pd00: DevBits1=7
FF09	07		DB	07H	;pd01: CmdBits1=7
FF0A	00 00		DW	0000H	;pd02/03: 1-burst on=0 uS
FF0C	01 90		DW	0190H	;pd04/05: 1-burst off=840 uS
FF0E	00 D2		DW	00D2H	;pd06/07: 0-burst on=420 uS
FF10	00 BE		DW	00BEH	;pd08/09: 0-burst off=420 uS
FF12	E8 48		DW	E848H	;pd0A/0B: Leadout off=118928 uS
FF14	31 00	LFF14:	SRP	#00H	
FF16	6C 06		LD	W6,#06H	
FF18	78 05		LD	W7,DCBUF+2	
FF1A	47 77 06		LDB	DCBUF+3.3,W7	
FF1D	E0 07		RR	DCBUF+4	
FF1F	02 77		ADD	W7,W7	
FF21	60 07		COM	DCBUF+4	
FF23	10 07		RLC	DCBUF+4	
FF25	10 06		RLC	DCBUF+3	
FF27	10 07		RLC	DCBUF+4	
FF29	10 06		RLC	DCBUF+3	
FF2B	10 06		RLC	DCBUF+3	
FF2D	31 C0		SRP	#C0H	
FF2F	E6 10 04		LD	R10,#04H	
FF32	8D 01 46		JP	0146H	

John has explained what needs to be done but when I try this in the PB assembler I get errors (the two lines with no address and "Invalid Argument":

This assumes we can send just press commands and never release. If
that's false we could call the IR engine (while key down) instead of
jumping to it, then invert the release flag:
XOR R06, C0
XOR R07, 6
and finally jump to the IR engine.

I assume this is just adding at the bottom:

CALL 0146H (instead of the last jump statement)
XOR R06, C0H
XOR R07, 6H
JP 0146H

When I try that I get errors. Any help will be appreciated from the assembly language gurus.

Here is what it looks like when I run "assemble":

Code: Select all

Addr	Code	Label	Op	Op Args	Comments	Errors
			REMOTE	S3C8+		2 ERRORS
FF00	43 89		DB	43H,89H	;38.5 kHz 33%	
FF02	21		DB	21H	;2 dev, 1 cmd	
FF03	8B 0F		JR	LFF14		
FF05	87		DB	87H	;pf0: 10000111=devs,1-cmd,dev-cmd	
FF06	80		DB	80H	;pf1: 10000000=-LO	
FF07	40		DB	40H	;pf2: 01000000=LOb16=1	
FF08	07		DB	07H	;pd00: DevBits1=7	
FF09	07		DB	07H	;pd01: CmdBits1=7	
FF0A	00 00		DW	0000H	;pd02/03: 1-burst on=0 uS	
FF0C	01 90		DW	0190H	;pd04/05: 1-burst off=840 uS	
FF0E	00 D2		DW	00D2H	;pd06/07: 0-burst on=420 uS	
FF10	00 BE		DW	00BEH	;pd08/09: 0-burst off=420 uS	
FF12	E8 48		DW	E848H	;pd0A/0B: Leadout off=118928 uS	
		LFF14:	SRP	#00H		Invalid argument
FF14	6C 06		LD	W6,#06H		
FF16	78 05		LD	W7,DCBUF+2		
FF18	47 77 06		LDB	DCBUF+3.3,W7		
FF1B	E0 07		RR	DCBUF+4		
FF1D	02 77		ADD	W7,W7		
FF1F	60 07		COM	DCBUF+4		
FF21	10 07		RLC	DCBUF+4		
FF23	10 06		RLC	DCBUF+3		
FF25	10 07		RLC	DCBUF+4		
FF27	10 06		RLC	DCBUF+3		
FF29	10 06		RLC	DCBUF+3		
			SRP	#C0H		Invalid argument
FF2B	E6 10 04		LD	R10,#04H		
FF2E	F6 01 46		Call	0146H		
FF31	B4 C0 06		XOR	R06,C0H		
FF34	B4 06 07		XOR	R07,6H		
FF37	8D 00 92		JP	0146		

[mr_d_p_gumby]

Code: Select all

	LFF14:	SRP	#00H		Invalid argument

I'm not sure if my assembler's syntax is right on this, but I did follow the Samsung data book. The SRP instruction is expecting a register reference, not a literal value as an argument. Leave the "#" off, and it works fine:

Code: Select all

FF14	31 00	LFF14:	SRP	00H

The disassembler is generating the wrong type of argument for the assembler. I've added this to the list of fixes for the next release.

[mr_d_p_gumby]

This assumes we can send just press commands and never release. If
that's false we could call the IR engine (while key down) instead of
jumping to it, then invert the release flag:
XOR R06, C0
XOR R07, 6
and finally jump to the IR engine.

I assume this is just adding at the bottom:

CALL 0146H (instead of the last jump statement)
XOR R06, C0H
XOR R07, 6H
JP 0146H

This would issue a down-up command immediately no matter how long the button was held down. If you want it to keep sending "down" while the button is pressed, then "up" when it is released, you need to call the routine that checks if the button is still down before doing the XOR & final call. I think it is a call to $010A, but I don't remember if this is correct or not (maybe John or Rob can correct me if I'm wrong). So your addition at the bottom would look like this:

Down1: CALL 0146H
CALL 010AH
JRC Down1
XOR R06, C0H
XOR R07, 6H
JP 0146H

[johnsfine]

This would issue a down-up command immediately no matter how long the button was held down. If you want it to keep sending "down" while the button is pressed, then "up" when it is released, you need to call the routine that checks if the button is still down before doing the XOR & final call.

Actually the first call to 0146 would either send the signal once or send repeatedly until the key is released depending on one of the control bits (that Jon probably remembers better than I do).

So with just the call, xor and jmp you could either send press and immediately release or send repeating press and later release (chosen by setting that control bit).

I haven't looked at the learned signals, but the discussion in one of these recent keyboard threads sounded like the requirement was to send press once, then wait and send release at the right time. That's the form that's tricky enough that it requires a loop checking whether the key was released. THAT loop should not include the call to send the press code.

[The Robman]

If bit0 of R29 is set, the signal will repeat, if it's not set it won't. If you plan on handling when to send the signal yourself if the protocol code, you should have this bit turned off. If it's turned on when you JP or CALL $0146 and the user is holding the button down, you won't come back from the call until they let the button go.

So, if you want to send the signal once, then return to the code to do something else, this bit should be turned off.

If your intent is to program the executor to send a signal after the button is released, you should have this bit turned on when you go to $0146 as that way control won't get returned to the executor until the button is released at which point you can program code to send whatever additional signals are required.

Just FYI, when you look at the raw data for an executor, here's a quick high-level of what the data represents:

bytes
1-2 = these tell you the frequency and the duty cycle (R0E,R0F)
3 = high-nibble tells you the number of fixed bytes (R10)
3 = low-nibble tells you the number of variable bytes (R11)
4-5 = this is a JP command that skips over the data block, which follows:

6-7 = Even though I've listed this as being 2 bytes, the number of bytes is actually variable, but 2 bytes is the most common. The MSB of each byte, if set, indicates that another byte follows. This data ends up in registers R28 thru R2C. There is alot of control built into these bytes, see below.

8 = number of bits to be used from the fixed bytes (R12)
9 = number of bits to be used from the variable bytes (R13)
10-11 = ON time for logical ONE burst pair (R14,R15)
12-13 = OFF time for logical ONE burst pair (R16,R17)
14-15 = ON time for logical ZERO burst pair (R18,R19)
16-17 = OFF time for logical ZERO burst pair (R1A,R1B)
18-19 = LEAD-OUT time (or sometimes TOTAL TIME, based on R29.6) (R1C,R1D)
20-21 = ON time for lead-in burst pair (R1E,R1F)
22-23 = OFF time for lead-in ONE burst pair (R20,R21)
24 = length in bits of 2nd fixed byte [only when R29.4 is set] (R22)
25 = minimum times to repeat the signal (R23)
26 = length in bits of 2nd variable byte (R24)


Now for the control bytes starting with R28:

Code: Select all

R28 bits:
0-1     words to send in device code portion of IR signal
        0 = nothing
        1 = single word of R12 bits
        2 = word of R12 bits followed by word of R22 bits
        3 = all protocol's fixed parameters starting from the R01-th (R12 bits each)

2-3     words to send in command code portion of IR signal
        0 = nothing
        1 = single word of R13 bits
        2 = word of R13 bits followed by word of R24 bits
        3 = all protocol's variable parameters (R13 bits each)

4-5     how to compose the signal (! = complement)
        0 = device - command
        1 = device - command - !device - !command
        2 = device - !device - command - !command
        3 = command - device

6       0/1 is Lead Out gap adjusted for total frame length (Off as Total)

7       is R29 present?
        0 = no
        1 = yes

R29 bits
0-1     does the signal repeat while button is held down?
        0 = no
        1 = yes
        2 = Ch+/-, Vol+/-, FF, Rew
        3 = No data bits in repeat

2-3     how to send lead-in burst pair???
        0 = nothing
        1 = always RR1E/RR20
        2 = RR1E/RR20 the first time only, nothing afterwards
        3 = RR1E/RR20 the first time, @D0 the following times

4       R23 is valid

5-6     Lead Out On style
        0 = [-LO]
        1 = [LI], [-LO]
        2 = [One On, -LO]
        3 = [LI], [One On, -LO]

7       is R2A present?
        0 = no
        1 = yes

R2A bits
0-1     how to send data for device code
        0 = send data as-is
        1 = send 0 after every bit
        2 = send 1 after every bit
        3 = send every bit twice

2-3     how to send data for command code
        0 = send data as-is
        1 = send 0 after every bit
        2 = send 1 after every bit
        3 = send every bit twice

4       Send zero backwards (bi-phase) ?
        0 = no
        1 = yes

5       send burst pair RR18/(RR14+RR16+RR1A) instead of RR18/RR1A

7       is R2B present?
        0 = no
        1 = yes

R2B bits
0-1     special stuff
        1 = XOR the device code with #$78 and put it in R08
        3 = use four bits to send two bits (1000 = 0, 0100 = 1, 0010 = 2, 0001 = 3)

5       use alt lead out?

7       is R2C present?
        0 = no
        1 = yes


R2C bits
6	prepend 1 to every word added to the IR signal, and append the following:

R2C.5   parity
R2C.4   inverted parity
R2C.3   two 0's
R2C.2   one 0

[jon_armstrong]

Rob, John, and Mike; it will take me a while to absorb all this, but it is extremely helpful. I'm traveling now but I will test out the various options when I get back.

Of course, I think I found an exception (and if I disassemble in PB I get a VB error):

Upgrade Protocol 0 = 00 1D (S3C8+) pid: 00 1D (KM v8.28)
58 D0 01 8B 0E 84 12 00 08 03 0C 00 00 00 00 02
FA 4A EC 60 03 E6 23 02 8D 01 49
End

How many fixed and variable bytes and how many bits per fixed and variable bytes??

Thanks!

[johnsfine]

That is 1 byte of 8 bits variable data and 0 bytes of 0 bits (each) of fixed data.

[jon_armstrong]

Thanks John I had 001D (and completely consistent with Rob's explanation) confused with 000D the relevance being in this thread.