Decoding an incoming infrared signal: need advice

[xnihilo]

Here is the stuff:

I'm using PIC16F684 (as usual) and I connected a Vishay TSOP4840 IR receiver-demodulator.
It has 3 leads: GND, VSS and DATA.
The data lead connects to RA0 of my pic. RA0 is set as input and has its WPU enabled so when the receiver gets 40KHz IR signal at 940 nm (and amplified it) it brings RA0 low.

Well.

Now I have to write a routine that will decode the signal.

Signal is a PWM signal (40KHz, 30% duty cycle).
The data encoding is:

Header: High 2400us.

Data: 8 bits, sent from MSB to LSB, decoded from MSB to LSB.
Each byte is prefixed with a 600us no-pulse pause (the 'spacer'). If a bit is set, there is a 1200us pulse, if bit is cleared, there is a 600us pulse.

The routine I would like to use is:
-----------------------------------------------

WHEN INT OCCURS:

(inside my int handler, once i've cleared port latch mismatch anr reset int flag)




databyte = %00000000

'wait for the header pulse to end and check if duration is about 2400us+/-100us
j = 0
WHILE (porta.0 == 0)
PAUSEUS 20
j = j + 1
WEND
IF (( j < 115) || (j > 125)) then abort 'wrong pulse duration

FOR i = 0 to 7

j = 0
WHILE (porta.0 == 1) 'wait until the bit prefix (600us no-pulse) ends
PAUSEUS 20
j = j + 1
WEND
IF ((j < 25) || (j > 35)) then abort 'wrong no-pulse duration, we want it to be 600us+/-100us

j = 0
WHILE (porta.0 == 0)
PAUSEUS 20
j = j + 1
WEND
IF ((j > 25) && (j < 35)) THEN
databyte.0(i) = 0
GOTO bypass
ENDIF
IF ((j > 55) && (j < 65)) THEN
databyte.0(i) = 1
GOTO bypass
ENDIF
GOTO abort 'wrong pulse duration
bypass:

NEXT i

abort:


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


I'm afraid this code is pretty heavy and I don't like the lack of accuracy in the timing that force me to use stupid code like:
IF ((j < 25) || (j > 35)) then abort

Is there a faster and more accurate way to decode my signal?

THANKS A LOT for any help or advice.

regards

charles

[mister_e]

Maybe you can find some tips with the following
http://rentron.com/PicBasic/IR_Chips.htm

[Bruce]

From the bit timing you indicate, I would guess this is a Sony IR transmitter? PULSIN should
be all you need to decode this type. It's one of the easiest around to encode & decode.

[xnihilo]

No guys,

I can't change my hardware.

BRUCE:
"From the bit timing you indicate, I would guess this is a Sony IR transmitter? PULSIN should
be all you need to decode this type. It's one of the easiest around to encode & decode."

It is a VISHAY TSOP4840 receiver (see mouser for the datasheet) and the emiter is a VISHAY TSAL6100 led. I'm using pic's PWM output to encode and I need to decode on the other side but do it quickly and acurately. I'm not using pulsin, I'm polling the input pin, what's wrong with that?

[Bruce]

Nothing's wrong with polling, if it works for you. I just prefer PULSIN since it's more
than accurate enough, and a lot easier.

[xnihilo]

Nothing's wrong with polling, if it works for you. I just prefer PULSIN since it's more
than accurate enough, and a lot easier.

I agree.

Thank you very much.

[xnihilo]

I have a strange behavior.

The signal I am supposed to get is:

Assuming the normal state is low, I drive the input pin low with an IR receiver-demodulator.

2400us low (=header), then for each of 16 bits I have a bit prefix which is a 600us pause then if the bit is = 1 there will be a 1200us low or if bit = 0, there will be 600us low.

The incoming IR signal triggers an int on RA4 and then I start pulsin-ing to get the data.

The sequence I get is something like:
127,261,136,251,140,137,137,136,136,247,261,136,24 7,0,0,0
0,1,0,1,0,0,0,0,0,1,1,0,1,?,?,?

There seems to be an offset somewhere. I don't seem to get the first bit.
Maybe it takes too much time to get to the routine that checks the pulse durations???

The data structure I am supposed to get is:
0,0,1,0,1,0,0,0,0,0,1,1,0,1,?,?


Here is my code, in the case someone has an idea:



'-------------------------------------------------------------------------------
'----- HEADER PULSE ------------------------------------------------------------
'-------------------------------------------------------------------------------

'based on pulsin routines from: http://rentron.com/PicBasic/IR_Chips.htm

PULSIN PORTA.4,0,pulse_in '// Read-in start pulse - in a word var!!
IF (pulse_in < 480) OR (pulse_in = 0) THEN '// Less than header, then keep looking
'GOTO bypass
ENDIF


'-------------------------------------------------------------------------------
'----- get 2 databytes ---------------------------------------------------------
'-------------------------------------------------------------------------------

'Maybe it is too late to get the header because pulsin may reacto to a high to low transition
'while we are ALREADY in the low state, so the header will be bypassed ????

FOR i = 0 to 15 'get a sequence of incoming 16 bits (WITHOUT their prefixes)
PULSIN PORTA.4,0,ir_pulse[i] '// Read 16 low-going pulses on RA.4
NEXT i '// Loop 16 times

' LCDOUT $fe,1,"hdr:",#pulse_in
' PAUSE 2000

'databyte = $FF '// Start with all 1's and find each 0

'we scan the second byte we stored from MSB to LSB
'FOR i = 8 TO 15 '// Get 8 "data" bits
FOR i = 0 TO 15 '// Get 8 "data" bits
LCDOUT $fe,1,#i,":",#ir_pulse[i]
PAUSE 2000
IF (ir_pulse[i] < 240) THEN '240*5us resolution at 8MHz = 1200 us
databyte.0(15-i) = 0 'clear the bit
ELSE
databyte.0(15-i) = 1
ENDIF
NEXT i

[xnihilo]

I solved the problem.
The header triggers the int and cannot be detected by pulsin that detects an edge.
When int is triggered, I just check with a loop and 15us increments the duration of the triggering signal (the 2400us signal) then I use pulsin to get the bits and their length (thus their state).

Cool.

[flotulopex]

Hello,

I'm making a small TV remote based on a 12F683.

It is not finished yet but I have a question about how important the carrier's frequency is.

I've made some test with my SONY TV at different carrier frequs, but I couldn't notice any difference in the operatin distance between the TV and the remote (it works over 8 meters). Maybe my TV is very "sensible" to any IR remote signal and this is not a trustfull test.

As different suppliers use different IR-Receivers with different specifications especially the carrier frequency (mainly between 36 and 40kHz), I'd like to know much importance is to give to this parameter.

Since the remote is going to "learn" from different remotes (= different brands = different carrier freq), I think best to adjust this freq accordingly.

Using mister_e's PicMultiCalc program, I've noticed that I can almost generate the frequency range in a 0,5kHz resolution (36 / 36,5 / 37 / 37,5 / etc).

Does anyone know if it is worth (or mandatory) to have a higher precision?

If yes, can I achieve this with a PIC easely or should I go for an external pulse-generator (or any other system)?

[dhouston]

Most of the receivers in A/V gear have a fairly wide bandwidth (+/- 5kHz) so this is not super-critical for typical use. I designed a CF card IR transmitter for use with PDAs a few years back. Using a single emitter driven by 3.3V, the tested range exceeded 30m.

[Bruce]

Like Dave says, it's not normally critical. Especially in relatively noise free environments
where you have a good strong IR signal.

But, if you need the absolute maximum range, under less than favorable conditions, then
it's a lot more important. If your carrier frequency is spot-on the center band-pass frequency
of the IR receiver, it's more likely to work under less than optimum conditions.

The IR receiver is more sensitive to the signal when it's spot-on the center band-pass
frequency.

Even little things like matching the wavelength of the IRLED to the IR receiver can make a
BIG difference if it has to work reliably under various conditions.