IR Counter

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

[dhouston]

I just looked at your diagram. That's not a Stop Code - it's a Repeat Code. That reduces battery drain compared to repeating the full code.