Let's Make Robots!

Four Button IR Remote

Controls four functions on anything you want to control
SwarmiRx.ASM9.5 KB
SwarmiTx.ASM7.87 KB

Four Button IR remote contoller



Four Button IR remote contoller

PIC12F675 Transmitter and 12F683 Receiver

I wanted a way to test steering capability in a new bot I'm working on using pager motors for propulsion. I have seen them used successfully
by other people but to be sure the direction can be contolled reliably I wanted to test them out first before committing a whole design based around them.
The bot in question will be a swarm bot similar to what Lumi is working on here . However as neat as his micro gear motors are I am looking for something smaller and cheaper again.
Due to the weight of the platform or lack of it I should say, trying to test with wire leads I thought would interfere with it's movement so I decided to build a remote control for testing purposes. Apart from experimenting with building my own range sensors with discrete IR parts I hadn't tackled using IR for communications ever.

I don't know if anyone else gets confused as me but whenever a signal is inverted on one end to the other I usually get it wrong the first time.
I downloaded a good pdf on Sony's protocol for IR remotes as it is a popular standard. After capturing the signals from my remotes with the logic analyser built into my pickit 2 I realised I didn't have a sony remote. My TV is a Samsung and I have an el cheapo Teac brand portable.
The signals are completely different being some 33 bits in length. I thought as convenient it would be to use a ready made remote and just interpret the signals for 4 buttons it may be just as simple to build my own. As I'm working in assembler with 8 bits it would be a lot of fuss to interpret 33 bit commands which is more than 4 bytes.

So to keep things simple I decided I'd just use 8 bits for each command. Using the Ascii values for L,R,F and S.(Left,Right,Forward and Stop)
Although this meant I had to build two lots of hardware, a receiver and a transmitter it seemed a better solution for me in this case.
What the receiver looks for is a low pulse of 2300-2500 microseconds duration. I used the capture function on GP2 on the 12F683 to measure the lengths of low pulses received. A 1 equals 1100-1300 microseconds and a zero 500-700 microseconds. This is following the convention of a 2400us start condition and 1200us for a 1 and 600us for a zero. Below you can see the binary representation b'01000110' which is decimal 70 and Ascii for 'F' (Forwards - both motors on).

In the end I'm not sure if I have emulated a cutdown sony signal(maybe some more knowledgeable could tell me) but it works nicely for what I wanted and appears to be error free. I'll include the two assembly files for the pics but please accept that they are just rough working files. There is much duplicate code and redundancies, mixed label naming conventions plus probably a few other bad habits as well. However I have commented the code with the intention of making it clear what is happening.

It's amazing how you can have it working in a simulator and even in a breadboard, you go build it in hardware and it doesn't work or has strange behaviour. Well in my case it was the old inverted signal issue again!!!
To test the code in the simulator I had setup stimulus for a hi signal from button press but forgot to change the code when I built the hardware with buttons switching low. Haha all good fun when the problems are found.
For the purposes of testing I am using a green and red led as representations of left and right motors. Please excuse the incorrect use of Port and Starboard colours.  : D














This Web Page Created with PageBreeze Free Website Builder

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

This should be below your comment from 4:13

I thought about that too. But I do have a benefit that my motors does not have a counterweight ;-)

The Picopter is exactly what I have in mind ;-) Easy and clean build and small enough for travelling. If you carry that little guy you don't need a business card if somebody is asking you "Hey, what are you doing?"


This is a family-ish site. :D

I believe that the first Low/HIGH is the "hey there is a command coming", and, the next 32 HIGH pulses are the command.

I, however, must bow to your ability to swing assembly, even on a PIC.

But that's one more thing under my belt. As our illustrious leader Frits once said and I think I've heard CtC say it as well "the fun is not in thinking you know it all but just how little you do know of what there is to be known"
I might come across as a bit of a pic and assembly fan but the truth is once you've invested as much time into learning a system and a Manufacturers way of delivering information you tend to want to make as much use of it as possible.
I had a foray into Python programming with a Udacity course and it ruined me. I couldn't think straight when I went back to assembly, lol.

It sounds like your using a cutdown Sony protocol the same as I do with the Micro Magician. I ignore the device code and only look at the first 7 bits which is the actual command.

I looked at several different button signals from my tv remote but couldn't decipher the system easily. As you can see in the top picture apart from a long bit pattern, the bits are actually represented by the high state as against low in Sony's IR protocol.
I intend to use this shortened Sony system for communication between swarmbots as well. I'm thinking that I can send multiple bytes to relay information. Similar to the full length Sony signal. If a bot receives an 'M' for message it will know to listen for a second byte containing the message and perhaps a third byte indicating which swarmbot sent it.

Ok, as a former fisherman I will forgive you the red/green messup... :-)

Interesting remote but sorry to tell you, I am more interested in the swarm bot you mentioned ;-)

Like your swarmbot project inspired me. I'm not sure if the pager motors are a good idea yet but the motors you used, while neat, I can only find for about 4 dollars each as against 80 cents each for the pager motors.
I am also wondering how far I can take it with an 8 pin pic and 2k program memory, 128 bytes ram and 256 bytes eeprom, lol.
The cost isn't really a big issue as I've also got most of the materials for a set of 10 larger swarmbots but you had me intrigued so much at your target of 5 dollars a piece so I thought I'd see if I could do it for that price.