IR Counter

[partime]

Thanks for the response dhouston. I looked over the information. I think that is were I eventually want to get to. However, I don't think I am ready to take that big of jump yet.

I have been working on trying to do simple IR communications between 2 PICs. I basically used the codes from http://www.rentron.com/Infrared_Communication.htm.

I used a PIC627 with this code for the PWM and SEROUT.

DEFINE OSC 4
TRISB.3 = 0  ' CCP1 (PortB.3 = Output)
PR2 = 25     ' Set PWM Period for approximately 38KHz
CCPR1L = 13  ' Set PWM Duty-Cycle to 50% 
CCP1CON = %00001100  ' Select PWM Mode
T2CON = %00000100    ' Timer2 = ON + 1:1 prescale
TRISB.0 = 0

ADDRESS	VAR BYTE
DAT	VAR BYTE
ID	VAR BYTE
ADDRESS	= 10
ID	= 25

BEGIN:
	FOR DAT = 0 TO 255
	    SEROUT PORTB.0,4,[ID,ADDRESS,DAT]
	    PAUSE 100
	NEXT
	GOTO BEGIN
END

And I used a PIC628A with this code for SERIN. The code Rentron had listed was BS2 code. I did my best to convert it to picbasic. I used SERIN2 instead of SERIN.

DEFINE OSC 4
CMCON = 7
VRCON = 0
TRISA = 0
TRISB = 1

SYNCH CON 25     'Establish synchronization byte
BAUD  CON 396    'NON INVERTED 2400 baud (MAX)
DAT   VAR byte   'Data storage variable
ADDRESS VAR BYTE

START:

SERIN2 PORTB.0,BAUD,[WAIT(SYNCH),ADDRESS,DAT]
PORTA = DAT

GOTO START
END

Was it okay to use SERIN2 with SEROUT?

I connected 4 LEDs to porta.0 thru porta.3. I am getting a response from the LEDs. I am just not sure if it representing the correct data. When I try something like:

ADDRESS	VAR BYTE
DAT	VAR BYTE
ID	VAR BYTE
ADDRESS	= 10
ID	= 25
DAT     = 10
BEGIN:
	SEROUT PORTB.0,4,[ID,ADDRESS,DAT]
	PAUSE 100
	GOTO BEGIN
END

I get the correct LEDs to light up initially for about a second. Then, the other LEDs start flashing.

I will continue to experiment and hopefully I will get the communications figured out.

I do have a question about the schematic Rentron uses for the IR Transmitter. Is there a reason why 2 Infrared LEDs are used to transmit the signal?

[dhouston]

Was it okay to use SERIN2 with SEROUT?

If you eventually want to use a remote, then all of this is just a waste of effort as 99.99% of remotes do not use RS232 communications.

I do have a question about the schematic Rentron uses for the IR Transmitter. Is there a reason why 2 Infrared LEDs are used to transmit the signal?

You get twice the IR signal strength for the same current.

[picster]

If your "carrier true" signal is incrementing because of looping, then you can simply count one, then sit and loop (no more counting) until the carrier detection returns a FALSE state, after which you drop out of the loop and wait for the next "button press". Kind of like switch debouncing, but different.

picster

[flotulopex]

Hello Partime,

I made a self-learning IR remote (with lots of help from people in this forum).

Maybe you can help some helpfull stuff in the code (especially LEARN and SEND routines).

Have a look here http://home.citycable.ch/flotulopex/...I_Frames_e.htm

[Archangel]

Hello Partime,

I made a self-learning IR remote (with lots of help from people in this forum).

Maybe you can help some helpfull stuff in the code (especially LEARN and SEND routines).

Have a look here http://home.citycable.ch/flotulopex/...I_Frames_e.htm

Roger, Nice ! I like your website ! Interested in that self learning remote too.

[partime]

Thank you picster and Roger for the information you presented.

I finally captured the signal from my remote as dhouston suggested. I couldn't get Loop Recorder to capture the signal, but I did get it with a different program (http://www.passmark.com/products/soundcheck.htm). I attached a copy of the signal I captured. It is from a Hitachi CLU-5722TSI remote's channel up button. The bottom one is the full signal. The top ones are of the signal divided into two segments.

The signal seems to follow this protocol that I found for Hitachi.

Code length:            32 bits
Carrier:                39.2kHz

The code is only transmitted once, and after that a stop code is transmitted.



	     +--------------------------------+                   
Header:      |                                |                  
	     +                                +----------------+..
			    16T                       8T
			   8.8ms                     4.4ms

	     +--+      
1 is coded:  |  |      
	   ..+  +------+..
	      T   3T

	     +--+  
0 is coded:  |  |  
	   ..+  +--+..
	      T  T 
			 +--+
			 |  |
After the last bit a ( ..+  +  ) is transmitted to terminate the last bit.
			  T

	      +--------------------------------+        +--+
Stop code:    |                                |        |  |
	      +                                +--------+  +
			      16T                  4T     T
			     8.8ms                2.2ms

T = 550us

What should the next step be? Should I try to write some code using PULSIN to read the incoming IR signal?

[dhouston]

That's the NEC protocol. It's one of the oldest and is used by more manufacturers than any other. It's very reliable as it has error detection built in (although some implementations do not use that). I have shown how to send/receive it (as RF) in this thread http://www.picbasic.co.uk/forum/showthread.php?t=6261. You just have to account for the fact that the IR receiver is active low while the RF receiver is active high. There is a link within that post to a NEC datasheet that explains it completely. I've decoded the third image and attached it. Hitachi is using error detection - the first two bytes sum to FF as do the third and fourth bytes.