IR And UART - Electronic Circuits Projects Diagrams Free

gramo · 11th May 2007, 10:02 AM

Just playing around with IR, and before I go off and order these AND gates, just wanted to be sure everything will work

PORTC.2 has a constant 38Khz PWM with a 50% duty cycle. The other input of the AND gate is connected to the UART TX of the PIC.

The idea is to use the and gate to switch the modulated signal (38Khz) on/off in synch with the UART signals, to the IR Emitter LED. You now have a 38Khz modulated UART IR signal...

The receiver’s output should look just like that of the UART, as it will demodulate the 38Khz signal too logic voltages (normal UART), and that will be connected to the RX of the receiver PIC

Here's the transmitter;

And the receiver;

The modulated UART signal might contain small errors, as the AND gate can't control the rise/fall conditions of the PWM input. Sometimes it might be one pulse out, others right on. With this in mind, I would start at around 300 baud, and trial it upward from there.

Should be noted that the 74HC08 has rise/fall times of ~33nS @ 5V, and can source/sink upto 25mA

bloody-orc · 11th May 2007, 10:27 AM

use IrDa man

MAX3130 (or something similar) is like MAX232, but has also inbuilt IrDa controller to connect to the same lines. Very good chip (I found it and am going to use it soon. haven't had any time to do that yet).

but this might work as well

but most certainly not so well

Medtronic · 11th May 2007, 10:37 AM

Very Good idea but can show us the firmware example

gramo · 11th May 2007, 10:57 AM

I can't find the MAX3130, but I did find one made by microchip

Hmm looking through the datasheet of the MCP2140, it seems to use almost exactly the same analogy, we'll have to build each and compare the two

**Nigel Goodwin** · 11th May 2007, 11:16 AM

You might have noticed that remote controls don't work like that?, and for VERY good reason - the pulse widths out of the receiver aren't the same as those supplied to the transmitter. For this reason they tend to use things like Manchester coding (Philips RC5) and the Sony SIRC's system (and a great many other similar schemes).

It also seems a waste adding an extra gate for the transmitter, and producing less accurate pulses? - it's trival to produce 38KHz in software with perfect accuracy from every bit.

Tim_B · 11th May 2007, 11:18 AM

I use a usart and a IR detector and have pretty good success but up at close range only, as soon as you start to go distances then you need to start thinking along the lines of RF techniques.

Also remember that any noise out of the detector will start the Usart and you have to think hard about syncing.

Again as I said I have used them, one system was a keyfob that received as well as transmitted, it worked very well in the end.

One trick I use is to tx out using the HPWM module I modified a standard Serial com's routine to toggle the Tris to turn on/off the HPWM output that generates the 38khz carrier.

In the keyfob I use a 12F683 as it has a HPWM built in. Suburb little device

gramo · 11th May 2007, 11:21 AM

Quote:

Originally Posted by Nigel Goodwin

It also seems a waste adding an extra gate for the transmitter, and producing less accurate pulses? - it's trival to produce 38KHz in software with perfect accuracy from every bit.

You still think the pulses will be 'less accurate' even though the rise/fall times of the 74HC08 are ~33nS @ 5V

gramo · 11th May 2007, 11:24 AM

Quote:

Originally Posted by Tim_B

One trick I use is to tx out using the HPWM module I modified a standard Serial com's routine to toggle the Tris to turn on/off the HPWM output that generates the 38khz carrier.

Nice, I'll have to try this out

**Nigel Goodwin** · 11th May 2007, 11:29 AM

Quote:

Originally Posted by gramo

You still think the pulses will be 'less accurate' even though the rise/fall times of the 74HC08 are ~33nS @ 5V

I don't see as the rise time has anything to do with it?, how do you plan syncronising the start and stop times of the 38KHz with the start and stop time of the UART? - presumably you don't, so the 38KHz starts and stops randomly anywhere in either a mark or a space - producing variable length pulses from the IR LED (making matters even worse).

In software every single IR pulse is a perfect number of 38KHz cycles, and without using any extra hardware.

I know the PIC includes various useful hardware, but that doesn't mean you have to use it - particularly when doing so gives substantially poorer performance, and in this case requires more external hardware.

ericgibbs · 11th May 2007, 12:18 PM

hi gramo,
I see the same problems as Nigel explained, one of the sync.
Any extraneous pulse could be seen by the RX end, if its at the start of a transmission frame it could be seen as a START bit.

The idea proposed by Tim_B, where the 38khz is gated on by the 'bit' seems a more secure approach.

I thought that the IR/UART path was already well trodden??

EDIT:I'm sure it is, now its my turn lol Touche. gramo!

gramo · 11th May 2007, 12:54 PM

Re-evaluating your post Tim

Quote:

One trick I use is to tx out using the HPWM module I modified a standard Serial com's routine to toggle the Tris to turn on/off the HPWM output that generates the 38khz carrier.

Hmm, wouldn’t that lead to the same issues I have at the moment? eg, the 38KHz signal starts and stops randomly anywhere in either a mark or a space, as the TRIS is being controlled, not the Sync of the signal? Is there a way to ensure that the modulated signal is in synch to start with?

Or perhaps the slight error was to small to corrupt data?

On a side note, using the software approach above;

The IR Receiver might start 1/2 a cycle late, but so to will it finish 1/2 cycle late, and there in the same concept for the remainder of that transmission. The signal would be slightly shifted if compared, but would take exactly the same amount of time as the TX UART original signal for each bit of data wouldn't it?

This is all speculation on my behalf, could be completely wrong

ericgibbs · 11th May 2007, 01:11 PM

hi gramo,
I think this one of the areas that 'simulators' are unable to show the actual effects we would get in actual hardware.

Why don't you construct a hardware setup and try it in real time.

They say a 'picture is worth a thousand words', I also believe ' a working model is worth a thousand pictures'.

Tim_B · 11th May 2007, 01:17 PM

It depends on the tx speeds I run my stuff at 2400 and only send 5 bytes at a time so it's never been an issue.

Also I have not looked in depth at the characteristics of the IR decoder, how many 38khz pulses does it need to see before it accepts it as valid?

I did start writing my own asm routines but its not actually that easy and the time taken to get it all going 100% was not worth it for the project I was using it on.

BTW I did all my work in real parts

I spent 5 mins altering the asm and it worked first time so never put much more thought into it

This was my code

Code:

    #disable RSOut
    Dim GPR As Byte SYSTEM
    Dim PP1 As Byte SYSTEM
    Dim PP1H As Byte SYSTEM
    Dim BPFH As Byte SYSTEM

    Symbol IR_LED =  PORTB.2
    Symbol IR_LED_TRS = TRISB.2
    
    GoTo OVER_IROUT

ASM
;SERIAL_BAUD = 2400
RSOut movwf GPR
	movwf PP1
	bsf 3,5
	bcf IR_LED
	bcf 3,5
	movlw 9
	movwf PP1H
	clrc
	Call rso@bit
	rrf PP1,f
	decfsz PP1H,f
	GoTo $ - 3
	setc
	Call rso@bit   ; STOP BIT
	movlw 0
	movwf PP0H
	movlw 100
	Call dlus@w 
	bsf STATUS,5  ;BANK1
	bsf IR_LED_TRS   ;MAKE PIN INPUT    ' LEAVE WITH THE SIGNAL IN ITS OFF STATE
	bcf STATUS,5  ;BANK0
	movfw GPR
	GoTo i@nt
rso@bit skpnc
	GoTo rso@bitl
	nop
	bsf STATUS,5  ;'BANK1
	bcf IR_LED_TRS   ;MAKE PIN OUTPUT
	bcf STATUS,5  ;BANK0
	GoTo Sr@dly1
rso@bitl
	bsf STATUS,5  ;BANK1
	bsf IR_LED_TRS   ;MAKE PIN INPUT
	bcf STATUS,5  ;BANK0
sr@dly1 
    movlw 1
	movwf PP0H
	movlw 147
	GoTo dlus@w
ch@snd
	btfsc BPFH,6
	GoTo RSOut
ENDASM

OVER_IROUT:

    PR2 = 25                                    ' Set PWM Period for approximately 38KHz
    CCPR1L = 13      		                    ' Set PWM Duty-Cycle to 50% 
    CCP1CON = %00001100                         ' Mode select = PWM
    T2CON = %00000100		                    ' Timer2 ON + 1:1 prescale ratio
    Input IR_LED                                ' MAKE SURE ITS AN INPUT PIN TO START WITH

In Proton once I included this I just used RSout x,x,x,x as normal

bloody-orc · 11th May 2007, 01:32 PM

MAX chip uses the same data as USART. Just send the data and it does all the encoding and decoding into the pulses etc. Also compatible with LAptops IrDa port. That's all the firmware...
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1947

gramo · 11th May 2007, 01:32 PM

Thanks Tim, that'll give me something to ponder tomorrow.

Quote:

Originally Posted by Tim_B

Also I have not looked in depth at the characteristics of the IR decoder, how many 38khz pulses does it need to see before it accepts it as valid?

16 Cycles, so the max baud would actually be 2375 (1 / ((1 / 38K) * 16))

I'd be happy with anything around 1200 to be honest

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

11th May 2007, 10:02 AM	#1
gramo	IR And UART Just playing around with IR, and before I go off and order these AND gates, just wanted to be sure everything will work PORTC.2 has a constant 38Khz PWM with a 50% duty cycle. The other input of the AND gate is connected to the UART TX of the PIC. The idea is to use the and gate to switch the modulated signal (38Khz) on/off in synch with the UART signals, to the IR Emitter LED. You now have a 38Khz modulated UART IR signal... The receiver’s output should look just like that of the UART, as it will demodulate the 38Khz signal too logic voltages (normal UART), and that will be connected to the RX of the receiver PIC Here's the transmitter; And the receiver; The modulated UART signal might contain small errors, as the AND gate can't control the rise/fall conditions of the PWM input. Sometimes it might be one pulse out, others right on. With this in mind, I would start at around 300 baud, and trial it upward from there. Should be noted that the 74HC08 has rise/fall times of ~33nS @ 5V, and can source/sink upto 25mA __________________ digital-diy.com - Hobby microcontroller projects and tutorials. Assembly, PICBasic and C examples. Last edited by gramo; 11th May 2007 at 10:06 AM.

11th May 2007, 10:27 AM	#2
bloody-orc	use IrDa man MAX3130 (or something similar) is like MAX232, but has also inbuilt IrDa controller to connect to the same lines. Very good chip (I found it and am going to use it soon. haven't had any time to do that yet). but this might work as well but most certainly not so well __________________ Need Help? Press F1 If that doesn\'t help you, ask me... I might know better.

11th May 2007, 10:37 AM	#3
Medtronic	Very Good idea but can show us the firmware example

11th May 2007, 10:57 AM	#4
gramo	I can't find the MAX3130, but I did find one made by microchip Hmm looking through the datasheet of the MCP2140, it seems to use almost exactly the same analogy, we'll have to build each and compare the two __________________ digital-diy.com - Hobby microcontroller projects and tutorials. Assembly, PICBasic and C examples. Last edited by gramo; 11th May 2007 at 11:10 AM.

11th May 2007, 11:16 AM	#5
Nigel Goodwin	You might have noticed that remote controls don't work like that?, and for VERY good reason - the pulse widths out of the receiver aren't the same as those supplied to the transmitter. For this reason they tend to use things like Manchester coding (Philips RC5) and the Sony SIRC's system (and a great many other similar schemes). It also seems a waste adding an extra gate for the transmitter, and producing less accurate pulses? - it's trival to produce 38KHz in software with perfect accuracy from every bit. __________________ PIC programmer software, and PIC Tutorials at: http://www.winpicprog.co.uk

11th May 2007, 11:18 AM	#6
Tim_B	I use a usart and a IR detector and have pretty good success but up at close range only, as soon as you start to go distances then you need to start thinking along the lines of RF techniques. Also remember that any noise out of the detector will start the Usart and you have to think hard about syncing. Again as I said I have used them, one system was a keyfob that received as well as transmitted, it worked very well in the end. One trick I use is to tx out using the HPWM module I modified a standard Serial com's routine to toggle the Tris to turn on/off the HPWM output that generates the 38khz carrier. In the keyfob I use a 12F683 as it has a HPWM built in. Suburb little device

11th May 2007, 12:18 PM	#10
ericgibbs	hi gramo, I see the same problems as Nigel explained, one of the sync. Any extraneous pulse could be seen by the RX end, if its at the start of a transmission frame it could be seen as a START bit. The idea proposed by Tim_B, where the 38khz is gated on by the 'bit' seems a more secure approach. I thought that the IR/UART path was already well trodden?? EDIT:I'm sure it is, now its my turn lol Touche. gramo! __________________ Eric " Good enough is Perfect " I will NOT answer PM's requesting technical help, please use the Forum PIC tutorials: Nigel's www.winpicprog.co.uk/ Bill's: www.blueroomelectronics.com/ Last edited by ericgibbs; 11th May 2007 at 12:35 PM.

11th May 2007, 01:11 PM	#12
ericgibbs	hi gramo, I think this one of the areas that 'simulators' are unable to show the actual effects we would get in actual hardware. Why don't you construct a hardware setup and try it in real time. They say a 'picture is worth a thousand words', I also believe ' a working model is worth a thousand pictures'. __________________ Eric " Good enough is Perfect " I will NOT answer PM's requesting technical help, please use the Forum PIC tutorials: Nigel's www.winpicprog.co.uk/ Bill's: www.blueroomelectronics.com/

11th May 2007, 01:32 PM	#14
bloody-orc	MAX chip uses the same data as USART. Just send the data and it does all the encoding and decoding into the pulses etc. Also compatible with LAptops IrDa port. That's all the firmware... http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1947 __________________ Need Help? Press F1 If that doesn\'t help you, ask me... I might know better.