Gadgeteer Serial IR Transmiter

I’ve read the posts by DevHammer on making an IR transmitter and I was wondering if it would be possible to use this (or a development of this) to allow me to send serial data between a Gadgeteer controller and a Fez robot client over IR.

I’ve got students making both ends of a remote controlled robot application and at the moment I’ve had to use a wire to link the serial ports on the controller and the robot. I’d love to be able to use IR to do this instead. From my limited knowledge of these things I reckon that if I use the output pin from a com port to control a 38Khz modulated IR signal I can then just strap the standard IR receiver component (the old school three wire ones) onto the input pin of a com port on the robot.

I realise that if we have 30 or so of these in a lab it will result in lots of crosstalk, but then we can have some fun giving systems station ids and then making a simple network protocol.

But first I need to make the modulator bit to do this. One plan might be to use the Duino Proto board to build up a little circuit that does the trick, but I’d love to know if this is a sensible or silly idea before I start burning my fingers with the soldering iron.

Any thoughts would be most welcome.

First: Wiring up a IR transmitter to the COM port and modulating the signal will not work reliable. IR is very sensitive to sunlight, TL lamps, changing reflections etc. If a person or object moves around, it is possible that the receiver receives spikes that disrupt your serial communication.

Maybe you can get it to work if you implement CRC checksums and “retransmission on failure” functionality.

Next: the IR transmitter and receiver must be in each others view, which limits the robot in its movements.

You might want to look for RF transmission instead. I would prefer something like ZigBee or bluetooth.

If you don’t want to get your hands dirty look for wireless serial link modems like:


(I searched google for: wireless serial link 433)

Thanks for that. I’ve used XBee modules in the past and they work very well, but they are rather expensive and I need 15 pairs, which probably rules out he wireless modems too…

I’m not too concerned about the possibility for errors though, as we can always drop the baud rate, which should help a bit, and it is actually quite useful for students to know that not all communication mediums are completely reliable. It’s a pity that it is a hardware course and not a networking one. The line of sight thing isn’t too much of a problem either, as the lab is quite small and all the walls are white. I think I’ll have a play and see where I end up.

OK, if you go that route all you need is a modulator. You can use the TX to modulate a 38kHz signal generated by a 555. Or if you have a PWM output (f.e. if you are sending from a FEZ or other microcontroller), you can setup the PWM to 38kHz and tie both TX and PWM outputs togetter through an AND gate.

If you’re using a FEZ Spider, you can also use a feature called OutputCompare (part of GHI’s premium libraries) to generate the carrier frequency…that’s what I do with my IR LED Array module, so I only need a single X or Y socket for the module.

Keep in mind that depending on how often you’re sending commands, you may reach a saturation point in terms of running multiple devices. For example, IR helicopters typically offer at most 2-3 channels of operation because beyond that there’s not enough bandwidth to avoid interference, as I understand it.

But while the helis are receiving packets every 200ms or so, you might not need to send as frequently, so you might be able to get away with more channels.

Good luck!

I’m not that fussed about the data rate to be honest, we only send very short commands every now and then. Are you using the serial port on the Gadgeteer device or are you “bit bashing” to get the output waveforms?

My hope is that I can keep as close to the standard serial port as I can. If you are using the standard com port I’d love to have some of your devices to have a play with.

@ devhammer. How did you work out the IR pulse for your IR helicopter? did you get it from a spec sheet?
I’ve been thinking about using your IR module for controlling the shutter on a Nikon DSLR but i need to work out how I’m going to get the IR pulse info.

@ HughB - Sciurus made a snippet that does just that. See

And an other project here: Nikon DSLR IR Remote Project - fizzPOP

1 Like

Doh! i didn’t even think to check codeshare! Many thanks for linking this WouterH it will save me some time. Roll on motion sensor and my nikon :slight_smile:

Neither. I’m using a variant of the code here:

GHI Electronics – Where Hardware Meets Software (see the section entitled “Sending Signal to Control a TV”)

For each interval (for the Syma S107, it’s roughly 200ms), I calculate the desired throttle, pitch, and yaw values and use those to create a buffer of uints containing the timings, and then pass that buffer to the OutputCompare’s SetBlocking function, like so:

Here’s the basic driver code for the IR LED Array (it’s not in Gadgeteer driver form yet, this is just pulled from my IR Commander project for the heli):

using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using GHIElectronics.NETMF.Hardware;
using GT = Gadgeteer;

namespace IRCommander
    class IRLEDArray
        static Cpu.Pin outputPin;
        static OutputCompare IRCommandGenerator;

        public IRLEDArray(int socket)
            outputPin = GT.Socket.GetSocket(socket, false, null, null).CpuPins[5];

            IRCommandGenerator = new OutputCompare(outputPin, true, 68);

        public void SendCommand(uint[] buffer)
            IRCommandGenerator.SetBlocking(true, buffer, 0, buffer.Length, 100, true, 38170);        

Not using serial at all, alas. Just a digital I/O along with OutputCompare.

Looks like you’ve already got what you need for the Nikon, but to answer your question, I found the specs for the Syma S107 protocol on an RC enthusiast forum:

Coaxial IR protocol (SH, Syma, etc...) - Page 5 - RC Groups (the whole thread is worth a read, but the interesting part on the protocol starts on pp5)