|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
JPannell
Joined: 29 Apr 2004 Posts: 11
|
Posted: Tue Oct 05, 2004 1:20 pm Post subject: Acer Keyboard |
|
|
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 |
|
|
JPannell
Joined: 29 Apr 2004 Posts: 11
|
Posted: Tue Oct 05, 2004 8:28 pm Post subject: |
|
|
I have just tried it with the 2117 I got from Rob(thanks!) and the results are the same.
Thanks,
Jason |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Tue Oct 05, 2004 9:41 pm Post subject: |
|
|
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 |
|
|
JPannell
Joined: 29 Apr 2004 Posts: 11
|
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Wed Oct 06, 2004 11:29 pm Post subject: |
|
|
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 |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Tue Oct 12, 2004 4:07 pm Post subject: |
|
|
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 |
|
|
JPannell
Joined: 29 Apr 2004 Posts: 11
|
Posted: Thu Oct 14, 2004 10:15 pm Post subject: |
|
|
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 |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Mon Nov 15, 2004 7:36 pm Post subject: |
|
|
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 |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Tue Nov 16, 2004 12:46 am Post subject: |
|
|
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. _________________ Mike England |
|
Back to top |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Tue Nov 16, 2004 1:38 am Post subject: |
|
|
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 |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Tue Nov 16, 2004 10:38 am Post subject: |
|
|
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 |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21264 Location: Chicago, IL |
Posted: Tue Nov 16, 2004 11:38 am Post subject: |
|
|
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 |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Wed Nov 17, 2004 1:18 am Post subject: |
|
|
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 |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Wed Nov 17, 2004 8:12 am Post subject: |
|
|
That is 1 byte of 8 bits variable data and 0 bytes of 0 bits (each) of fixed data. |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Wed Nov 17, 2004 5:31 pm Post subject: |
|
|
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 |
|
|
|
|
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
|