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

chicony IR keyboard debug help
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Keyboards
View previous topic :: View next topic  
Author Message
digitalcujo



Joined: 04 Nov 2004
Posts: 6

PostPosted: Thu Nov 04, 2004 4:58 pm    Post subject: chicony IR keyboard debug help Reply with quote

I learned how to get my radio-shack remote to learn from the Chicony IR keyboard. The remote can now send the learned keyboard signals successfully, but as many others have mentioned, I ran out of memory quickly. I’m currently stuck trying to get the JP1 software to load the chicony IR keyboard protocol in a format that the receiver with listen to.
Here are the steps I took:
1) I downloaded the IR software and KM spreadsheet and loaded the following file into the spreadsheet software…
http://groups.yahoo.com/group/jp1/files/3.%20Device%20Codes/Keyboards/Chicony_KB-KM3.txt

2) Within the spreadsheet I mapped the “cable” buttons to the learned keys, and loaded them up into the remote as cable “1999”.
3) When I try to send the signals from the remote, the IR port doesn’t respond at all to any keys.
4) To make sure I’m doing the whole process correctly, I learned the volume control from my sony TV remote, and then re-mapped the learned volume button to the cable button “zero” in IR software, and the TV does respond to my re-mapped key. This experiment tells me that I’m going through most of the process successfully.

I’m not sure how to proceed, so I posted the remotes memory dump to the diagnosis area, and I was hoping one of you could point me in the right direction.

1. Device: ir keyboard
2. Type of device: Chicony kb-0005
3. Remote model: learning remote: radioshack 15-2115
4. JP1 user? yes
5. Still have original remote? yup, I have the original ir keyboard.
6. Checked Yahoo file section? yes, used: Chicony_KB-KM3.txt
7. Checked Pronto file section (at R/C)? no

Diagnosis File: irchicony_chicony.txt

Everything in the "SAT" section is learned from the keyboard.
Back to top
View user's profile Send private message
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3379
Location: Cary, NC

PostPosted: Thu Nov 04, 2004 5:26 pm    Post subject: Reply with quote

Please also post a copy of the IR file you are using that has the device and protocol upgrades installed, so that we can see that you did that correctly.
_________________
-- 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
View user's profile Send private message Visit poster's website
Mark Pierson
Expert


Joined: 03 Aug 2003
Posts: 3011
Location: Connecticut, USA

PostPosted: Thu Nov 04, 2004 7:36 pm    Post subject: Re: chicony IR keyboard debug help Reply with quote

digitalcujo wrote:
2) Within the spreadsheet I mapped the “cable” buttons to the learned keys, and loaded them up into the remote as cable “1999”.

You lost me with this comment. Are you saying that you used the Cable device type with a setup code of 1999 (which is what the upgrade is already set for)? And what do you mean by mapped buttons to the learned keys?

When you opened the upgrade in KM, did you also select the proper remote to match your model on the Setup sheet (the upgrade is for a URC-9910)?
_________________
Mark
Back to top
View user's profile Send private message Send e-mail Visit poster's website
digitalcujo



Joined: 04 Nov 2004
Posts: 6

PostPosted: Thu Nov 04, 2004 11:28 pm    Post subject: Reply with quote

thanks for the responses!

I uploaded the IR file to http://groups.yahoo.com/group/jp1/files/Diagnosis%20Area/irchicony_chicony.txt

In my first post I was trying to say that the chicony device code I downloaded from the JP1 website changes the default device type in the spreadsheet to "cable" and setup code to "1999". I also made sure that I changed the remote type in cell C:2 to my remote type 15-2117/15-2116. After I copied the upgrade code and protocol code to the IR program and then uploaded it to the remote, my remote shows that shows the setup code for cable is set to 1999 in the LCD display.

As for my comment about "mapped buttons to the learned keys", I misspoke about the learned keys. I ment that I made sure that the remote buttons were correctly mapped to functions in the "buttons" worksheet.

here is the "setup" worksheet C2:C23 (the only part I changed is the remote type):
Remote: 15-2117 / 15-2116
Device Type: Cable
Setup Code: 1999
Button Codes: OBC
SURR = Select: NO

Protocol Name: Manual Settings
Device1: 1
Device2:
Device3:
Raw Fixed Data:

Protocol ID: 01 77
Fixed Data: 80
Manual Settings
PID:
2nd Cmd Byte: None
Signal Style: LSB
Bits/Dev: 8
Bits/Cmd: 8
Back to top
View user's profile Send private message
digitalcujo



Joined: 04 Nov 2004
Posts: 6

PostPosted: Thu Nov 04, 2004 11:33 pm    Post subject: Reply with quote

opps, I forgot to mention the URL of the protocol upgrades:
http://groups.yahoo.com/group/jp1/files/3.%20Device%20Codes/Keyboards/Chicony_KB-KM3.txt
Back to top
View user's profile Send private message
digitalcujo



Joined: 04 Nov 2004
Posts: 6

PostPosted: Mon Nov 08, 2004 9:13 pm    Post subject: Reply with quote

Update: This weekend I was able to download the upgrade code for my cable box (motorola DCT 2000) and program my remote with it (via JP1). Since this upgrade work flawlessly on my remote, I know that I’m on the right track as far as using the IR.exe/KM to program my remote with upgrade code. This leads me to think that something in the chicony protocol isn't working with my model of IR keyboard.
How do I go about decoding the learned codes to figure out how the difference between the learned code and upgrade code? Does anyone have a good example thread/website that I could learn from?
thanks in advanced.
Back to top
View user's profile Send private message
The Robman
Site Owner


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

PostPosted: Mon Nov 08, 2004 9:56 pm    Post subject: Reply with quote

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
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: Fri Nov 12, 2004 3:45 pm    Post subject: Reply with quote

Your keyboard uses a fairly different IR Protocol from the other Chicony KB. Try this device/protocol upgrade.
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
digitalcujo



Joined: 04 Nov 2004
Posts: 6

PostPosted: Mon Nov 15, 2004 2:30 am    Post subject: Reply with quote

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
View user's profile Send private message
johnsfine
Site Admin


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

PostPosted: Mon Nov 15, 2004 8:17 am    Post subject: Reply with quote

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
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: Mon Nov 15, 2004 1:24 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


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

PostPosted: Mon Nov 15, 2004 2:10 pm    Post subject: Reply with quote

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
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: Mon Nov 15, 2004 5:49 pm    Post subject: Reply with quote

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


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

PostPosted: Mon Nov 15, 2004 5:58 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


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

PostPosted: Mon Nov 15, 2004 6:06 pm    Post subject: Reply with quote

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
View user's profile Send private message 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
Goto page 1, 2  Next
Page 1 of 2

 
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
Get Smart! the band's official homepage Rockabilly Central