 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
Tuer
Joined: 17 Mar 2010
Posts: 18
|
 Posted: Sun Apr 04, 2010 8:30 pm Post subject: |
 |
|
| The Robman wrote: | Do you think you have what you need to move forward now? I don't think you're going to be able to create a single protocol that creates the variety of signals that you need without using some assembler, and as your remote is a JP1.2 remote, that means you'll need to use HCS08 assembler, plus you'll need some understanding of how the IR engine works.
All of that is probably too much for you to learn quickly, so you'll probably need Vicky's help with that. But for her to be able to help you, you'll need to clearly state what you want the signals to look like.
She'll need to know...
a) the carrier frequency
b) the ON and OFF times for the main pair
c) how many different pairs you need |
I think I'm starting to gain an understanding here. Let me recap what I think I understand so that you can point out any inaccuracies in my line of thinking. I also have a few more questions at the end.
http://people.virginia.edu/~cmd8n/IROut.png
This is my end goal; the infrared signal that I want to be able to see with the Wiimote. The real trick here is that the TV remote doesn't generate its signals in terms of IR "OFF" and IR "ON. Instead, it uses protocols in terms of lead-in and out pairs, and logical one and zero pairs. Because of this, getting the explicit IR output I'm looking for isn't very straightforward.
As for constructing a protocol that the remote could understand, I'm pretty sure it's still possible. I don't need to worry about lead-in and lead-out pairs since based on the Protocol-Builder document, the lead-in can be turned off (or set to appear only on the first repetition, which would be fine too). Theoretically, the lead-out would never be seen as I'd want the signal to repeat as long as possible.
One way I think I could make this work is to have different timings for the logical one and logical zero. Referring to my example image above, I could make the "ON" time for the logical one be 400000 uSec and the "OFF" time for the logical one be 50000 uSec. For the logical zero, I could use a "ON" time of 300000 uSec and an "OFF" time of 50000 uSec. Then, I could set button "X" to transmit data of "1111111" and button "Y" to transmit data of "00000000". I think that might get me the signal I'm looking for.
Other questions: how do I go about choosing a carrier frequency? I'm not really sure what the implications of my choice would be. From the above post, it looks like it will affect battery life, but is that all? |
|
| Back to top |
|
 |
cauer29
Joined: 03 Feb 2010
Posts: 236
|
| Posted: Sun Apr 04, 2010 11:38 pm Post subject: |
|
|
| Tuer wrote: |
Other questions: how do I go about choosing a carrier frequency? I'm not really sure what the implications of my choice would be. From the above post, it looks like it will affect battery life, but is that all? |
I don't think it's going to matter what frequency you use. Typical IR remote protocols use frequencies between 36-40KHz. The wii IR array is not going to see the flickering at that frequency. It will just see the overall integrated on time during one sample frame of the array. It'll probably work, but it's way ugly from an engineering esthetic standpoint.
As for the battery life you mentioned, it probably will run the batteries down in 5 minutes of continuous transmission. To make this work long term, you probably should install resistors in series with the IR leds to knock the current down to something more conducive.
A.A. |
|
| Back to top |
|
|
Tuer
Joined: 17 Mar 2010
Posts: 18
|
| Posted: Mon Apr 05, 2010 12:48 am Post subject: |
|
|
| cauer29 wrote: | | Tuer wrote: |
Other questions: how do I go about choosing a carrier frequency? I'm not really sure what the implications of my choice would be. From the above post, it looks like it will affect battery life, but is that all? |
I don't think it's going to matter what frequency you use. Typical IR remote protocols use frequencies between 36-40KHz. The wii IR array is not going to see the flickering at that frequency. It will just see the overall integrated on time during one sample frame of the array. It'll probably work, but it's way ugly from an engineering esthetic standpoint.
As for the battery life you mentioned, it probably will run the batteries down in 5 minutes of continuous transmission. To make this work long term, you probably should install resistors in series with the IR leds to knock the current down to something more conducive.
A.A. |
For me, there is no long term, just as long as it lasts long enough for me to write a paper and film a demo. 
I'm a little confused by what you are saying regarding the flickering at that carrier frequency. Are you saying that the protocol will transmit too fast for the Wiimote to pick up meaningfully? If not, why would it be ugly from an engineering aesthetic? Not trying to rag on you at all, just curious what you mean. |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Mon Apr 05, 2010 6:08 am Post subject: |
|
|
Tuer if you really want a "simple" sequence to run your test on, I'd suggest an 8 bit binary code.
This would be easy to build in PB and easy for you to manipulate to find something you could see.
Typically you have an off time before you repeat the message,
For this you'd just need a
zero value
time on, time off
one value
time on, time off
a lead-out time
11111111_______11111111______........
11011011_______11011011______........
A leadout time between the repeated message just allows you to know where the message begins. So if you are interested in more than 2 numbers, I'd recommend including a lead-out time in your protocol..
This would be easy to create and you could do it yourself. Your original version of a "simple protocol" would be difficult to create requiring quite a bit of assembly language and a thorough understanding of the IR engine, however with binary you simply plug in the values in IR.
Edit, Since this won't be going anywhere other than to a JP1.2 remote, I should add that on these remotes a Quad protocol with 1 on time and 4 different off times requires only a small amount of assembly code. But from the first post where you were using numbers like 7 and 8, I didn't go there, I jumped imediately to the complexity of the XMP signal, which is very difficult to generate, and then added to that complexity because you said you wanted different On times, or am I mistaken there?
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
cauer29
Joined: 03 Feb 2010
Posts: 236
|
| Posted: Mon Apr 05, 2010 10:03 am Post subject: |
|
|
| Tuer wrote: |
For me, there is no long term, just as long as it lasts long enough for me to write a paper and film a demo.
I'm a little confused by what you are saying regarding the flickering at that carrier frequency. Are you saying that the protocol will transmit too fast for the Wiimote to pick up meaningfully? If not, why would it be ugly from an engineering aesthetic? Not trying to rag on you at all, just curious what you mean. |
What I meant by the wiimote won't see the flickering, is that the individual elements of the IR sensor array will not respond fast enough to see that the IR is turning on and off, but rather it will simply respond to the sum total of the "on" time during one frame sample. It'll work fine in that regard. It won't notice the "off" time between the carrier pulses.
Since I don't know actually what the overall goal is here, it's hard to comment on why this scheme is aesthetically limited to me as an engineer of 30 years. I suppose if the goal is to get a signal from an IR source into a computer is required, I see many much simpler methods to that end. There are numerous IR receivers that connect to computers via USB that would completely bypass any need for Wiimotes or other Bluetooth devices. Assuming that there is a hard requirement for Bluetooth, even if it's just a fashion requirement, then I think I'd have explored any of the PS3 IR to Bluetooth convertors out there, as they're designed to receive IR button presses and translate those to Bluetooth, sending them to the PS3, effictively mimicking the PS3's Bluetooth remote. Using the Wiimote to receive a custom IR protocol and relaying to PC via Bluetooth and then decoding that by custom video frame analysis software......is aesthetically displeasing. It's not in the "fingernails on the chalkboard" class, but still....
A.A. |
|
| Back to top |
|
|
Tuer
Joined: 17 Mar 2010
Posts: 18
|
| Posted: Mon Apr 05, 2010 1:14 pm Post subject: |
|
|
| vickyg2003 wrote: | Tuer if you really want a "simple" sequence to run your test on, I'd suggest an 8 bit binary code.
This would be easy to build in PB and easy for you to manipulate to find something you could see.
Typically you have an off time before you repeat the message,
For this you'd just need a
zero value
time on, time off
one value
time on, time off
a lead-out time
11111111_______11111111______........
11011011_______11011011______........
A leadout time between the repeated message just allows you to know where the message begins. So if you are interested in more than 2 numbers, I'd recommend including a lead-out time in your protocol..
This would be easy to create and you could do it yourself. Your original version of a "simple protocol" would be difficult to create requiring quite a bit of assembly language and a thorough understanding of the IR engine, however with binary you simply plug in the values in IR.
Edit, Since this won't be going anywhere other than to a JP1.2 remote, I should add that on these remotes a Quad protocol with 1 on time and 4 different off times requires only a small amount of assembly code. But from the first post where you were using numbers like 7 and 8, I didn't go there, I jumped imediately to the complexity of the XMP signal, which is very difficult to generate, and then added to that complexity because you said you wanted different On times, or am I mistaken there? |
I think I understand what you're saying here. How do I get started putting this together? |
|
| Back to top |
|
|
Tuer
Joined: 17 Mar 2010
Posts: 18
|
| Posted: Mon Apr 05, 2010 1:42 pm Post subject: |
|
|
| cauer29 wrote: | | I suppose if the goal is to get a signal from an IR source into a computer is required, I see many much simpler methods to that end. |
So here's where our misunderstanding lies. The whole reason I'd like to do something like this is to create distinctly identifiable Wii sensor bars. For example, the normal Wii sensor bar gives a permanent "ON" signal. The problem here is that since every sensor bar emits the exact same signal, it's impossible to distinguish between multiple bars. While no games for the Wii use multiple sensor bars as far as I know, if I wanted to use the Wiimote technology in some more customized application with multiple sensor bars, it might be nice to be able to identify which sensor bar a Wiimote was looking at. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Mon Apr 05, 2010 2:22 pm Post subject: |
|
|
How many different "buttons" do you want to be able to support? If two is all you need (ie, the 400ms time and the 300ms time), then this will be easy. If you need a lot more than that, it can be done but it would require assembler.
Also, it sounds like you'd be better of not using a carrier frequency at all, which you're allowed to do.
_________________
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 |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Mon Apr 05, 2010 2:43 pm Post subject: |
|
|
| The Robman wrote: | | Also, it sounds like you'd be better of not using a carrier frequency at all, which you're allowed to do. |
I'd still suggest using a carrier. If you have the IR LED turned on that much, it's likely to burn out before the batteries die. In this application, the carrier will serve as more of a "brightness" control (i.e., PWM modulation) and limit the average current in the LED to something it can handle. You can always set the carrier up higher (100 kHz?), so I think the sensor hardware in the wiimote will not "see" it. This way, the duty cycle of the carrier would set the brightness.
_________________
Mike England |
|
| Back to top |
|
|
Tuer
Joined: 17 Mar 2010
Posts: 18
|
| Posted: Mon Apr 05, 2010 3:03 pm Post subject: |
|
|
| The Robman wrote: | How many different "buttons" do you want to be able to support? If two is all you need (ie, the 400ms time and the 300ms time), then this will be easy. If you need a lot more than that, it can be done but it would require assembler.
Also, it sounds like you'd be better of not using a carrier frequency at all, which you're allowed to do. |
Two would be enough for my purposes. |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Mon Apr 05, 2010 5:31 pm Post subject: |
|
|
So these two signals would be enough?
You can adjust the timings and frequency with PB. These two signals are assigned to CH+ and Ch-.
Here is a zip file with the
Protocol Builder and KM files
Good Luck
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
Tuer
Joined: 17 Mar 2010
Posts: 18
|
| Posted: Mon Apr 05, 2010 6:05 pm Post subject: |
|
|
| Thanks a lot! I'll give it a shot and see how it goes. Again, thanks for all your help through this entire process, I wouldn't have been able to make this much progress without you all. |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Mon Apr 05, 2010 7:19 pm Post subject: |
|
|
Tuer, we're happy to help.
| mr_d_p_gumby wrote: | | The Robman wrote: | | Also, it sounds like you'd be better of not using a carrier frequency at all, which you're allowed to do. |
I'd still suggest using a carrier. If you have the IR LED turned on that much, it's likely to burn out before the batteries die. |
That's the truth. When I started exploring the IR Engine, I burned out my 10820's IR emitter in a matter of minutes. 
I've set Tuer's frequency quite high, and I hope that will be okay for his tests.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
cauer29
Joined: 03 Feb 2010
Posts: 236
|
| Posted: Mon Apr 05, 2010 9:07 pm Post subject: |
|
|
| Tuer wrote: | | cauer29 wrote: | | I suppose if the goal is to get a signal from an IR source into a computer is required, I see many much simpler methods to that end. |
So here's where our misunderstanding lies. The whole reason I'd like to do something like this is to create distinctly identifiable Wii sensor bars. For example, the normal Wii sensor bar gives a permanent "ON" signal. The problem here is that since every sensor bar emits the exact same signal, it's impossible to distinguish between multiple bars. While no games for the Wii use multiple sensor bars as far as I know, if I wanted to use the Wiimote technology in some more customized application with multiple sensor bars, it might be nice to be able to identify which sensor bar a Wiimote was looking at. |
Ok, I understand now. I think I would've approached it by building custom sensor bars. I'm thinking something simple like modulating an existing sensor bar at 10hz or 20hz. That'd be fairly trivial to add to the existing sensor bar. Then your video analysis software could easily pick out the difference between 10 hz pulsing and 20 hz pulsing. Using a JP1 remote to create 2 unique patterns, is the pure software method and has the disadvantage of using way more power than needed, even if it does avoid the dirty deed of building/modding hardware.
A.A. |
|
| Back to top |
|
|
Tuer
Joined: 17 Mar 2010
Posts: 18
|
| Posted: Mon Apr 05, 2010 9:18 pm Post subject: |
|
|
| cauer29 wrote: | | Tuer wrote: | | cauer29 wrote: | | I suppose if the goal is to get a signal from an IR source into a computer is required, I see many much simpler methods to that end. |
So here's where our misunderstanding lies. The whole reason I'd like to do something like this is to create distinctly identifiable Wii sensor bars. For example, the normal Wii sensor bar gives a permanent "ON" signal. The problem here is that since every sensor bar emits the exact same signal, it's impossible to distinguish between multiple bars. While no games for the Wii use multiple sensor bars as far as I know, if I wanted to use the Wiimote technology in some more customized application with multiple sensor bars, it might be nice to be able to identify which sensor bar a Wiimote was looking at. |
Ok, I understand now. I think I would've approached it by building custom sensor bars. I'm thinking something simple like modulating an existing sensor bar at 10hz or 20hz. That'd be fairly trivial to add to the existing sensor bar. Then your video analysis software could easily pick out the difference between 10 hz pulsing and 20 hz pulsing. Using a JP1 remote to create 2 unique patterns, is the pure software method and has the disadvantage of using way more power than needed, even if it does avoid the dirty deed of building/modding hardware.
A.A. |
Yeah it's the pure software version, but only because I'm a pure software person  |
|
| 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
