0

I'm trying to verify the pulse width of an IR receiver I "borrowed" from one of those cheap RGB controllers (like thisone) with an arduino nano. But the data I'm getting right now is about 3.4KHz and not the 38KHz I expected.

I'm trying to measure it by connecting the data pin of the IR on INT0 and listening for any change, if the pin goes low I start a measurement, if it goes high I stop the measurement and read out the value.

I'm using Timer1 and no prescaling

My code is as followes

#include <util/delay.h>

#define inpin 1 << PIND2
#define timeron 1 << CS10 //timer no prescale

bool wasTiming = false;
short i = 0;

volatile short timings[20];
volatile bool print = false;

volatile short seconds = 0;

int main()
{
    USART.begin();

    _delay_ms(500);
    USART.writeln("Arduino online");

    DDRD = 0;

    TCCR1A = 0; //no compares, normal counter mode
    TCCR1B = 0; //clock off

    EICRA = 1 << ISC00; // Any change INT0 (PD2)
    EIMSK = 1 << INT0; // INT0 interrupt enable

    sei();

    char buff[20];
    for (;;)
    {
        if (print)
        {
            print = false;

            for (short j = 0; j < 20; j++)
            {
                sprintf(buff, "% 6d ticks", timings[j]);
                USART.writeln(buff);
            }
        }
    }
    USART.end();

    return 0;
}

ISR(INT0_vect)
{
    if (PIND & inpin) //pin high
    {
        if (wasTiming)// 
        {
            TCCR1B = 0; //timer clock off
            timings[i] = TCNT1;
            TCNT1 = 0; //empty timer register
            wasTiming = false;

            i++;
            if (i == 20)
            {
                print = true;
                i = 0;
            }
        }
    }
    else // pin low
    {
        if (!wasTiming)
        {
            TCCR1B = timeron; //timer clock on
            wasTiming = true;
        }
    }
}

and the output data is

 13902 ticks
  8865 ticks
  9961 ticks
  8877 ticks
  9968 ticks
  9842 ticks
  8506 ticks
  9896 ticks
  9585 ticks
  9865 ticks
  9541 ticks
  8853 ticks
  9545 ticks
  8888 ticks
  9885 ticks
  9954 ticks
  8515 ticks
  9885 ticks
  8909 ticks
  9874 ticks

on average that looks like about 9500 ticks, which leads me to the following calculation: (16,000,000 / 9,500) * 2 = 3,368.4Hz

Am I doing something wrong here? Or is the data that I'm getting correct, in which case, how would I go about turning that into 1's and 0's?

I'm not really looking for off-the-shelf solutions, half the fun of doing this is figuring it out myself. Eventually I'm gonna build my own RGB controller with this to replace that cheapo thing I already have (it has a few flaws I would like to correct).

migrated from electronics.stackexchange.com Jan 30 '17 at 0:05

This question came from our site for electronics and electrical engineering professionals, students, and enthusiasts.

  • 38kHz is the carrier - the data switches the carrier on and off. The output from the TSOP is data. – JIm Dearden Jan 29 '17 at 12:11
  • You need to evaluate the IR waveforms using an oscilloscope. Without this you are running blind. Also consider that the IR remote control is likely to be outputting various pulse widths as part of the protocol that it uses. – Michael Karas Jan 29 '17 at 12:12
  • @MichaelKaras I don't have one and have no-one in my area has one either, I would've used one if I could – Gelunox Jan 29 '17 at 12:15
  • Your data seems about right. If you look at the data sheet of an IR receiver chip, it'll state that about ten cycles (of 38 kHz) is required to detect one baud. – glen_geek Jan 29 '17 at 16:30
0

You mistakenly believe that the carrier frequency of 38 kHz should be available at the data output pin of the infrared detector chip. These chips provide a logic output indicating the presence of 38 kHz. Most are frequency-selective, being more sensitive at one frequency somewhere between 35 kHz - 60 kHz.
A data sheet pulled at random specifies typical pulse bursts that might be used to encode digital data (pulse burst timing highlighted in red):
infrared remote receiver pulse burst timing
In your case, \$f_o\$ might be close to 38 kHz. No fewer than six cycles \$t_{pi}\$ are recommended for the length of one baud. Perhaps your transmitter includes a few more cycles (ten or eleven?) to be safe. The receiver circuitry requires about five cycles before commit, \$t_d\$. Hopefully, a similar delay at end-of-pulse occurs, but the graph at right suggests the end-of-pulse extends a little longer than \$t_d\$. However, pulse width is impressively constant over five magnitudes of infrared intensity.
Note that the presence of a burst of 38 kHz from the transmitter most often sends the output of the receiver to a logic low. No optical signal yields a logic high at receiver output, sometimes with a fast false-detect glitch (which should be rejected if its length is short). A large-value pull-up resistor added between output pin and Vdd may be required to ensure that an idle receiver goes to logic high.
You will still have to determine how these pulse bursts are encoded into logical bits. Many protocols exist, some use pulse position, others use pulse length encoding.

  • I was indeed mistakenly believing the frequency was available at the data pin. I have since discovered that the data I'm receiving is encoded in pulse-distance and am now able to extract binary data from it. Thank you! – Gelunox Jan 30 '17 at 10:58

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.