Synchronization for serial IR communication

[Maltaeron]

I have a setup with a controlling board and a receiving one. The infrared sending and receiving works fine, however I am having trouble keeping them synchronized.

The controller sends "packets" of data each at 18 bits, the first 12 being a signature and the following six the desired command to execute.
It does not matter if the occasional packet is lost.

Synchronization is thus left up to the receiver which tries to do this with two main parts:

• A timer which calls my "addBit" method at my predetermined frequency
• And a main code, which looks for an IR change and resets the timer to it

At present, all that is happening is that addBit is called only when changes are not occurring.

I have no clue why, and have practically burst my head trying to figure it out...

[Admin]

At present, all that is happening is that addBit is called only when changes are not occurring.

Can you show us the code that basically says:
if signal received
   addbit

Perhaps its false triggering on noise? Put up an oscope on the received signal early in the circuit, but also on the UART line as well to see if noise is transmitted when it shouldn't be.

Also, try a lower baud rate.

[Maltaeron]

Meh, I just killed the sync thing and now it works fine, since both receiver and transmitter are using the same crystal(same product), I trust neither to wander faster or slower than the other.

[superchiku]

HEY MAN I WAS WONDERING HOW DO U SETUP A SERIAL IR COMMUNICATION IN USART ?

ITS COOL COZ IT MUST BE WIRELESS , CAN U SHARE THE SCHEMATIC?

[Maltaeron]

TYPING IN ALL CAPS CAN GET ANNOYING! 

Its not a real serial interface, and not through usart.
I don't have a schematic, but since the setup is so simple I won't need one to explain it.

I got some infrared leds and an infrared "remote receiver" (http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=1967024)

To represent "on" the mircocontroller modulates the LED on and off at the right frequency for the receiver, (this eliminates ambient light problems).
Off is just plain off.

To receive, the receiver outputs a high signal when it does not detect the modulated on/off signal, and a low signal when it does.
If both receiver and controller agree on a certain frequency for changes, they can have one way wireless control!

For my robot, whenever a command is to be sent, first a 12 bit 'signature' is sent followed immediately by a 6 bit command, when the robot 'sees' the signature, it knows a command is following it.

The main problems with the communications is that the IR LEDs have to be facing the robot's receivers, or communications will not be clear.

[izua]

I've been thinking of making something like this, but with a more complex packet format, and also, intermediate signal "hubs" so I can spread several in my house. This way, wherever the robot will be in a "hub" coverage area, I can see on my computer what its thinking.

But the whole protocol is killer to design, as not to have any signal bouncing. setting a time to live might solve it, though.
anyway, can you post some pseudocode for your project? I'm very interested in this.

are you using two different frequencies to allow full duplex? If not, how do you keep TX and RX from overlapping at one end?

[airman00]

I've been thinking of making something like this, but with a more complex packet format, and also, intermediate signal "hubs" so I can spread several in my house. This way, wherever the robot will be in a "hub" coverage area, I can see on my computer what its thinking.

But the whole protocol is killer to design, as not to have any signal bouncing. setting a time to live might solve it, though.
anyway, can you post some pseudocode for your project? I'm very interested in this.

are you using two different frequencies to allow full duplex? If not, how do you keep TX and RX from overlapping at one end?

just use RF or wifi

[superchiku]

would rf be better than ir , if yes then how do u use rf is serial communication

[izua]

i'd love to, but rf solutions on-a-chip are not so easily available.
there is the nordIC chip, there's CC1000 (both transceivers with digitally selected freq), but both are smd and information on them is sparse.

i've been thinking for a while of breeding my own digital transceiver.
ontopic: hmm, it's not nice to hijack other people's threads.

[Maltaeron]

can you post some pseudocode for your project? I'm very interested in this.

are you using two different frequencies to allow full duplex? If not, how do you keep TX and RX from overlapping at one end?

The whole design is very simple, but is only one-way It might be possible to use different modulation frequencies for each direction, but they would have to be significantly different as to make sure they wouldn't interfere -- My 36khz receiver could pick up 38khz signals --

Also, on the programatical side, you might be hard pressed to modulate it if it gets much higher -- I'm running my atMega168 at its 20mhz max, though if its self correction for 38khz wasn't there I might have been able to run it at a lower speed.

Good Luck Everyone! 

[superchiku]

the transducer and receiver circuit is quite complicated to make and will take up valuable space, not good for robots..

[szhang]

Why not try the Sparkfun RF modules?  They seem to have a pretty simple serial interface and good range as well.