 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
IBNobody
Joined: 06 May 2007
Posts: 124
|
 Posted: Sat Oct 13, 2007 12:38 am Post subject: |
 |
|
I have a very rough codebase for the NEC1 protocol decoder.
It's based around a countdown timer that deincrements from 67ms every 25us. The timer starts on the rising edge of a demodulated burst and resets every subsequent edge. At each edge, the timer value is read and the interval is used to classify the burst. If no edge is detected within 67ms, the packet is terminated and the contents are checked for device and complement information. |
|
| Back to top |
|
 |
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Sat Oct 13, 2007 7:22 am Post subject: |
|
|
| IBNobody wrote: | | If no edge is detected within 67ms, the packet is terminated and the contents are checked for device and complement information. |
1) I'm not sure if that is what you meant, so I'll warn you about a serious error that sounds like:
Some IR receivers apparently let a default value control the bits they haven't seen yet. If the packet ends early, they may accept it using those default values. There are too many ways that garbage or an actual truncated packet may do that and give you a wrong command. If you don't get the whole packet, throw away the partial and wait for another.
2) 67ms is too long for that. In fact any large amount is more than you actually want. The main factor in terminating a valid packet is that you have the expect number of bits. After that, you just need to detect that the next burst is longer than a valid '1' bit. You don't need to see that the next burst is very long. Why make your response time slower for no reason.
3) Your first stage measures every burst (start to start). It should be able to reset to idle state any time a burst significantly longer than a start burst is measured, and recognize a valid start pulse any time it is in idle state. It should also be able to latch into garbage state when anything goes wrong and stay there until a long burst puts it in idle state. |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Sun Oct 14, 2007 8:57 am Post subject: |
|
|
I'm making some changes to my IR decoder based on what you said. Some of the things you mentioned were already being used.
Instead of having a terminator (a pulse followed by no pulse at all) trigger the packet computation, I will now count bits. When I get to 32, I'll check the packets.
This also requires a change to the burst measurement timer. I will shorten the timeout value from 67ms to 15ms. If I don't receive a "capping" burst within 15ms, I will trip my error flag.
My error flag currently invalidates the packet and is only reset upon the receipt of a valid header. Also, I can receive a header at any time.
If you can suggest any common error modes, that would be helpful. I am simulating the burst receiver using Altera's waveform analyzer tool in MAXPlus2. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Sun Oct 14, 2007 9:43 am Post subject: |
|
|
| IBNobody wrote: | | If you can suggest any common error modes, that would be helpful. I am simulating the burst receiver using Altera's waveform analyzer tool in MAXPlus2. |
First you need a definition of correct. I use IRP notation to describe IR signals. In IRP notation, NEC2 protocol is:
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+
The meanings of the various parts of that are:
38.4k The signal is modulated at about 38.4Khz
564 The rest of this IRP string gives time in units of about 564 microseconds.
1,-1 A zero bit is encoded as 1 unit (564uS) modulated followed by one unit quiet.
1,-3 A one bit is encoded as 1 unit modulated followed by three units quiet.
16,-8,D:8,S:8,F:8,~F:8,1,-78 Each frame consists of 16 units modulated followed by 8 units quiet, followed by 8 bits encoding the device number, 8 bits encoding the subdevice, 8 bits encoding the function, 8 bits encoding the complement of the function, one unit of modulation and about 78 units of quiet. (Each bit is encoded as described earlier).
()+ The whole frame is repeated as long as the button is held.
The most common error is that the ends of modulation are randomly early, so instead of 564uS modulated and 564uS quiet, one zero bit might be 500 and 628, another might be 200 and 928. If you just look at the start to start times, you'll never even notice.
Next, the original remote might have a different time base. You ought to be able to easily handle up to 20% off in either direction: With a receiver designed for units of 564, have the sender using 451 or 677.
Start of modulation can also be randomly late at little, not by as much nor as often as end of modulation is randomly early. 50 uS late is the most you should expect for the start of bursts other than the first (the first may be off by more). Since you are measuring start to start, if one start is late and the next not late, a burst could measure 50uS short. The burst before the late one could be 50uS long. That is on top of them being long or short due to a different time base.
The common serious error is that some bursts are dropped entirely, due to varying aim by the operator of the remote. Usually, those are dropped off the beginning, sometime the end, less often the middle. Those errors should be unrecoverable. Your goal for those should be to avoid a spurious decode, rather than to get the correct decode. (Vs. all the issues I described earlier in which the goal is to get a correct decode despite distorted input). It should be easy to detect that there simply weren't enough bursts before the next longer gap. It's rather disgusting that there are major brand consumer products whose IR receivers get that wrong.
If you are rather tolerant of timing distortion, then another "error" you need to worry about is that the signal you're looking at is from an unrelated remote. It might accidentally match your device code and have a valid function complement. That's not very likely, but it is another reason why it is worth checking that there is more than a maximum valid one bit worth of gap after the last bit (the protocols likely to match the first 32 bits likely have more than 32 bits). |
|
| Back to top |
|
|
The Others
Joined: 14 Oct 2007
Posts: 6
Location: Montreal,Qc
|
| Posted: Sun Oct 14, 2007 3:08 pm Post subject: |
|
|
Hi IBNobody,
My first name is Ben.
That's funny, I had the exact same idea about 2 weeks ago and first open my remote last Friday.
I'm planning on using the following to do the same:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3146
and a Sharp IR Receiver (don't have the number with me at this moment).
Both are available at digikey.com
I will use the Harmony 880 with PS2 code to control this IR>>Bluetooth box.
Are you willing to share with me some tech details about the key press simulation you are planning to do in your XPGA/PLD?
Right now I am at the point of understanding the sense/scan usage. My current observations tells me the following:
- Lines 1 to 20 are inactive low on no key press. A strong pullup don't lift them, so these lines are actively driven low. This is not a pulldown.
- Lines 21 to 28 need a pulldown of at least 4.7K to create activity. Internal pullup is probably close to 10K. This pulldown creates a pulse stream of 100uSec (LO 90% - HI 10%)
- If pressing ONE key, only one of the Lines 21 to 28 is active. In this case, if a weak pullup (470K) is put on any of the non-active Lines 1 to 20 the signal will toogle (HI 90% - LO 10%). This confirm the open drain on Lines 1 to 20 with an estimated 1M impedance in this case.
At home I'm currently limited because I have only access to a 1 channel 10MHz scope. I'll do more this week at work.
To show you how serious I am here is my keyboard mapping.
A1-3
A2-2
A3-1
A4-EJECT
B1-6
B2-5
B3-4
B4-AUDIO
C1-9
C2-8
C3-7
C4-ANGLE
D1-TIME
D2-0
D3-CLEAR
D4-SUBTITLE
E1-YELLOW
E2-BLUE
E3-GREEN
E4-RED
F1-RETURN
F2-POP UP/MENU
F3-TOP MENU
F4-DISPLAY
G1-BACK(RED CIRCLE)
G2-UP ARROW
G3-OPTIONS(GREEN TRIANGLE)
H1-RIGHT ARROW
H2-ENTER
H3-LEFT ARROW
I1-BLUE CROSS
I2-DOWN ARROW
I3-VIEW(RED SQUARE)
J1-R1
J2-PlayStation
J3-L1
K1-R2
K2-L2
L1-R3
L2-START
L3-SELECT
L4-L3
M1-SCAN RIGHT
M2-PLAY
M3-SCAN LEFT
N1-NEXT RIGHT
N2-STOP
N3-NEXT LEFT
O1-SLOW/STEP RIGHT
O2-PAUSE
O3-SLOW/STEP LEFT
01-K1
02-J1
03-J3
04-I2
05-H1
06-H3
07-G2
08-L2
09-K2
10-J2
11-I1
12-I3
13-H2
14-G1
15-G3
16-E1,L1,O1,N2,M3,D2,C3,B4
17-F1,E2,A1,D3,C4,L3,N3
18-F2,B1,A2,E3,D4,L4,O2
19-F3,E4,C1,B2,A3,M1,O3
20-F4,C2,B3,A4,D1,N1,M2
21-L2,L1 --- pull up
22-K1,L3,O3,O2,O1,N1,K2 --- pull up
23-J1,M1,M2,L4,N3,N2,J2 --- pull up
24-F4,F3,F2,F1,I1,J3,M3 --- pull up
25-E4,E3,E2,E1,D1,I2,I3 --- pull up
26-D4,D3,D2,C1,C2,H1,H2 --- pull up
27-C4,C3,B2,B3,B1,G1,H3 --- pull up
28-B4,A4,A3,A2,A1,G2,G3 --- pull up
01-K1 21-L2
02-J1 21-L1
03-J3 22-K1
04-I2 22-L3
05-H1 22-O3
06-H3 22-O2
07-G2 22-O1
08-L2 22-N1
09-K2 22-K2
10-J2 23-J1
11-I1 23-M1
12-I3 23-M2
13-H2 23-L4
14-G1 23-N3
15-G3 23-N2
16-E1 23-J2
16-L1 24-F4
16-O1 24-F3
16-N2 24-F2
16-M3 24-F1
16-D2 24-I1
16-C3 24-J3
16-B4 24-M3
17-F1 25-E4
17-E2 25-E3
17-A1 25-E2
17-D3 25-E1
17-C4 25-D1
17-L3 25-I2
17-N3 25-I3
18-F2 26-D4
18-B1 26-D3
18-A2 26-D2
18-E3 26-C1
18-D4 26-C2
18-L4 26-H1
18-O2 26-H2
19-F3 27-C4
19-E4 27-C3
19-C1 27-B2
19-B2 27-B3
19-A3 27-B1
19-M1 27-G1
19-O3 27-H3
20-F4 28-B4
20-C2 28-A4
20-B3 28-A3
20-A4 28-A2
20-D1 28-A1
20-N1 28-G2
20-M2 28-G3
28-A1 15-G3
17-A1 28-G3
18-A2 05-H1
28-A2 26-H1
19-A3 26-H2
28-A3 13-H2
20-A4 27-H3
28-A4 06-H3
27-B1 24-I1
18-B1 11-I1
19-B2 04-I2
27-B2 25-I2
20-B3 12-I3
27-B3 25-I3
28-B4 02-J1
16-B4 23-J1
26-C1 10-J2
19-C1 23-J2
20-C2 03-J3
26-C2 24-J3
27-C3 01-K1
16-C3 22-K1
17-C4 22-K2
27-C4 09-K2
25-D1 16-L1
20-D1 21-L1
26-D2 08-L2
16-D2 21-L2
26-D3 17-L3
17-D3 22-L3
18-D4 23-L4
26-D4 18-L4
25-E1 19-M1
16-E1 23-M1
25-E2 20-M2
17-E2 23-M2
18-E3 16-M3
25-E3 24-M3
25-E4 20-N1
19-E4 22-N1
24-F1 23-N2
17-F1 16-N2
18-F2 23-N3
24-F2 17-N3
24-F3 16-O1
19-F3 22-O1
24-F4 22-O2
20-F4 18-O2
27-G1 19-O3
14-G1 22-O3
07-G2
28-G2 |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Sun Oct 14, 2007 3:22 pm Post subject: |
|
|
Thanks for the info...
I think I have the decoder nailed down. It counts bits and waits for at least 16ms of dead time after the frame. At that point, data is valid.
I have the button switcher routine done, too. The only thing I need is logic to connect the two.
How long would you recommend I hold the button down?
I have to hold it down for at least 2ms due to the scan rate on the BD remote. BUT... I need a hold time of at least 110ms, probably more. This would prevent any button releases while I'm waiting for the next IR packet. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Sun Oct 14, 2007 5:14 pm Post subject: |
|
|
| The Others wrote: | | Right now I am at the point of understanding the sense/scan usage. My current observations tells me the following: |
Have you read what was already posted in this thread? I think you will find it explains everything about the sense/scan usage that you seem (from the next things you said) to not understand.
| The Others wrote: | | - Lines 1 to 20 are inactive low on no key press. |
I would call that "active low". While no keys are pressed, all scan line are active in order to detect when any key is pressed.
| The Others wrote: | | - If pressing ONE key, only one of the Lines 21 to 28 is active. |
I can't tell whether you really understand that. All scan lines are equally (same frequency, different phase) cycling between low voltage and high impedance. The one line that looks different on the scope only looks different because it is connected to the 10K pull up in the sense line.
| The Others wrote: | | At home I'm currently limited because I have only access to a 1 channel 10MHz scope. I'll do more this week at work. |
But since we already have those results posted here, you don't need to.
| The Others wrote: |
To show you how serious I am here is my keyboard mapping. |
I don't understand. What do the codes mean in that list? At first I though you were giving scan/sense coordinates of the labeled keys of the bluetooth remote, with a letter for each scan line and a number for each sense line. But the distribution doesn't fit the description earlier in this thread and I can't figure out the later portion of your mapping at all.
| IBNobody wrote: |
How long would you recommend I hold the button down?
I have to hold it down for at least 2ms due to the scan rate on the BD remote. BUT... I need a hold time of at least 110ms, probably more. This would prevent any button releases while I'm waiting for the next IR packet. |
It may be necessary to hold long enough to avoid interruption if you miss an IR packet. I'm not sure. Even just long enough to get the next packet if none are dropped may make the system feel sluggish. I found your request for a faster protocol very convincing. |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Sun Oct 14, 2007 5:48 pm Post subject: |
|
|
| I posted my message and didn't see yours, Ben. I'll have a longer reply for you once I get back. |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Sun Oct 14, 2007 7:31 pm Post subject: |
|
|
| johnsfine wrote: | | It may be necessary to hold long enough to avoid interruption if you miss an IR packet. I'm not sure. Even just long enough to get the next packet if none are dropped may make the system feel sluggish. I found your request for a faster protocol very convincing. |
Yes... I'm going to have to create one myself, though, because even that Nokia has a 100ms repeat time.
All things in due course... I'll get my NEC protocol working and then improve the system (and replace the TSOP IR demodulator).
Do you happen to know how many packets typically make it to an IR receiver?
EDIT: I'm looking over the documentation for Protocol Builder now, but I didn't see anything pertaining to adjusting the actual repeating period. Is the repeat time for PB-built protocols dependant on the total number of time units? |
|
| Back to top |
|
|
The Others
Joined: 14 Oct 2007
Posts: 6
Location: Montreal,Qc
|
| Posted: Sun Oct 14, 2007 7:52 pm Post subject: |
|
|
I redid my matrix to respect left to right ( 1 to 4) and top to bottom (A to O) of the remote. And also used test point numbering as on the PCB.
I was unable to see the first picture you post. But the second post is clear on the way it works.
A1 : TP01+TP09 : EJECT
A2 : TP01+TP10 : 1
A3 : TP01+TP11 : 2
A4 : TP01+TP12 : 3
B1 : TP01+TP13 : AUDIO
B2 : TP02+TP09 : 4
B3 : TP02+TP10 : 5
B4 : TP02+TP11 : 6
C1 : TP02+TP12 : ANGLE
C2 : TP02+TP13 : 7
C3 : TP03+TP09 : 8
C4 : TP03+TP10 : 9
D1 : TP03+TP11 : SUBTITLE
D2 : TP03+TP12 : CLEAR
D3 : TP03+TP13 : 0
D4 : TP04+TP09 : TIME
E1 : TP04+TP10 : RED
E2 : TP04+TP11 : GREEN
E3 : TP04+TP12 : BLUE
E4 : TP04+TP13 : YELLOW
F1 : TP05+TP09 : DISPLAY
F2 : TP05+TP10 : TOP MENU
F3 : TP05+TP11 : POP UP/MENU
F4 : TP05+TP12 : RETURN
G1 : TP01+TP14 : OPTIONS(GREEN TRIANGLE)
G2 : TP01+TP22 : UP ARROW
G3 : TP02+TP15 : BACK(RED CIRCLE)
H1 : TP02+TP23 : LEFT ARROW
H2 : TP03+TP16 : ENTER
H3 : TP03+TP24 : RIGHT ARROW
I1 : TP04+TP17 : VIEW(RED SQUARE)
I2 : TP04+TP25 : DOWN ARROW
I3 : TP05+TP18 : BLUE CROSS
J1 : TP05+TP26 : L1
J2 : TP06+TP19 : PlayStation
J3 : TP06+TP27 : R1
K1 : TP07+TP20 : L2
K2 : TP07+TP28 : R2
L1 : TP06+TP11 : L3
L2 : TP07+TP12 : SELECT
L3 : TP08+TP21 : START
L4 : TP08+TP13 : R3
M1 : TP05+TP13 : SCAN LEFT
M2 : TP06+TP09 : PLAY
M3 : TP06+TP10 : SCAN RIGHT
N1 : TP06+TP12 : NEXT LEFT
N2 : TP06+TP13 : STOP
N3 : TP07+TP09 : NEXT RIGHT
O1 : TP07+TP10 : SLOW/STEP LEFT
O2 : TP07+TP11 : PAUSE
O3 : TP07+TP13 : SLOW/STEP RIGHT
TP01 : A1,A2,A3,A4,B1,G1,G2
TP02 : B2,B3,B4,C1,C2,G3,H1
TP03 : C3,C4,D1,D2,D3,H2,H3
TP04 : D4,E1,E2,E3,E4,I1,I2
TP05 : F1,F2,F3,F4,I3,J1,M1
TP06 : J2,J3,L1,M2,M3,N1,N2
TP07 : K1,K2,L2,N3,O1,O2,O3
TP08 : L3,L4
TP09 : A1,B2,C3,D4,F1,M2,N3
TP10 : A2,B3,C4,E1,F2,M3,O1
TP11 : A3,B4,D1,E2,F3,L1,O2
TP12 : A4,C1,D2,E3,F4,L2,N1
TP13 : B1,C2,D3,E4,L4,M1,N2,O3
TP14 : G1
TP15 : G3
TP16 : H2
TP17 : I1
TP18 : I3
TP19 : J2
TP20 : K1
TP21 : L3
TP22 : G2
TP23 : H1
TP24 : H3
TP25 : I2
TP26 : J1
TP27 : J3
TP28 : K2 |
|
| Back to top |
|
|
The Others
Joined: 14 Oct 2007
Posts: 6
Location: Montreal,Qc
|
| Posted: Sun Oct 14, 2007 8:04 pm Post subject: |
|
|
Hi Johnsfine & IBNobody,
I'm sorry if I jump in your thread like that. I was so happy to see somebody else is/are trying to achieve the same thing. And I couldn't resist. For months I'm searching for a commercial solution.
I'll do my class and properly follow the thread since the beginning. I also already clarify myself which regards the matrix vs the test point that IBNobody was refering to.
In fact, if you guys come up with the solution I would obviously jump on it to save me time. I'm ready to offer $$ for that  .
Ben |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Sun Oct 14, 2007 10:29 pm Post subject: |
|
|
Ben,
I'll keep your offer in mind. Financial cost splitting might be worth it because I plan on spinning the PCB. (The PLDs I use don't come in anything other than fine pitch SMT.)
On a brighter note, it seems that most of the money would be going into the PCB. Altera's cheapest, slowest MAX II chips can be had for $6 at digikey.
I'll release my code once I merge my burst routine with my switch routine. It's written in AHDL, Altera's very basic hardware definition language.
(I chose AHDL because I don't know VHDL, and Altera's tools give me fits when I try and write in Verilog. Plus, Altera's fitter converts VHDL and Verilog into AHDL to build the logic equations.) |
|
| Back to top |
|
|
The Others
Joined: 14 Oct 2007
Posts: 6
Location: Montreal,Qc
|
| Posted: Mon Oct 15, 2007 9:45 am Post subject: |
|
|
Hi IBNobody,
I'll probably use ATtiny24 in a 14-SOIC package to do the job:
http://atmel.com/dyn/resources/prod_documents/8006S.pdf
1.91$/ea at digikey.com
8 pins from PortA to simulate the scan/sense protocol. 1 pin on PortB for the IR in.
This very small package can be glued somewhere on the PCB of the original remote and have the 8+1 wires easily routed to it.
At this moment I believe we just needs TP01 to TP08 (the sense lines) to do the whole interface. I don't think we need to touch TP09 to TP28. By properly using internal timers of the ATtiny24 we can emulate what TP01 to TP08 + TP09 to TP28 are doing.
If this works:
- the modification cost will very low.
- very low power usage (100nA in power down)
- Keyboard can still be used
- All logic will fit the original case
- Quick to modify a remote
- No PCB to do
I'll still use the Atmel Butterfly proto board to do the prototyping because it can be easily interface to a PC via RS-232.
Ben |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Mon Oct 15, 2007 10:02 am Post subject: |
|
|
| The Others wrote: | | At this moment I believe we just needs TP01 to TP08 (the sense lines) to do the whole interface. I don't think we need to touch TP09 to TP28. By properly using internal timers of the ATtiny24 we can emulate what TP01 to TP08 + TP09 to TP28 are doing. |
Interesting idea. I don't think you'd have much margin for error on the timing.
What would your ATtiny24 use as a time reference? How thermally stable is that time reference?
What does the BT remote's main chip use as a time reference? How thermally stable is it? Is it available on a test point, so you could use the same clock? |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Mon Oct 15, 2007 10:03 am Post subject: |
|
|
You'll need at least one of the scan lines as an input to sync your timers. Otherwise, you wouldn't know when to pull the sense lines low.
Other than that, it shouldn't be too hard. I'd recommend adding an LED into the system to indicate if a button is being pressed.
As far as packaging goes... I was just going to take the BDRM mainboard, put it in a project box, and feed everything from a 3.3v wall-wart. My rationale for this (i.e. why I'm not cramming everything into the original remote) was that I didn't want my toddler to walk off with the IR receiver remote. If the thing's plugged in and doesn't look like a remote, I'd have less of a chance of that happening. |
|
| 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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
