hi all,

doctor request from us to transmit the data between two pics wirelessly .
he don't need to use Rf to do that ,he suggest to use optical way like using LED .

can we do that ?
if yes,how?

thanks in advanced

 

Sure.
Use an IR receiver that incorporates filtering, demodulation and AGC.
Drive the IR LED at a compatible frequency, switching it on and off in bursts that correspond to the data bits. The attached datasheet is an example. The IR receiver detects IR light modulated at 38KHz and filtering to reject ambient light. When it sees the 38KHz light from the LED, the output switches.

I have used this technique to send async data from a PIC UART and PWM. Drive the anode of the LED with the hardware PWM at 38KHz 50% duty cycle and drive the cathode with the UART TX output. The 38KHz bursts will be emitted as async UART bits. The receiver is connected to the RX UART pin of the other PIC. It sees the bursts and recovers the baseband async.

You should be able to get 2400 baud without too much trouble. Pick a higher modulation frequency and pay attention to the burst timings in the datasheet and you can go faster. The one I did was 4800 baud and rock-solid.

Good luck!

Mouser has a list of IR receivers.
http://www.mouser.com/search/refine.aspx?N=11326342

 

Sure.
Use an IR receiver that incorporates filtering, demodulation and AGC.
Drive the IR LED at a compatible frequency, switching it on and off in bursts that correspond to the data bits. The attached datasheet is an example. The IR receiver detects IR light modulated at 38KHz and filtering to reject ambient light. When it sees the 38KHz light from the LED, the output switches.

I have used this technique to send async data from a PIC UART and PWM. Drive the anode of the LED with the hardware PWM at 38KHz 50% duty cycle and drive the cathode with the UART TX output. The 38KHz bursts will be emitted as async UART bits. The receiver is connected to the RX UART pin of the other PIC. It sees the bursts and recovers the baseband async.

You should be able to get 2400 baud without too much trouble. Pick a higher modulation frequency and pay attention to the burst timings in the datasheet and you can go faster. The one I did was 4800 baud and rock-solid.

Good luck!

Mouser has a list of IR receivers.
http://www.mouser.com/search/refine.aspx?N=11326342

thanks alot for your appreciated effort

could you explain more the lines in red color
do u mean i cant use baud rate greater than 2400 ?

regards

 

Sure!
EDIT: Maybe... discussion follows:

If you look at the table in the datasheet on page 5 you see that for the TSOP532.. you need a minimum of 10 cycles per burst. Think of that as the bit time of your async comms. At 4800 baud, 1 bit time is 1/4800 ~= 208uS per bit. Consider the case where you are sending 55h (alternating 1's and 0's). Each bit is 208uS.
At 38KHz, the 10 cycle minimum requires (1/38000)*10 = 263us.

This result is actually a problem since the IR receiver (TSOP53238 see page 1) needs 263uS of signal minimum (the 10cycle burst) but at 4800 baud, the minimum bit time is only 208uS. When I first posted I didn't do the calculation. So what do do?

If you slow down the baud rate to 2400, the minimum bit time is 416uS. At 38KHz, that is about 15 cycles in the burst so that part works..

To get to 4800 baud, you could go to a 56KHz receiver (TSOP53256). Then the 10 cycle min. burst is (1/56000)*10 ~= 178uS. The 208 uS min bit time at 4800 baud is satisfied.

Next, consider the maximum burst length. According to pp5, it is 70 cycles (to keep recovery time low). Unfortunately, that is less than 1 character's worth of bits at 4800baud. For example, transmitting 00h is 8 bits of burst. That is about 93 cycles, more than 70, so you have to allow more time between characters. (>4X the burst length).

All of this is for this particular device that I picked at random for you.. You can use as is or search for one that is spec'd with a longer total burst. I went back through my old stuff and think I used a TSOP1156 but don't know if it is still available. Of note is the minimum 6 cycle burst (not 10) with a max 0f 70 for fast recovery. That is 11.6 bits, more than enough and is why my original arithmetic went off the rails

So.... Find something like that if you can.
Sorry this was rambling. I should think before I type.. but it is valid stuff and served to remind me that what I used as an example was not necessarily the best choice.

Good luck!

EDIT: Looking around, what I used was equivalent to a TSOP53156 (datasheet attached) This receiver is categorized as an AGC1 class. It is faster than the other one but it seems that the AGC1's have been superseded by AGC2 (the original one I picked) and higher for more noise rejection. Unfortunately, while the AGC1's are still made, I found none in stock anywhere. You may have better luck. You probably can use an AGC2 (TSOP53256) with the understanding that there is some delay between characters, get lucky and find an AGC1 or try something else altogether.

Datasheet and more info attached.

 

Jackpot!
TSOP31156 has same specs and is in stock at Mouser and hopefully where you are.
It will do 4800 baud. Use a 950nm LED.
http://www.mouser.com/ProductDetail/Vishay/TSOP31156/?qs=/ha2pyFadugdmp0sIcwZdK8zbGbkicOWJm74vPmtcMY=

Datasheet attached.

Let us know what you decide.
Good luck!

 

is this one or two way connection? what range? did you consider IRDA?
for example: TFBS4711-TT1

 

Sure!
EDIT: Maybe... discussion follows:

If you look at the table in the datasheet on page 5 you see that for the TSOP532.. you need a minimum of 10 cycles per burst. Think of that as the bit time of your async comms. At 4800 baud, 1 bit time is 1/4800 ~= 208uS per bit. Consider the case where you are sending 55h (alternating 1's and 0's). Each bit is 208uS.
At 38KHz, the 10 cycle minimum requires (1/38000)*10 = 263us.

This result is actually a problem since the IR receiver (TSOP53238 see page 1) needs 263uS of signal minimum (the 10cycle burst) but at 4800 baud, the minimum bit time is only 208uS. When I first posted I didn't do the calculation. So what do do?

If you slow down the baud rate to 2400, the minimum bit time is 416uS. At 38KHz, that is about 15 cycles in the burst so that part works..

To get to 4800 baud, you could go to a 56KHz receiver (TSOP53256). Then the 10 cycle min. burst is (1/56000)*10 ~= 178uS. The 208 uS min bit time at 4800 baud is satisfied.

Next, consider the maximum burst length. According to pp5, it is 70 cycles (to keep recovery time low). Unfortunately, that is less than 1 character's worth of bits at 4800baud. For example, transmitting 00h is 8 bits of burst. That is about 93 cycles, more than 70, so you have to allow more time between characters. (>4X the burst length).

All of this is for this particular device that I picked at random for you.. You can use as is or search for one that is spec'd with a longer total burst. I went back through my old stuff and think I used a TSOP1156 but don't know if it is still available. Of note is the minimum 6 cycle burst (not 10) with a max 0f 70 for fast recovery. That is 11.6 bits, more than enough and is why my original arithmetic went off the rails

So.... Find something like that if you can.
Sorry this was rambling. I should think before I type.. but it is valid stuff and served to remind me that what I used as an example was not necessarily the best choice.

Good luck!

EDIT: Looking around, what I used was equivalent to a TSOP53156 (datasheet attached) This receiver is categorized as an AGC1 class. It is faster than the other one but it seems that the AGC1's have been superseded by AGC2 (the original one I picked) and higher for more noise rejection. Unfortunately, while the AGC1's are still made, I found none in stock anywhere. You may have better luck. You probably can use an AGC2 (TSOP53256) with the understanding that there is some delay between characters, get lucky and find an AGC1 or try something else altogether.

Datasheet and more info attached.

thaaank you for your appreciated effort

i will try what i understood and then tell you about the result

can i transmit the data using this method over a range greater than 50cm ?

^_^

 

is this one or two way connection? what range? did you consider IRDA?
for example: TFBS4711-TT1

for my project one way connection ..
the range >50cm
the TFBS4711-TT1 is a great device but may be i cant find it in my country
and the project should be submitted within this week

thanks for your effort ^_^

 

Hola John,

Not intending to derail this thread: the OP now mentions a distance >50 cm, so could you briefly elaborate on how to roughly estimate a "safe" maximum?

 

Hola John,
Not intending to derail this thread: the OP now mentions a distance >50 cm, so could you briefly elaborate on how to roughly estimate a "safe" maximum?

Howdy back! It's a good question and remarkably complex if you drill down. But thanks to those busy and talented engineers at Vishay, I don't have to type so much. Here are some ap-notes from the project archives that answer most of that.

The application was a handheld data collector that dumped stored data to a receiver usually around a meter away but it worked over several meters. Data was sent in numbered-sequential packets with CRC. The receiver used the packet numbers and CRC to reassemble and validate the dataset and beeped when it got it all. The handheld sent the dataset repeatedly as long as the SEND button was pressed so the operator just hit SEND until he heard the beep.
For reference, the prototype LED was a 5mm TSAL6100, described in the ap-note. The production unit used a smaller/cheaper 3mm Everlight EL-IR204-A which is actually a 940nm unit but it worked fine. LED current was about 3ma. From those numbers you can look up beam angle, intensity, etc. if you are interested, and compare with the minimum irradiance spec for the receiver. I did all that and found that we had plenty of light so carried on from there.

FWIW, we did consider IrDa but it was much more expensive and the protocols more complex. It IS a great IR link though..

Have a good one!

 

Howdy back! It's a good question and remarkably complex if you drill down. But thanks to those busy and talented engineers at Vishay, I don't have to type so much. Here are some ap-notes from the project archives that answer most of that.

The application was a handheld data collector that dumped stored data to a receiver usually around a meter away but it worked over several meters. Data was sent in numbered-sequential packets with CRC. The receiver used the packet numbers and CRC to reassemble and validate the dataset and beeped when it got it all. The handheld sent the dataset repeatedly as long as the SEND button was pressed so the operator just hit SEND until he heard the beep.
For reference, the prototype LED was a 5mm TSAL6100, described in the ap-note. The production unit used a smaller/cheaper 3mm Everlight EL-IR204-A which is actually a 940nm unit but it worked fine. LED current was about 3ma. From those numbers you can look up beam angle, intensity, etc. if you are interested, and compare with the minimum irradiance spec for the receiver. I did all that and found that we had plenty of light so carried on from there.

FWIW, we did consider IrDa but it was much more expensive and the protocols more complex. It IS a great IR link though..

Have a good one!

Short, good data and to the point as usual. Gracias John.

 

Locked temporarily pending clarification of member status.

EDIT:
New member was using 2 names and will continue as Layan_AK. This thread addresses the same basic problem as this one:
https://forum.allaboutcircuits.com/...-mcu-using-a-led-and-photo-transistor.134796/
but with different approaches that warrant keeping both to avoid confusion.