PIC to PIC wireless

[atferrari]

A 16F877 sends commands to three independent 16F628, each one PWM controlling the start / stop / reverse and speed of a DC motor or modified servo.

For a wireless link I considered to use an IR diode emitting a common Sony IR code with the instruction (start - stop - reverse or PWM value) and the identification of the motor (for the moment, the three will do all at the same time).

Signal, modulated at 38 KHz decoded by an IR receiver module.

Since the IR diode can not "see" each IR receiver all the time (they move with respect to the diode) I would put two IR recievers per motor, duly ORed. Redundant to ensure that no 16F628 miss a command.

If needed I would use three diodes to "flood" the area and ensure redundancy even more.

Distance diode-receiver: 30 cm maximum.

Decoding by software at each 16F628

-------------------------------------------

By now I don't expect things to get much more complex. To get a direct link to each 16F628, if not wireless I should resort to slip rings. Really costly (which I can not afford) :cry: .


Suggestions / comments anyone :?: I will appreciate that

 

[atferrari]

First step OK!

First step done!

The orders from the bot's brain, sent via an IR link, consist of one start pulse and one 8-bit pack with the MS nybble for device ID and the LS nybble for commands. Te whole coded as per Sony's SIRC protocol.

Fors testing I've set up the 16F628 generating a PWM which after receiving the START order, starts and ramps up to full duty cycle value while the STOP order brings the PWM out pin to 0.
-----------------------------------------------
For the moment, the IR emitting diode is facing the receiver just few mm away.

When the bench lamp light is on, I can see in the scope random pulses reaching the input pin in the 16F628. Up to now I've not detected they had any visible effect like an unexpected START or STOP but... could that happen?

In case you ask, no, I don't have any fluorescent lights around (I hate them!!)

With the windows wide open and daylight flooding the room I can't see any visible pulse.

Comments anyone?
-----------------------------------------------

Next step:

a- error checking routine.

I googled for that and found TOO MUCH (overwhelming) info. Checksum / CRC / majority / ANDing / etc...

Suggestions / comments welcome!!!

And after that:

b- Routines to control direction forward / reverse.

Agustín Tomás

 

[Jay.slovak]

I suppose Checksum is the simpliest way of Error detecting.
On the transciever side, Sum up all bytes (ignore overflows) and save the resulting value into another Byte. Send all bytes to the receiver (including checksum) and let receiver recalculate it's own checksum, then just compare them and you will find out wheater your Bytes arrived correctly. If not, try to resend them...

 

[Joel Rainville]

Would a simple parity bit be acceptable? You would simply add a parity bit every Nth bit (usually every byte, but be creative ) and make sure all N bits + parity bit add up to an even number (or odd number to be even more creative :lol

 

[atferrari]

Too much info...

Spent lot of hours reading and at a certain point "even" and "odd" became the same :shock: :shock:

I will sleep on it and tomorrow will start afresh.

My idea is to repeat every order (START plus 1-byte pack) three times plus whatever is needed for error checking (correction?).

Of course all this could (easily) change. :!:

Will keep you posted.