Figuring out IR sensor PWM frequency with Arduino 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 &lt;util/delay.h&gt;

#define inpin 1 &lt;&lt; PIND2
#define timeron 1 &lt;&lt; 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 &lt;&lt; ISC00; // Any change INT0 (PD2)
    EIMSK = 1 &lt;&lt; INT0; // INT0 interrupt enable

    sei();

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

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

    return 0;
}

ISR(INT0_vect)
{
    if (PIND &amp; 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).
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):

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.