Decoding an incoming infrared signal: need advice

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