Is there a reason for unstable button numbers of an IR remote?


I wrote a remote class where I identify the pressed number of the remote to set states. But however I get never the same number of the pressed key.

For example I press the number '1' and on the serial interface shows this:


And it should look like this:

16724175 // Button 1
16724175 // Button 1
16724175 // Button 1
16724175 // Button 1
16724175 // Button 1


I am using an arduino UNO board and the standart remote of the starter kit. There is no name just 'SPECIAL FOR MP3'.

Some more infos

Ok, in my first project I used the code from Noreddine Kessa(Example Project) which works fine. Next I copied some code in my new class 'IRControl.cpp' ( you can see below). Then I created an object IRControl in the main.cpp and run the menu() in the loop.


 * IRControl.h
 *  Created on: 04.04.2016
 *      Author: David

#ifndef IRCONTROL_H_
#define IRCONTROL_H_

//Remote Defines
#define buttonON 16753245
#define buttonMode 16736925
#define buttonSoundOff 16769565
#define buttonPlayStop 16743045
#define buttonTrackBack 16712445
#define buttonTrackForward 16761405
#define buttonEQ 16769055
#define buttonMinus 16754775
#define buttonPlus 16748655
#define button0 16738455
#define buttonRepeat 16750695
#define buttonJSD 16756815
#define button1 16724175
#define button2 16718055
#define button3 16743045
#define button4 16716015
#define button5 16726215
#define button6 16734885
#define button7 16728765
#define button8 16730805

#include "IRremote.h"
#include "wiring_private.h"

enum zustaende{Motor1, Motor2, Motor3, Sleep};
extern int zustand;

class IRControl {
    IRrecv *irrecv;
    decode_results remoteValue;
    IRControl(int RECV_PIN);
    virtual ~IRControl();
    void menu();

#endif /* IRCONTROL_H_ */


* IRControl.cpp
 *  Created on: 04.04.2016
 *      Author: David

#include "IRControl.h"

IRControl::IRControl(int RECV_PIN) {
    // TODO Auto-generated constructor stub
    irrecv = new IRrecv(RECV_PIN);
    pinMode(RECV_PIN , INPUT);

IRControl::~IRControl() {
    // TODO Auto-generated destructor stub
    delete irrecv;

void IRControl::menu() {
    if (irrecv->decode(&remoteValue)) {
        //lReceived = remoteValue.value ;
                case button1:
                    zustand = Motor1;
                    //digitalWrite (LED1, HIGH); // for control

                case button2:
                    zustand = Motor2;
                    //digitalWrite (LED2, HIGH);
                case button3:
                    zustand = Motor3;
                    //digitalWrite (LED3, HIGH);

                case button0:
                    zustand = Sleep;

                default: break;
        irrecv->resume(); // Receive the next value

Where the problem could be

I think there could be a problem with the IRrecv *irrecv;. But i'm not sure.

Thanks for your help

  • 1
    I'd say you're just "receiving" random numbers. That most likely means your hardware setup is not what it should be. Unfortunately your answer only mentions software so nothing to comment about until you explain your hardware setup. And instead of immediately complicating things with complex code, I usually just start with the library's example code and check that my hardware setup is OK. Only then I continue with the software. Apr 4 '16 at 19:27
  • there are a number of ir protocols, you need to understand which one you are using, and use the right software/hardware and/or settings. you cant just randomly throw ir at some random tool and expect it to work.
    – old_timer
    Apr 4 '16 at 19:32
  • it not giving consistent results indicates that you have not matched up the receiver (protocol, frequency, etc) to the transmitter (the remote).
    – old_timer
    Apr 4 '16 at 19:32
  • Thanks for your answers. However I used the same hardware setup for both projects. The problem appeared as I exported the code to my new class.
    – Deweird
    Apr 4 '16 at 19:39
  • So I guess the general setting should be fine and there is an issue in the code.
    – Deweird
    Apr 4 '16 at 19:40

Please post the code where you call the library. In particular where do you make an instance of IRControl?

I am guessing you are doing it at global scope which means you are probably running into the C++ static initialization order fiasco.

What it is: http://www.parashift.com/c++-faq/static-init-order.html

How to prevent it: http://www.parashift.com/c++-faq/static-init-order-on-first-use.html

To prevent this, you should not be doing this in the class constructor:

irrecv = new IRrecv(RECV_PIN);
pinMode(RECV_PIN , INPUT);

Instead, make a begin function (like most Arduino classes do) and call that from setup.

  • btw. is parashift.com/c++-faq/static-init-order.html down?
    – Deweird
    Apr 5 '16 at 19:29
  • Ok it works. I i create the objects in the main.cpp and changed my code in the IRControl. I think your answer was a good help. Should i update my question and add my solution?
    – Deweird
    Apr 6 '16 at 13:00
  • btw. is parashift.com/c++-faq/static-init-order.html down? looks like it. It's the top Google hit for C++ static initialization order fiasco though.
    – Nick Gammon
    Apr 6 '16 at 21:51
  • Should i update my question and add my solution? - not really, because the question part is for the question. If you want to amplify on my answer with example code, etc. then make your own answer and explain what you had to change and why. It doesn't make a lot of sense if a question answers itself.
    – Nick Gammon
    Apr 6 '16 at 22:02
  • What you can do, if my answer was largely correct, but you want to add more detail, is to edit my answer and add in the detail. The edit will be added to an edit queue, but it will no doubt be accepted. That way the answer is fleshed out. If you think that your code is substantially different to what I posted, then post it as a separate answer.
    – Nick Gammon
    Apr 6 '16 at 22:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.