Changing value on PWN pins with IR remote messes up the program

Would you please post the code on this site.  I, for one, don't want to go to a third-party site such as that.

Would you please post the code on this site.  I, for one, don't want to go to a third-party site such as that.

Sure.

#include "IRremote.h"
//assigning ir receiver to digital pin 2
int receiver = 2;

IRrecv irrecv(receiver); //creating an instance of irrecv
decode_results results; //create instance of decode results

//LEDs initialization
int lampka[] = {3, 5, 6, 9, 10, 11, 13};

//ir sensor initialization
int ir_sens = 2;

//photoresistor initialization at analog pin 0
int photo_res = 0;

int val = 255; //brightness of the leds

int program = 1; //which program should be executed now?
int state = 1; //the chain should be turned on or turned off?
int mode = 1; //we input modes or brightness with the remote?

//function defining buttons of the remote
void translateIR()
{

switch(results.value)
   {
    case 0xFF42BD: //* button
      mode = 1;
      break;
   
    case 0xFF52AD: //# button
      mode = 2;
      break;

     case 0xFF02FD: //ok button
       if (state == 1)
         state = 0;
       else
         state = 1;
       break;
    case 0xFF6897: //button 1
      if (mode == 1)
      program = 1;
      if (mode == 2)
      val = 25;
      break;
   
    case 0xFF9867: //button2
      if (mode == 1)
      program = 2;
      if (mode == 2)
      val = 50;
      break;

    case 0xFFB04F: //button3
      program = 3;
      break;
   }

}

//first program of the chain
void pierwszy()
{
for(int wl_wyl = 0; wl_wyl < 7; wl_wyl++)
{
  analogWrite(lampka[wl_wyl], val);
  delay(500);
  digitalWrite(lampka[wl_wyl], LOW);
}
}

//second program of the chain
void staly()
{
for(int wlacznik = 0; wlacznik < 7; wlacznik++)
{
  analogWrite(lampka[wlacznik], val);
}

delay(3000);

for(int wylacznik = 0; wylacznik < 7; wylacznik++)
{
  digitalWrite(lampka[wylacznik], LOW);
}
}


//third program of the chain
void srodek()
{
analogWrite(lampka[3], val);
delay(500);
analogWrite(lampka[0], val);
delay(500);
analogWrite(lampka[5], val);
delay(500);
analogWrite(lampka[1], val);
delay(500);
analogWrite(lampka[4], val);
delay(500);
analogWrite(lampka[2], val);
delay(3000);

for(int wylacznik = 0; wylacznik <7; wylacznik++)
{
   digitalWrite(lampka[wylacznik], LOW);
   delay(100);
}

}

void setup(){

  Serial.begin(9600);

  irrecv.enableIRIn(); //initialization of ir receiver

  //setting all LED as output pins
  for (int ust_lamp = 0; ust_lamp < 7; ust_lamp++)
  {
    pinMode(lampka[ust_lamp],OUTPUT);
  }
}

void loop()
{
  //turning on LEDs when its dark
  if ((analogRead(photo_res) < 500)&& (state == 1))
  {
    //we execute program which is currently set
    switch(program)
    {
      case 1:
        pierwszy();
        break;
     
      case 2:
        staly();
        break;
     
      case 3:
        srodek();
        break;
    }
  }

  else //if it's too bright outside we turn off the lights
  {
    for(int wyl_ciemnosc = 0; wyl_ciemnosc <7; wyl_ciemnosc++)
    {
     digitalWrite(lampka[wyl_ciemnosc], LOW);
    }
  }
  delay(1000);

  if (irrecv.decode(&results))
  {

   translateIR();
   irrecv.resume();

  }

}

Here's a video showing what's wrong with the program:

You don't have permission to edit metadata of this video.

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

RE: Changing value on PWN pins with IR remote messes up the program

Poster

Upload Preview

Ok

Cancel

Thanks for the video!  Makes the problem much more clear.

I would actually suspect the remote or receiver before a code problem.  I also don't know what IR coding sequences/protocols the remote is using to communicate; so I can't really say whether there's a difficulty with the hex registers being used.  Having said that, I find a couple of curiosities in the code:

1.  Are you intentionally continuing to use the photoresistor to control on/off states?  If the light level is too high it will interfere with your control -

     //turning on LEDs when its dark 

     if ((analogRead(photo_res) < 500)&& (state == 1)) 

2.  There is not an escape sequence if coherent button values aren't received by the Arduino

I don't have the "Robot IR Remote" library, so let's assume that's OK.  The code will compile fine when I account for that reference.  That brings me back around to the remote.  Two things to check are pretty mundane, but important:

1.  Have you either put known good alkaline batteries, or measured their voltage?  Don't use Carbon-Zinc ("Heavy-Duty", etc.), as these may not supply enough current for the LED's everything to work properly.

2.  Have you checked to see if there's a button stuck on the remote?  You can do this by looking at it the IR LED through a smartphone or digital camera (that lacks an IR filter).  If you're seeing pulses or a steady light when you're not pushing buttons then the remote is sending signals you don't intend.

There can also be a problem with the receiver photodiode...That's much harder to diagnose, unless you can put o'scope probes (or an analog multimeter) on the legs.  Have you done an old-fashioned KCL calculation?  If the only time the LED's are at maximum brightness is when controlled by the remote I would suspect there's not enough power on the ckt.  Just using a sketch to control the LED's seems to work fine; so I'd say everything is wired up and with correct polarity.

BTW: I like the project.  I'm particularly fond of anything that blinks LED's.  I'm simple that way.

Hopefully this is of some help.

Thank you for the reply!

The thing is the remote works fine up to the moment when I change the value of PWMs. Program I use is a modified version of one which I used with potentiometer and tact switches to change brightness and modes of the LEDs. With these hardware it worked solid, I don't know why it has problems with IR remote.

To answer your questions:

1. When I test remote this line is not used for the convenience, because I usually write code in the morning.

2. The values are analysed only when if (irrecv.decode(&results)) is true, which means that a value was sent by the remote. So I don't think I need an escape mechanism, or maybe I do?

Second batch of questions:

1. Do you mean batteries powering the circuit? For now it's power through USB.

2. I've checked remote with this simple program:

#include "IRremote.h"

int receiver = 11; // Signal Pin of IR receiver to Arduino Digital Pin 11

/*-----( Declare objects )-----*/
IRrecv irrecv(receiver);     // create instance of 'irrecv'
decode_results results;      // create instance of 'decode_results'

void setup()   /*----( SETUP: RUNS ONCE )----*/
{
  Serial.begin(9600);
  Serial.println("IR Receiver Button Decode");
  irrecv.enableIRIn(); // Start the receiver

}/*--(end setup )---*/


void loop()   /*----( LOOP: RUNS CONSTANTLY )----*/
{
  if (irrecv.decode(&results)) // have we received an IR signal?

  {
    translateIR();
    irrecv.resume(); // receive the next value
  }
}/* --(end main loop )-- */

/*-----( Function )-----*/
void translateIR() // takes action based on IR code received

// describing Remote IR codes

{

  switch(results.value)

  {

  case 0xFF629D: Serial.println(" FORWARD"); break;
  case 0xFF22DD: Serial.println(" LEFT");    break;
  case 0xFF02FD: Serial.println(" -OK-");    break;
  case 0xFFC23D: Serial.println(" RIGHT");   break;
  case 0xFFA857: Serial.println(" REVERSE"); break;
  case 0xFF6897: Serial.println(" 1");    break;
  case 0xFF9867: Serial.println(" 2");    break;
  case 0xFFB04F: Serial.println(" 3");    break;
  case 0xFF30CF: Serial.println(" 4");    break;
  case 0xFF18E7: Serial.println(" 5");    break;
  case 0xFF7A85: Serial.println(" 6");    break;
  case 0xFF10EF: Serial.println(" 7");    break;
  case 0xFF38C7: Serial.println(" 8");    break;
  case 0xFF5AA5: Serial.println(" 9");    break;
  case 0xFF42BD: Serial.println(" *");    break;
  case 0xFF4AB5: Serial.println(" 0");    break;
  case 0xFF52AD: Serial.println(" #");    break;
  case 0xFFFFFFFF: Serial.println(" REPEAT");break;

  default:
    Serial.println(" other button   ");

  }// End Case

  delay(500); // Do not get immediate repeat


} //END translateIR

which I found here: https://brainy-bits.com/tutorials/ir-remote-arduino/ . All buttons work fine and they're not stuck.

As I said before I don't suspect receiver or remote to be damaged or uncalibrated, because in other programs they work just fine.

I will try to rewrite the program from scratch, maybe there's something I can't see.

Once more thank you for checking the code, video and so lengthy reply.

Update #1

I've found a solution. It turned out that when I add irrecv.enableIRIn(); line to the code, it somehow interrupts PWMs 3 and 11. Without this line they work just fine. I'll try connecting receiver to other pins and if doesn't work I'll try another library for IR remote.

You're welcome!

Outstanding!  Glad you found the source of the problem, in any case.  Now that you state what you were seeing I start to understand.  Here is some info on the timers as implemented in the Atmega 328P, which you may already know.  Note the timers are different on the Atmega 32U4, so this wouldn't apply to a Mega, Leonardo, etc. (and certainly not the Due's SAM3X8E):

• Pins 5 and 6: controlled by Timer0
• Pins 9 and 10: controlled by Timer1
• Pins 11 and 3: controlled by Timer2

• Timer0 is an 8-bit timer, it can hold a maximum value of 255. It is used by delay() and millis(), so there are consequences when messing with it
• Timer1 is a 16-bit timer, it can hold a maximum of 65535 (an unsigned 16-bit integer). The Arduino Servo library uses this timer
• Timer2 is an 8-bit timer used by the Arduino tone() function

And, of course, the IRremote library uses TIMER_RESET, so depending on which timer it uses it can conflict with the associated pins.

Thank you so much for  the explanation. So these pins won't work with the remote hooked up. Too bad. But, I've ordered Arduino MEGA so I'll have more PWMs to use in the near future. Thanks you again for the contribution. I think the topic can be closed.

You're most welcome.