IR Counter


Closed Thread
Results 1 to 13 of 13

Thread: IR Counter

  1. #1
    Join Date
    May 2009
    Posts
    4

    Default IR Counter

    I want to use infrared communication to increase/decrease the score on a scoreboard. So, if I press one button on a remote, then the score will increase by one. And, if another button is pressed, then the score gets decreased by one. The score is output to a dual 7-segment LED display. This is what I have done so far.

    First, I setup a PIC627 to increase the count by one everytime I pressed a button which was hardwired to the PIC. Next, I removed the button and added a PIC628a to act as the button. I bought the Infrared Communications kit from Rentron.com (http://www.rentron.com/remote_contro...red-serial.htm) and used the PNA4602M detector to be the input to the PIC628a. I programmed it so the output would go high when an infrared signal was detected. This worked. I could use any remote I had and the count would increase everytime I pressed any button. Lastly, I assembled the transmitting part of the kit I got from Rentron. I used a simple SEROUT command to be transmitted. And again, the count would increase when the signal was detected. So, I think I sort of have the up count figured out. I am new to most of this and I took small steps to get where I am now. I started with the simple counter and just added to it.

    Here is some of the programming I have used:

    PIC627 - gets input from portb.7 and increase cnt by 1 when button is pressed

    BUTTON Pbutton, 1, 255,0, i, 0, LOOP 'pbutton = portb.7
    pause 100
    Cnt = Cnt + 1
    GOTO LOOP

    The count would increase very rapidly when the remote button was press just montentarly, so I added the pause. This helped slow things down. I'm not sure if this best command to use to increase the count or not. It was okay when I just used this chip hardwired to a button. But, now since I want the increase to be triggered by an IR signal, I'm not sure it is the best choice to use.


    PIC628a - gets input from the PNA4602M detector and outputs to the 627 as a button

    loop:
    IF PORTB.0 = 0 Then
    high PORTB.1
    else
    low PORTB.1
    endif
    goto loop

    So, if an infrared signal is detected, then a high signal is output to portb.7 on the PIC627.


    PIC84 - used to produce the data to be transmitted

    TRISB = 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

    This is just the code I got off the Rentron website, just to test that things were working. The output is NANDed with 38 kHz carrier frequency. Having this setup, the diplay will count up very fast because of the constant signal that is being generated.


    My next task is to add a way to decrease the count. This is were I think I am going to need some guidance. Ideally, I would like to be able use an old TV remote and just use one button on the remote to increase the count and another to decrease it. Otherwise, I believe that I will need to add pushbuttons which produce different SEROUT data. Or something like that.

    I can probably reduce the number of PICs that I am using. I just used each PIC to accomplish a given task and simplify things.

    Hopefully this isn't too much information, but I wanted to give a good idea of what I have setup. Do I look like I am going in the right direction with things? Any input would be appreciated. Thanks.

  2. #2
    Join Date
    Dec 2005
    Posts
    1,073


    Did you find this post helpful? Yes | No

    Default

    You need to take this step-by-step.

    The first step is to choose the remote and then capture the signal from the keys you want to use. See http://davehouston.org/learn.htm for a simple way to do this.

  3. #3
    Join Date
    May 2009
    Posts
    4


    Did you find this post helpful? Yes | No

    Default

    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.
    Code:
    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.

    Code:
    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:
    Code:
    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?

  4. #4
    Join Date
    Dec 2005
    Posts
    1,073


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by partime View Post
    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.

  5. #5


    Did you find this post helpful? Yes | No

    Default qualifying IR input

    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

  6. #6
    Join Date
    Aug 2006
    Location
    SWITZERLAND (french speaking)
    Posts
    891


    Did you find this post helpful? Yes | No

    Default

    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

  7. #7
    Join Date
    Aug 2006
    Location
    Look, behind you.
    Posts
    2,818


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by flotulopex View Post
    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.
    If you do not believe in MAGIC, Consider how currency has value simply by printing it, and is then traded for real assets.
    .
    Gold is the money of kings, silver is the money of gentlemen, barter is the money of peasants - but debt is the money of slaves
    .
    There simply is no "Happy Spam" If you do it you will disappear from this forum.

  8. #8
    Join Date
    May 2009
    Posts
    4


    Did you find this post helpful? Yes | No

    Default

    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:
    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?
    Attached Images Attached Images  

  9. #9
    Join Date
    Dec 2005
    Posts
    1,073


    Did you find this post helpful? Yes | No

    Default

    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.
    Attached Images Attached Images  
    Last edited by dhouston; - 1st June 2009 at 11:58. Reason: Added PNG of decoded NEC code

  10. #10
    Join Date
    Dec 2005
    Posts
    1,073


    Did you find this post helpful? Yes | No

    Default

    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.

  11. #11
    Join Date
    May 2009
    Posts
    4


    Did you find this post helpful? Yes | No

    Default

    Thanks again for your help Dave. I pretty much used your RF receiver code and modified it for use with the IR signal. Here is the code I used on an 16F84A with a 4 MHz crystal. I used it to test if the channel up button was pressed on the remote.

    Code:
    define PULSIN_MAX 968
    
    IRPIN           var     PORTB.0
    LED             var     PORTB.1
    LED2            var     PORTB.2
    RF              var     byte[4]
    Header          var     word
    PULSE_LENGTH    var     byte
    i               var     byte
    
    INIT:   RF[0]=0
            RF[1]=0
            RF[2]=0
            RF[3]=0
            i=0
            Pulsin IRPIN, 0, Header
            if (Header < 792) then INIT
            while irpin = 0:wend
            repeat
                pulsin IRPIN, 1, PULSE_LENGTH
                if (PULSE_LENGTH < 40) or (PULSE_LENGTH > 175) then INIT
                if (PULSE_LENGTH > 90) then 
                    RF.0(i) = 1
                else
                    rf.0(i) = 0
                endif
                i=i+1
            until (i>31)
            if (RF[3]=230) then 
            high LED
            pause 500
            low LED
            else
            high LED2
            pause 500
            low LED2
            endif
            goto INIT
    end
    I get LED to go high when I press the channel up button.

    It took me awhile to figure out how the data was arranged in the array. I started out using RF[0]=10 to light LED, but kept getting LED2 to light up. So, I thought there was something screwed up with the values pulsin was generating. Finally, I read through the FAQ on arrays and figured out my problem. I used RF[0]=80 and got LED to light up. However, LED would light up with any button I pushed since all the buttons used the same starting code. So, I ended up using RF[3] to test if channel up was pressed.

    Is testing RF[3] going to be the best way to determine which button is pushed? I plan to use channel up/channel down for one team and volume up/volume down for the other team.

  12. #12
    Join Date
    Dec 2005
    Posts
    1,073


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by partime View Post
    Is testing RF[3] going to be the best way to determine which button is pushed? I plan to use channel up/channel down for one team and volume up/volume down for the other team.
    The way most use this protocol, RF[0] indicates a device (e.g. TV, CD player) and RF[2] indicates a button (e.g. number, Vol+). RF[1] is the bitwise complement of RF[0] and RF[3] is the bitwise complement of RF[2]. So, you are probably safe using either RF[2] or RF[3].

    I would suggest a change...
    Code:
            while irpin = 1:wend
    That merely waits until the initial space part of the header passes. With RF I found that was necessary.

  13. #13
    Join Date
    Dec 2005
    Posts
    1,073


    Did you find this post helpful? Yes | No

    Default

    Also, since the array elements are reset to zero at the top of the loop, you can simplify this...
    Code:
                if (PULSE_LENGTH > 90) then 
                    RF.0(i) = 1
                else
                    rf.0(i) = 0
                endif
    to this...
    Code:
                if (PULSE_LENGTH > 90) then 
                    RF.0(i) = 1
                endif
    And, while errors are less likely with IR, you can detect them buy adding RF[2] and RF[3]. They should always sum to 255 or $FF.
    Last edited by dhouston; - 3rd June 2009 at 12:40.

Similar Threads

  1. Conway's Game Of Life
    By wellyboot in forum mel PIC BASIC Pro
    Replies: 45
    Last Post: - 28th May 2020, 06:14
  2. Replies: 17
    Last Post: - 12th April 2014, 02:17
  3. 20 Digit Virtual LED Counter
    By T.Jackson in forum Code Examples
    Replies: 9
    Last Post: - 19th November 2007, 05:02
  4. PIC10F200 Automated IR Light Switch
    By Bruce in forum Code Examples
    Replies: 7
    Last Post: - 3rd May 2007, 11:40
  5. Microcontroller with 2 way paging application problem
    By oneohthree in forum mel PIC BASIC Pro
    Replies: 30
    Last Post: - 20th April 2007, 17:27

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts