IR And UART

[gramo]

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;
**broken link removed**

And the receiver;
**broken link removed**

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]

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]

Very Good idea but can show us the firmware example

 

[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

 

[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.

 

[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

 

[gramo]

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]

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]

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]

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]

Re-evaluating your post Tim

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]

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]

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

    #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]

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...
**broken link removed**

 

[gramo]

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

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

 

[gramo]

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...
**broken link removed**

I could understand someone who does know how to use PIC's to use a rather expensive device like the above, but put simply, PIC's are cheaper, and coupled with an IR Receiver for $1, they can (could) do the same job, and much more...

I suppose speed could be an issue, but why on earth would you use IR if speed was a requirement?

 

[geko]

To sync the data with the 38Khz signal you could use a JK flip-flop instead of the AND gate.

Clock it at 76KHz (2 x 38Khz), hold K input high and connect the J input to your data. When J is high you get 38Khz signal out, when J is low, the output is low and the transition is synced to the clock. (I might have that the wrong way round in which case swap J & K or use -Q out )

 

[bloody-orc]

there's nothing better than that MAX chip, when both USART and IR are required on one board witch only has one USART host (one chip). As you would have to buy MAX232 for RS232 anyway, then why not invest 1$ more and get 3010... I got a few free of charge and am very happy. probably going to do some testing this weekend (if I get the time).
Plus as most good chips have a built in USART (Hardware) then using this is much easier. especially when 2way data is needed. and it is interrupt driven, witch makes software on the uController run much faster, than when you have to poll the data line to see, if anything is there to be read...

Of course I'm not saying that using PIC to do the IrDa communication isn't cheaper, but when 2way data is needed than 3130 is the way to go. especially when communicating with PC/Laptop/PDA/Mobile/etc devices. Makes coding also a lot easier (normal COM port commands).


Anyway good luck with your project and go the way you find most appropriate for you. I'm only suggesting that you should use 3130 when doing 2 way communication or something similar.

when just one way and simple data PIC to PIC, then Manchester encoding and transistor controlled over amperaged IR diode and daylight filtered OP-amp amplified receiver is the way to go...

 

[donniedj]

gramo:
I use IR-mods on many of my PIC projects to interface with a PC. I do not use nothing other than the IR-Mod RX and IR leds. Have you taken a look at the IR-Mod protocal? Data is interpreted by the length of a stream of 38KHZ pulses and all pulses must terminate for a period of time proportional to the the transmision time. Unlike RS232, where you can send all 1s or all 0s without interruption, IR requires each 1 or 0 bit to be reset because any continous streams will be filtered out.

Is this a "What I have done" or a "Can it be done" post? Because I would like to see if it can be done. Extra 74hc chips waste to much space for me but would still like to know.

 

[blueroomelectronics]

donniedj, just watched your coilgun fire three rounds.
Is it supposed to appear that the gun can fire three rounds that fast?

(if so check out the shadows as it appears the sun is going down pretty rapidly)