| View previous topic :: View next topic |
| Author |
Message |
IBNobody
Joined: 06 May 2007
Posts: 124
|
 Posted: Mon Oct 15, 2007 1:34 pm Post subject: |
 |
|
John,
Did you see the question I asked a little bit ago about Protocol Builder? I wanted to know how JP1 remotes calculated the repeat time. |
|
| Back to top |
|
 |
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Mon Oct 15, 2007 2:01 pm Post subject: |
|
|
Typically the total frame time is just the sum of all the specified values.
There is an option named "OFF as Total" that changes the meaning of the cell above it in PB. That cell is normally the length of the quiet time at the end of the frame, but can be the total time, including that quiet time, so you can get a consistent repeat rate.
You need to make sure the total is greater than the sum of the previous parts. It will not truncate a frame to fit a too small total.
| IBNobody wrote: | | and replace the TSOP IR demodulator |
So you already have one of the TSOPxx38 parts for NEC? |
|
| Back to top |
|
|
The Others
Joined: 14 Oct 2007
Posts: 6
Location: Montreal,Qc
|
| Posted: Mon Oct 15, 2007 2:36 pm Post subject: |
|
|
| IBNobody wrote: | 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. |
I came to that conclusion early this afternoon.
For the LED, still some IO left. Point noted.
In my case the BD remote stays in a cabinet. The Harmony 880 is the main unit. |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Mon Oct 15, 2007 2:37 pm Post subject: |
|
|
| johnsfine wrote: | | So you already have one of the TSOPxx38 parts for NEC? |
Yes, but I can always swap it out. I will go with a TSOP1756 if I need to change the protocol.
I'm 90% done with the build. Now I just need to debug. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Mon Oct 15, 2007 2:56 pm Post subject: |
|
|
| johnsfine wrote: | | if you chose 56Khz and used a TSOP1156, 2156, or 4156, you could get the same 24 bits into 64% as much time. |
| IBNobody wrote: | | I will go with a TSOP1756 if I need to change the protocol. |
Why the 1756? If I'm reading the spec's right, a 1756 would limit the protocol speed to slower than you could get with one of those other TSOP parts I listed. Are those others not available from your supplier, or they cost more, or what?
A TSOP7000 is significantly more expensive and larger than a TSOPxx56, but it still may be just a small fraction of your project cost and it would allow a protocol far faster than you could get with a TSOPxx56. |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Mon Oct 15, 2007 4:14 pm Post subject: |
|
|
| johnsfine wrote: | | johnsfine wrote: | | if you chose 56Khz and used a TSOP1156, 2156, or 4156, you could get the same 24 bits into 64% as much time. |
| IBNobody wrote: | | I will go with a TSOP1756 if I need to change the protocol. |
Why the 1756? If I'm reading the spec's right, a 1756 would limit the protocol speed to slower than you could get with one of those other TSOP parts I listed. Are those others not available from your supplier, or they cost more, or what?
A TSOP7000 is significantly more expensive and larger than a TSOPxx56, but it still may be just a small fraction of your project cost and it would allow a protocol far faster than you could get with a TSOPxx56. |
I was just moving up the frequency levels, as per your earlier message. But I'm making things so that the IR receiver fits into a screw terminal. (GND/Vs/Out and Out/GND/Vs terminal configurations are supported.) |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Thu Oct 18, 2007 9:52 pm Post subject: |
|
|
Don't rely on the Device.xls sheet for protocol information. It lies! You'll need to hook up your IR receiver to a scope and verify your remote is outputting the correct IR pattern.
One of the NEC patterns I was going to use didn't repeat the pattern. It just sent the pattern once and then sent a pulse.
Also, the TSOP1738 is an active-low device. I forgot to invert my input. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Fri Oct 19, 2007 8:02 am Post subject: |
|
|
| IBNobody wrote: | | Don't rely on the Device.xls sheet for protocol information. It lies! |
Do you have an example? Or did you mean the thing you said below?
| IBNobody wrote: | | One of the NEC patterns I was going to use didn't repeat the pattern. It just sent the pattern once and then sent a pulse. |
That's what we call "NEC1". It is more common than "NEC2". I was initially suggesting that you use NEC2 (before I suggested inventing a new faster protocol).
You can easily find NEC2 setup codes in Devices.xls, or create an NEC2 upgrade. |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Fri Oct 19, 2007 4:31 pm Post subject: |
|
|
You were correct. I didn't realize there was a difference between the two.
A faster protocol isn't needed, it looks like. When we were thinking about this whole thing, we didn't factor in the human finger speed.
After running some tests on my IR-BDRM repeater, I've found that a typical remote press fires off 2-3 packets at a repeat rate of 110ms. My timeout value of 120 ms wasn't long enough to account for an occasional bad packet. I increased it to 230ms.
Everything seems to work, but the real test will be coming soon.
Something odd... I see the scan lines being pulled down all at once and then they are fired one by one. But this is happening even when there's no keypad input. When it cycles, though, it doesn't vary the width of the scan lines.
::shrugs::
Wish me luck! |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Fri Oct 19, 2007 6:49 pm Post subject: |
|
|
It works... Sort of...
I was able to turn on the PS3, but I think I didn't program my Atlas remote correctly. Or maybe I didn't map the buttons right. I get the wrong function.
NEC2 sends the OBC (in hex), and I'm 99% sure I'm getting the right code sent out of the remote.
The other problem I ran into was that 230ms hold time was too long for some buttons. The arrow keys were particularly bad. I may need to add some logic specific to those button presses. I'm okay with not being able to hold an arrow key down.
Here's my code that connects the scan lines to the sense lines. (The sense lines are all open-drain, but you don't see that portion of the code.) I'm going to check it in regards to Ben's.
| Code: | ----------------------------------------------------------------------
-- SCAN LINE SWITCHING
----------------------------------------------------------------------
-- SCAN LINE 1
CASE scan_mux[7..0] IS
WHEN h"01" => sense_out[1] = scan[9]; -- EJECT
WHEN h"02" => sense_out[1] = scan[10]; -- 1
WHEN h"03" => sense_out[1] = scan[11]; -- 2
WHEN h"04" => sense_out[1] = scan[12]; -- 3
WHEN h"05" => sense_out[1] = scan[13]; -- AUDIO
WHEN h"06" => sense_out[1] = scan[14]; -- TRIANGLE
WHEN h"07" => sense_out[1] = scan[22]; -- UP
WHEN OTHERS => sense_out[1] = VCC;
END CASE;
-- SCAN LINE 2
CASE scan_mux[7..0] IS
WHEN h"08" => sense_out[2] = scan[9]; -- 4
WHEN h"09" => sense_out[2] = scan[10]; -- 5
WHEN h"0A" => sense_out[2] = scan[11]; -- 6
WHEN h"0B" => sense_out[2] = scan[12]; -- ANGLE
WHEN h"0C" => sense_out[2] = scan[13]; -- 7
WHEN h"0D" => sense_out[2] = scan[15]; -- CIRCLE
WHEN h"0E" => sense_out[2] = scan[23]; -- LEFT
WHEN OTHERS => sense_out[2] = VCC;
END CASE;
-- SCAN LINE 3
CASE scan_mux[7..0] IS
WHEN h"0F" => sense_out[3] = scan[9]; -- 8
WHEN h"10" => sense_out[3] = scan[10]; -- 9
WHEN h"11" => sense_out[3] = scan[11]; -- SUB
WHEN h"12" => sense_out[3] = scan[12]; -- CLEAR
WHEN h"13" => sense_out[3] = scan[13]; -- 0
WHEN h"14" => sense_out[3] = scan[16]; -- ENTER
WHEN h"15" => sense_out[3] = scan[24]; -- RIGHT
WHEN OTHERS => sense_out[3] = VCC;
END CASE;
-- SCAN LINE 4
CASE scan_mux[7..0] IS
WHEN h"16" => sense_out[4] = scan[9]; -- TIME
WHEN h"17" => sense_out[4] = scan[10]; -- RED
WHEN h"18" => sense_out[4] = scan[11]; -- GREEN
WHEN h"19" => sense_out[4] = scan[12]; -- BLUE
WHEN h"1A" => sense_out[4] = scan[13]; -- YELLOW
WHEN h"1B" => sense_out[4] = scan[17]; -- SQUARE
WHEN h"1C" => sense_out[4] = scan[25]; -- DOWN
WHEN OTHERS => sense_out[4] = VCC;
END CASE;
-- SCAN LINE 5
CASE scan_mux[7..0] IS
WHEN h"1D" => sense_out[5] = scan[9]; -- DISPLAY
WHEN h"1E" => sense_out[5] = scan[10]; -- TOP MENU
WHEN h"1F" => sense_out[5] = scan[11]; -- POP MENU
WHEN h"20" => sense_out[5] = scan[12]; -- RETURN
WHEN h"21" => sense_out[5] = scan[13]; -- REV
WHEN h"22" => sense_out[5] = scan[18]; -- X
WHEN h"23" => sense_out[5] = scan[26]; -- L1
WHEN OTHERS => sense_out[5] = VCC;
END CASE;
-- SCAN LINE 6
CASE scan_mux[7..0] IS
WHEN h"24" => sense_out[6] = scan[9]; -- PLAY
WHEN h"25" => sense_out[6] = scan[10]; -- FWD
WHEN h"26" => sense_out[6] = scan[11]; -- L3
WHEN h"27" => sense_out[6] = scan[12]; -- SKIP REV
WHEN h"28" => sense_out[6] = scan[13]; -- STOP
WHEN h"29" => sense_out[6] = scan[19]; -- PS
WHEN h"2A" => sense_out[6] = scan[27]; -- R1
WHEN OTHERS => sense_out[6] = VCC;
END CASE;
-- SCAN LINE 7
CASE scan_mux[7..0] IS
WHEN h"2B" => sense_out[7] = scan[9]; -- SKIP FWD
WHEN h"2C" => sense_out[7] = scan[10]; -- STEP REV
WHEN h"2D" => sense_out[7] = scan[11]; -- PAUSE
WHEN h"2E" => sense_out[7] = scan[12]; -- SELECT
WHEN h"2F" => sense_out[7] = scan[13]; -- STEP FWD
WHEN h"30" => sense_out[7] = scan[20]; -- L2
WHEN h"31" => sense_out[7] = scan[28]; -- R2
WHEN OTHERS => sense_out[7] = VCC;
END CASE;
-- SCAN LINE 8
CASE scan_mux[7..0] IS
WHEN h"32" => sense_out[8] = scan[13]; -- R3
WHEN h"33" => sense_out[8] = scan[21]; -- START
WHEN OTHERS => sense_out[8] = VCC;
END CASE;
|
|
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Fri Oct 19, 2007 7:36 pm Post subject: |
|
|
I can't tell if you're asking a question or just telling us the status.
I don't think there is enough info here for me to make a decent guess why you get the wrong functions.
I think you need to record a few samples of which function you tried vs. which you got. Then look for a pattern in the function numbers or scan numbers or sense numbers. |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Fri Oct 19, 2007 9:18 pm Post subject: |
|
|
It was just a status update.
I want to sincerely thank you for all the questions you answered for me, though. I appreciated it. |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Fri Oct 19, 2007 11:31 pm Post subject: |
|
|
It works! It works! Yay!
The remote button problem was my fault. My device upgrade was for cable, but I changed it in IR to DVD. The buttons got scrambled.
The IR remote works, but there's that direction button caveat I mentioned before.
The PS3 "crossbar" main menu navigation system is too sensitive. A single button press may cause the cursor to move 2 or 3 icons over rather than 1. I'm holding down my directional buttons too long. In a BR movie, it's not an issue. One keypress moved the selection over 1 "unit" and not 2 or 3.
I have a solution for this, but it will need to wait 'till Monday to try out. I'm going to add in logic between the IR decoder and the button-pusher modules that will intercept the d-button codes. These codes will cause the system to pulse the d-button once and then keep the buttons idle. All other codes will cause their buttons to be held as usual for 230ms. |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Mon Oct 22, 2007 8:03 pm Post subject: |
|
|
The keypad fix works okay, but it still feels a little rough if I'm trying to rapidly scroll through menus. I think the next programming step is to switch protocols.
As far as hardware goes, I'm going to buy a case and a low-amp fuse next. My daughter has already grabbed the board and taken it out of its ESD safe home. It has a limited lifespan until I get it covered. |
|
| Back to top |
|
|
The Others
Joined: 14 Oct 2007
Posts: 6
Location: Montreal,Qc
|
| Posted: Sat Nov 10, 2007 7:12 pm Post subject: |
|
|
Hi Guys,
After a week of fine tuning mine is also working great. No issue so far. Currently in QA. Wife and kids are using the IR remote to control the PS3. Power Off and Power On also under control. I paid big attention to power management and the 2xAA are driving the original BD remote logic + the extra logic used to emulate key press. I'm now planning on doing a full production PCB and maybe find few customers for it. I'll see. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
