need Universal Remote code for some other company than Sony
okonisfree
Posts: 38
I have an universal remote. I have it perfectly working with the Boe-Bot with the Sony code. However, I am going into a competition and a lot of other people have there remotes compilant with the Boe-Bot in Sony tv code. I was wondering if someone knew or could make a code that I could put on my Boe-Bot that was for some other company like Samsung or wahatevr. Also I was wondering if My Boe-Bot could block out other infrared remote signals that were not meant for the Bot. I attached my code that I have on my Bot right now.
Post Edited By Moderator (Chris Savage (Parallax)) : 7/26/2006 7:14:45 PM GMT
Post Edited By Moderator (Chris Savage (Parallax)) : 7/26/2006 7:14:45 PM GMT
Comments
Post Edited By Moderator (Chris Savage (Parallax)) : 7/26/2006 7:14:36 PM GMT
Post Edited By Moderator (Chris Savage (Parallax)) : 7/26/2006 7:14:28 PM GMT
Post Edited By Moderator (Chris Savage (Parallax)) : 7/26/2006 7:14:20 PM GMT
So any ir remote is sending pulses of ir light.· You just need to read those pulses.· Try using RCTIME on the pin that your ir sensor is hooked up to.· PULSIN will get you some good info too.· Do a loop that fills an array with the time that the ir pin state was high, follwed by an RCTIME that clocks how long the pin was low.· Run it while pushing a button on your remote.· Look at the array of numbers.· Any repeating patterns?· That's your signal.· Then push another button.· What's different?· Use that difference for control.
It would help if you knew the remote's protocol.· This website has some:
http://www.xs4all.nl/~sbp/knowledge/ir/ir.htm
Good luck.· Post some code.
Post Edited By Moderator (Chris Savage (Parallax)) : 7/26/2006 7:14:11 PM GMT
You are using Select/Case with a variable that is set by your subprogram that reads your remote. So your robot has 10 functions that it will do based on what button is pressed. You can probably keep that same structure with any remote.
I hooked up an ir sensor to pin 4 on my Basic Stamp. I ran this code:
' {$STAMP BS2}
' {$PBASIC 2.5}
goop VAR Word
DO
PULSIN 4, 1, goop
DEBUG DEC goop, CR
LOOP
My debug window started giving me a long column of zeros.
Then I pressed the 'up' button on my remote and the debug window started spewing out numbers. I pressed the pause button on my debug window, scrolled up to where the numbers started (after the zeros) and I wrote down the first 10 numbers.
Then I double checked it by using the same process to see how much the number change. They didn’t change more than one digit.
Then I pressed the resume button on the debug window and shot the ir sensor with the left arrow button, pressed the pause button on the debug window, scrolled up to where the numbers started, wrote down the first 10, and double checked them.
I repeated this process for all the arrow buttons.
Then I compared the number strings. They all started the same. 2207 in my case. That’s different than the sony remotes that all start < 1000. So I could start my get_remote_code subprogram with IF irPulse > 2200 THEN… That way I wouldn’t get hit by the sony’s.
By the fourth number I had strings that were different for each button. So all I would need to do is write IF/THEN statements that discriminate based on this fact. Maybe I would do:
For index = 1 to 4
Pulsin 4, 1, goop
remoteCode = remoteCode + goop
Next
After this loop finishes I would have different numbers for remoteCode and I could Select a Case based on what the number was.
It’s not as clean as what you have going on in your program, but it’s off the top of my head, and to be honest, I’m still not comfortable with bits and bytes and nibbles…
Man, I have spent WAY too much time on this... good luck.
Post Edited By Moderator (Chris Savage (Parallax)) : 7/27/2006 4:13:12 PM GMT
Without going deeply into how IR remotes work (the subject is covered in much greater detail elsewhere), the Sony protocol was picked for very specific reasons...mostly having to do with the speed at which the Stamp runs. Decoding other manufacturer's protocols might be difficult or even impossible using the Stamp alone. If I were you, I would investigate creating my own communication protocol using a second Stamp to generate your own codes. One advantage of this is that if you come up with something good, you could just tack an extra byte on the front of your transmission and instantly be able to control up to 256 devices with no hardware changes. Imagine a battle where everyone has the same kind of remote, but the signals don't get crossed...
Just an idea...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...
The problem with this approach is when you want to control more than one BOE-BOT. Two IR-Remotes are going to 'conflict' with each other, or 'jam' each other (if they both have buttons pushed at the same time), no matter what you do. The Sony protocol is a nice one, relatively simple, and easy for the BOE-Bot to decode. Going to another protocol is not going to solve the 'jamming' issue, though.
Typically, in competitions, RF remotes are used, and each robot is assigned its own RF frequency. Thus they don't 'jam' each other or recieve each other's messages.
The other way to resolve 'jamming' issues is to have your 'sender' send some sync byte, the message bytes, and an 'end' byte. Then when recieved, the Bot first checks for good sync and 'end' bytes before using the message. If garbled, the bot throws away the message and waits for the next message. This assumes you'll send each message multiple times, so even if SOME of your messages are 'jammed' by the other guy, a few will get through.
You can't modify the IR-Remote to do this though. An IR-Remote assumes it's the only one in the room, being used by one person to control your TV.
Hmm. I think the Sony protocol DOES have a 'device code' part in it that says if the device being controlled is a TV, VCR, DVD, or whatever. You could select on your remote to control a DVD, say, and then have the BOE-Bot decode the 'device' byte and only use those with the DVD code. That would then ignore 'TV' commands. You'd still have the 'jamming' issue though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~okonisfree
"When life gives you lemons...
SUCK IT UP!"
lol jk
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~okonisfree
"When life gives you lemons...
SUCK IT UP!"
lol jk
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
~okonisfree
"When life gives you lemons...
SUCK IT UP!"
lol jk
Ok, this is how the Sony code works:
These steps are most likely the same for most remotes, as universal remotes are relatively simple and probably just store the different values for each key in this format, then transmits it.· The only steps that will probably be different for different remotes is the key that each value corresponds with, along with the pauses in the time.· Some remotes are probably slightly different, involving frequencies and non-standard coding systems to transmit their codes, but most remotes are probably similar to Sony.· This is only a theory, though; I'll make another post once I've tested my theory.
Post Edited By Moderator (Chris Savage (Parallax)) : 8/5/2006 1:49:40 AM GMT
the fact is that hes using a BOE with a BS@, alot of the remote signals cannot be cought in time with the BS2, for this reason is why they chose SONY protocol. You might find one or two that will work correctly but i really dunno.