pic to pic ir link versus wired link : help please anyone

i have connected two pic16f690 via one pin.
"sender" pic's pin rc5 is outputing a signal in pwm at 40 khz at a 30% duty cycle to "receiver" pic pin ra0.

the pic output on rc5 is connected to a bc182l npn transistor via a 4.7k resistor while the receiver pic pin ra0 is connected to the transistor collector lead. transistor emiter lead is connected to gnd which is common to both pics. the signal from emitter pic should bring the receiver pic pin to gnd and trigger an interrupt so it starts to read the pwm input.

The signal is:

on for 2400us
8 times: off for 600us, on for 600 us
off for 600us, on for 600 us
off for 600us, on for 1200us
off for 600us, on for 600 us
off for 600us, on for 600 us
off for 600us, on for 600 us
off for 600us, on for 600 us
off for 600us, on for 600 us
off for 600us, on for 600 us

this is a 'header' followed by two bits with bits sent msb to lsb:
0000000001000000

the receiving pic gets the signal on pin ra0 and it triggers an int but in the int handler, pulsin records values equal to 0!!!

If instead i attach an infrared led (Vishay tsal6100 at 940 nm) via the gate of an irld110pbf hexfet/mosfet at the output pin and use a Vishay tsop4840 ir receiver-demodulator at 40khz that pulls the receiver pic pin low when receiving an ir signal at 40khz, then it works! the receiver pic gets the interrupt, reads the signal and pulsin records the right duration.

How can it be?
Is it related to the way the transistor works? Sonething about the saturation or a lag?
i tried replacing the resistor+transistor with a hexfet but it does not work either!

I need to use a wired link between the pics, not an ir led and an ir receiver.

The code works because when using ir link (tsal6100-hexfet-tsop4840) the pic gets the signal. What's wrong with the transistor or hexfet?

Any ideas?

Quote:

Originally Posted by xnihilo

I need to use a wired link between the pics, not an ir led and an ir receiver.

Then don't modulate it.

The infrared receiver demodulates the 40khz, leaving only the data.
But with just a transistor, you're sending the 40khz along with the data to the receiving PIC.

Demodulation

Quote:

Originally Posted by Darrel Taylor

Then don't modulate it.

The infrared receiver demodulates the 40khz, leaving only the data.
But with just a transistor, you're sending the 40khz along with the data to the receiving PIC.
 

Hi Darrel, Thank you for your anwser.

Er...
Well, it is maybe too technical for me.

Would it solve the problem if instead of sending a PWM at 40KHz I send a non PWM signal using PBP "High" and "Low" for the output pin?
I'm puzzled, I think I already tried this and it didn't work either...
The receiving pic should get the pulses and the PULSIN should record it.
I have to try again.

RECEIVER pic:

Code:

'############################################################################### check_signal: '40KHz IR signal received by a TSOP4840 sensor or +5v (PWM) on the supplier input port, the total length with header is: max: 2400+16*600+16*1200 us '############################################################################### 'This may be either a bullet or a medic supply or a scores request 'MEMO: the timings may be very important !!!! 'Get the data 'first byte contains the player ID: 'bit7 of this bit is hit/system message, bits 6-0 are player ID 'second byte is: '00xxxx-- hit, from MT or SquadTag tagger (Milestag tagger has to select TEAM RED!!) '11xxxx-- scores request from SUPPLIER '01xxxx-- medic supply 'Only 00xxxx-- bullet is compatible with Milestag 'If other teams than RED are selected on the tagger, it will send fake information to the sensors module! 'If the input is a hit, only bits 2-5 contain the damage levels 'Only 4 values are valid for damage (IR bullet): '25% is encoded as: d9 '50% is encoded as: d13 '75% is encoded as: d14 '100% is encoded as: d15 'See Milestag protocol version 2 '%01000000 medic '%11000000 scores request 'We don't have to specificaly bypass the header because as it has already began, the pulsin will ignore it and wait for the next pulse which is the MSB of first sent byte 'fill in this data: '- pin: which pin received the message '- decode the data byte pin = 255 'set default fake area 'choose the pin on which to read depending on the pin that has triggered the INT 'get the duration of each of the expected 14 bits (8+6) 'when the scores request from supplier (via transistor) get to pin0, 'it yields an invalid signal (while it is fine when it gets to pin1 or pin2) IF (a.0(0) == 0) THEN FOR i = 0 to 13 'get a sequence of incoming 14 bits (WITHOUT their prefixes which are 600us pause) PULSIN PORTA.0,0,ir_pulse[i] ' Read 14 low-going pulses on RA.4, see pbp manual NEXT i pin = 0 ' Loop 14 times, record in 5us resolution pulse duration in the word variables array ENDIF IF (a.0(1) == 0) THEN FOR i = 0 to 13 'get a sequence of incoming 14 bits (WITHOUT their prefixes which are 600us pause) PULSIN PORTA.1,0,ir_pulse[i] ' Read 14 low-going pulses on RA.4, see pbp manual NEXT i pin = 1 ' Loop 14 times, record in 5us resolution pulse duration in the word variables array ENDIF IF (a.0(2) == 0) THEN FOR i = 0 to 13 'get a sequence of incoming 14 bits (WITHOUT their prefixes which are 600us pause) PULSIN PORTA.2,0,ir_pulse[i] ' Read 14 low-going pulses on RA.4, see pbp manual NEXT i pin = 2 ' Loop 14 times, record in 5us resolution pulse duration in the word variables array ENDIF IF (a.0(3) == 0) THEN FOR i = 0 to 13 'get a sequence of incoming 14 bits (WITHOUT their prefixes which are 600us pause) PULSIN PORTA.3,0,ir_pulse[i] ' Read 14 low-going pulses on RA.4, see pbp manual NEXT i pin = 3 ' Loop 14 times, record in 5us resolution pulse duration in the word variables array ENDIF IF (a.0(4) == 0) THEN FOR i = 0 to 13 'get a sequence of incoming 14 bits (WITHOUT their prefixes which are 600us pause) PULSIN PORTA.4,0,ir_pulse[i] ' Read 14 low-going pulses on RA.4, see pbp manual NEXT i pin = 4 ' Loop 14 times, record in 5us resolution pulse duration in the word variables array ENDIF 'at this step we got the bit length for the 14 bits '(it can be bytes for player ID and damage, or 0,192 if scores request, or medic supply) 'after this label: '- we know which pin received the message; '- if pin 0-4: we also have the durations of the pulses '- if pin =5: we know it is a status request (+5V pulse) '----- LCDOUT $fe,1,"pin = ",#pin PAUSE 2000 'Ranges for LOW bit: 109 to 153 'Ranges for HIGH BIT: 221 to 266 'header length: 118 to 122 'we scan the words array we stored from MSB to LSB databyte = 0 'reset low byte and high byte of the word variable to %0000000000000000 FOR i = 0 TO 13 ' process only 14 "data" bits out of 16 bits collected LCDOUT $fe,1,#i,":",#ir_pulse[i] PAUSE 2000 IF ((ir_pulse[i] > 210) && (ir_pulse[i] < 275)) THEN '240*5us resolution at 8MHz = 1200 us (usual length of a zero is about 127 - 145 and 242 to 266 fore a one) databyte.0(15-i) = 1 'clear the bit goto slip 'bypass ENDIF IF ((ir_pulse[i] > 105) && (ir_pulse[i] < 160)) THEN '240*5us resolution at 8MHz = 1200 us (usual length of a zero is about 127 - 145 and 242 to 266 fore a one) databyte.0(15-i) = 0 'clear the bit GOTO slip 'bypass ENDIF 'ELSE: invalid data LCDOUT $fe,1,#i," != ",#ir_pulse[i] LCDOUT $fe,$c0,"Invalid" PAUSE 500 valid = 0 'PAUSE 3000 databyte.0 = %10000000 'set an invalid data value to bypass the validation routine 'GOTO hop_here 'bypass and abort if one of the 14 bits is off limits slip: NEXT i 'At this step we filled "databyte" word variable from MSB to LSB with 14 incoming bits 'at this step the bit lengths are fine valid = 1 'now let's see if the bytes have a valid value IF ((databyte.0(6) == 0) && (databyte.0(7) == 0)) THEN 'if it is a bullet hit, 'update hits count inflicted by the opponent (who we know the ID) killer_id = databyte.byte1 'get opponent ID read (killer_id + 128),gotchas 'get the hits count by this opponent from EEPROM gotchas = (gotchas + 1) 'update count write (killer_id + 128), gotchas 'store back updated count in EEPROM 'output the data related to the oponent who hit you LCDOUT $fe,1,"Kiler: ",#databyte.Byte1 LCDOUT $fe,$C0,"Gotchas: ",#gotchas PAUSE 3000 ENDIF hop_here: 'jump here if one of the bit length is invalid (valid flag/bit is set to 0) 'show the two bytes values LCDOUT $fe,1,"DATA: ",#databyte.byte0 'display lowest byte of the word LCDOUT $fe,$c0,"ID: ",#databyte.byte1 'display lowest byte of the word PAUSE 3000 RETURN 'after signal has been processed return from subroutine

SENDER pic, PWM, works with IR transmission, not with wired link,
variable sig = %11000000

Code:

'############################################################################### send_sig: 'encoding the data signal: medic or score request '############################################################################### 'OUTPUT PWM on IR led on HEXFET on RC5 high backlight LCDOUT $FE, 1,"SENDING" LCDOUT $FE, $c0 'move at begining of 2nd line LCDOUT "PWM DATA" PAUSE 2000 'pause 2s low backlight T2CON.2 = 1 'start timer2 'HEADER: TMR2 = 0 'reset timer2 CCP1CON = 12 PAUSEus 2400 'HIGH pulse, 2400 uS output on RC5, *PWM* CCP1CON = 0 'DATA: 'first byte, %00000000 (MT2 compatible), don't care For i = 0 to 7 '8 bits, MSB to LSB pauseus 600 'bit prefix (600us no-pulse) TMR2 = 0 'reset timer2 CCP1CON = 12 'bit is '0' PAUSEus 600 CCP1CON = 0 NEXT i 'second byte For i = 0 to 5 'send only 6 bits MSB to LSB pauseus 600 'bit prefix TMR2 = 0 CCP1CON = 12 IF (sig.0(7-i) == 1) THEN PAUSEus 1200 'if bit = 1 ELSE PAUSEus 600 'if bit = 0 ENDIF CCP1CON = 0 NEXT i T2CON.2 = 0 'stop timer2 LCDOUT $FE, 1,"sig:",#sig LCDOUT $fe,$c0 FOR i = 0 to 7 LCDOUT #sig.0(7-i) NEXT i PAuSE 3000 LCDOUT $fe,1 RETURN

If you don't modulate it, you may have range & noise problem. Common use those IR-Demodulator so far. Just keep it and that's it. Open most Audio equipment... what's inside OOOOH surprise, a IR-Demod module :D

Quote:

Originally Posted by xnihilo

Would it solve the problem if instead of sending a PWM at 40KHz I send a non PWM signal using PBP "High" and "Low" for the output pin?
I'm puzzled, I think I already tried this and it didn't work either...

It should work. But you probably need to invert it.

On the transmit side, where it would previously turn the HPWM ON, make the pin LOW instead.

For PWM OFF, set the pin HIGH, and forget the transistor.

Added: And make sure the CCP module is turned OFF.

Quote:

Originally Posted by mister_e

If you don't modulate it, you may have range & noise problem. Common use those IR-Demodulator so far. Just keep it and that's it. Open most Audio equipment... what's inside OOOOH surprise, a IR-Demod module :D

My projet is a lasergame equipment with a "gun module", a "body module" and a "supplier" module that gives magazines/ammo and medics.

Yes, I understand the fact that it has to be modulated when using an IR link. My problem is that I have to use a wired link instead. Sender pic is used in a "supplier module" that provides a medic to a player 'body module' with its own pic. If the Medic supplier user wants to cheat, he can ask multiple players to stand in front of the IR led so they all get the medic kit (because of the spread and range of the ir beam). It has to be a pic to pic link.

Quote:

Originally Posted by Darrel Taylor

It should work. But you probably need to invert it.

On the transmit side, where it would previously turn the HPWM ON, make the pin LOW instead.

For PWM OFF, set the pin HIGH, and forget the transistor.

Added: And make sure the CCP module is turned OFF.
 

Yes, turn it low instead of high because I have to pull low my receiver pic pin RA0 to trigger the int.

But, and wouldn't it be better, I can also output a positive voltage pulse while the receiver pic is pulled to GND by a WPD resistor and PULSIN listens to a Low to HIGH transition: PULSIN porta.0,1,etcetera

Code:

IF (a.0(0) == 0) THEN FOR i = 0 to 13 'get a sequence of incoming 14 bits (WITHOUT their prefixes which are 600us pause) PULSIN PORTA.0,1,ir_pulse[i] ' Read 14 low-going pulses on RA.4, see pbp manual NEXT i pin = 0 ' Loop 14 times, record in 5us resolution pulse duration in the word variables array ENDIF

It would work too?

BTW, why do I need to disable CCP module? It would prevent the output to work fine?

And what's technicaly wrong with using a transistor???

As long as MAX 25mA drive to the LED give you enough range... there's no 'real' need for the extra transistor.

Quote:

Originally Posted by mister_e

As long as MAX 25mA drive to the LED give you enough range... there's no 'real' need for the extra transistor.

The IR led I use in the 'gun' module is boosted at 1A (!!!) so I have to use a HEXFET.
Anyway, for the "Supplier module", it is only to send a 14bits message and as I wrote above, to avaoid cheating, I really need to use a wired link instead of IR link. So I have to avoid using IR link.

Quote:

Originally Posted by mister_e

As long as MAX 25mA drive to the LED give you enough range... there's no 'real' need for the extra transistor.

Except for the 'heating/burning' pads... :D

Quote:

Originally Posted by xnihilo

BTW, why do I need to disable CCP module? It would prevent the output to work fine?

Yes, as long as the CCP module is ON, it has control of the CCP1 pin.

Quote:

And what's technically wrong with using a transistor???

Nothing really. Just extra parts that don't add any functionality.

But after thinking a little more about it ...
With people that are running and jumping with nylon backpacks while wearing rubber soled shoes ... If the first contact between 2 of them is going to be the connection to deliver a health pack? I think extra ESD protection on those pins would be the biggest concern.

Quote:

Originally Posted by skimask

Except for the 'heating/burning' pads... :D

gimme a break willya

Quote:

Originally Posted by Darrel Taylor

Yes, as long as the CCP module is ON, it has control of the CCP1 pin.

Nothing really. Just extra parts that don't add any functionality.

But after thinking a little more about it ...
With people that are running and jumping with nylon backpacks while wearing rubber soled shoes ... If the first contact between 2 of them is going to be the connection to deliver a health pack? I think extra ESD protection on those pins would be the biggest concern.
 

jeeze... i didn't think about that.
the pics don't have some esd protection like the eeproms (24lc08 seem to have that)?
How can i prevent an esd? using a capacitor?

Pic to Pic one wire data transmission: success

Quote:

Originally Posted by Darrel Taylor

It should work. But you probably need to invert it.

On the transmit side, where it would previously turn the HPWM ON, make the pin LOW instead.

For PWM OFF, set the pin HIGH, and forget the transistor.

Added: And make sure the CCP module is turned OFF.
 

Pure genious... Darrel, thank you. it works perfectly!
Hope this thread will help other.

Regards