JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Acer Keyboard

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Keyboards
View previous topic :: View next topic  
Author Message
JPannell



Joined: 29 Apr 2004
Posts: 11

                    
PostPosted: Tue Oct 05, 2004 1:20 pm    Post subject: Acer Keyboard Reply with quote

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
Back to top
View user's profile Send private message
JPannell



Joined: 29 Apr 2004
Posts: 11

                    
PostPosted: Tue Oct 05, 2004 8:28 pm    Post subject: Reply with quote

I have just tried it with the 2117 I got from Rob(thanks!) and the results are the same.
Thanks,
Jason
Back to top
View user's profile Send private message
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Tue Oct 05, 2004 9:41 pm    Post subject: Reply with quote

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.
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
JPannell



Joined: 29 Apr 2004
Posts: 11

                    
PostPosted: Tue Oct 05, 2004 11:16 pm    Post subject: Reply with quote

Hi Jon,
Here is the link,
http://groups.yahoo.com/group/jp1/files/Diagnosis%20Area/acer_keyboard_numbers.IR
Thanks,
Jason
Back to top
View user's profile Send private message
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Wed Oct 06, 2004 11:29 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail Visit poster's website
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Tue Oct 12, 2004 4:07 pm    Post subject: Reply with quote

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:
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.
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
JPannell



Joined: 29 Apr 2004
Posts: 11

                    
PostPosted: Thu Oct 14, 2004 10:15 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Mon Nov 15, 2004 7:36 pm    Post subject: Reply with quote

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:
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":

Quote:
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:
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      

_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mr_d_p_gumby
Expert


Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA

                    
PostPosted: Tue Nov 16, 2004 12:46 am    Post subject: Reply with quote

jon_armstrong wrote:
Code:
   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:
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. Crying or Very sad
_________________
Mike England
Back to top
View user's profile Send private message
mr_d_p_gumby
Expert


Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA

                    
PostPosted: Tue Nov 16, 2004 1:38 am    Post subject: Reply with quote

jon_armstrong wrote:
Quote:
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
_________________
Mike England
Back to top
View user's profile Send private message
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Tue Nov 16, 2004 10:38 am    Post subject: Reply with quote

mr_d_p_gumby wrote:
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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Nov 16, 2004 11:38 am    Post subject: Reply with quote

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

_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!


Last edited by The Robman on Thu Dec 02, 2004 3:50 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Wed Nov 17, 2004 1:18 am    Post subject: Reply with quote

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!
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Wed Nov 17, 2004 8:12 am    Post subject: Reply with quote

That is 1 byte of 8 bits variable data and 0 bytes of 0 bits (each) of fixed data.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Wed Nov 17, 2004 5:31 pm    Post subject: Reply with quote

Thanks John I had 001D (and completely consistent with Rob's explanation) confused with 000D the relevance being in this thread.
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Keyboards All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control