http://imageshack.us/photo/my-images/19/img01373201209152153.jpg/
This is an ultra-cheap (significantly under 10 USD) bare-bones selfmade Arduino replacement:

Mini Breadboard

Prolific USB to Serial adapter with connector cable (betemcu.cn)

ATmega168 microcontroller with Arduino LilyPad bootloader

IR LED

The parts can be ordered from China on eBay.

While this works, I found that I can drastically increase reach by using a crystal (for timing precision), a 2N222A NPN transistor (to amplify the pin's signal) and a 100uF electrolytic condensator (to deliver enough current to pulse the LED). The transistor is connected to the pin using a resistor. For an example schematic, see the TV-B-GONE. Also, I found that I can use multiple IR LEDs in parallel.

http://imageshack.us/photo/my-images/19/img01373201209152153.jpg/
This is an ultra-cheap (significantly under 10 USD) bare-bones selfmade Arduino replacement:

Mini Breadboard

Prolific USB to Serial adapter with connector cable (betemcu.cn)

ATmega168 microcontroller with Arduino LilyPad bootloader

IR LED

The parts can be ordered from China on eBay.

While this works, I found that I can drastically increase reach by using a crystal (for timing precision), a 2N222A NPN transistor (to amplify the pin's signal) and a 100uF electrolytic condensator (to deliver enough current to pulse the LED). The transistor is connected to the pin using a resistor. For an example schematic, see the TV-B-GONE. Also, I found that I can use multiple IR LEDs in parallel.

If using a crystal increases range significantly, you have some very finicky equipment indeed. The passband for an IR demod is wide enough to show minimal effect at 5% or more frequency error. That said, the envelope timing may be more critical in some equipment, though this is more common with carrier-less protocols.

Also, running LEDs in parallel is not as good as you might think. LEDs in parallel may not share current equally due to small differences in their V/I curve. It's best to use individual series resistors, one for each LED. That acts as a first order load balancer and can cut the unequal current from 60% or more, down to the 5-10% range.

If you have not done so, is it possible to combine an infrared transmitter and receiver on one Arduino board in the same project?
Also, are there any plans to include identification of the infrared remote carrier frequency on reception of an infrared signal (with the use of a phototransistor which does not filter out the infrared carrier frequency unlike an infrared receiver module)?_________________"The best thing possible to do with knowledge is to share it".

If you have not done so, is it possible to combine an infrared transmitter and receiver on one Arduino board in the same project?

There is a number (dependiing on model, typically two-digit) of so-called GPIO-pins that can each be used either for sending, or receiving.

Quote:

Also, are there any plans to include identification of the infrared remote carrier frequency on reception of an infrared signal (with the use of a phototransistor which does not filter out the infrared carrier frequency unlike an infrared receiver module)?

I have hooked up the hardware since almost a year ago... To my knowledge, no-one has done it yet, should be possible with moderate programming and hardware skills. Hope to get some time soon.

BTW. my next program, called IrScrutinizer, will support direct sending and receiving of IR signals with the Arduino, receiving unfortunately only using a demodulating receiver (at least for the first version).

If you have not done so, are there plans to incorporate the IR sender and receiver program in the same Arduino board (of which the mode can be selected with a serial port command e.g. "RX" for IR receiving mode and "TX" for IR transmitting mode)?_________________"The best thing possible to do with knowledge is to share it".

In my UEI remote (URC-7562-B00), it has a S3C80 CPU with an 8MHz crystal.
Also, in RemoteMaster (viewing Manual Settings of protocol), the boxes with uSec values cannot have decimal places.
This should not be a problem for a 16MHz ATmega328-based Arduino (e.g. Uno - a compact version of the Uno is the Freetronics LeoStick).
In a book titled "Practical Arduino", a digital read can be accomplished in 1uS on the Uno (meaning we are not using analog ports).
So I have a thought that the Arduino should determine the carrier frequency and its Carrier On/Off periods without any problem, with the more powerful host computer processing the raw data transmitted from the Arduino._________________"The best thing possible to do with knowledge is to share it".

You are probably talking about measuring the period time, or even on- and off-times. I think the IrToy does something like this. It can probably be done, just go ahead! However, I suspect the measurement to be somewhat unreliable, one reason is the relatively slow switching times (~ 1 microsecond) of current IR leds. But feel free to prove me wrong! (The results I have gotten from IrToy + IrScrutinizer are satisfying.)

But I would be inclined to implement Kevin Timmerman's IrWidget idea instead: It instead counts the number of pulses in every 100 microseconds interval, and transfers these as raw numbers over a serial connection to a host computer, that is then computing the frequency from a large number of samples. I have given a link in a previous message. Both Kevin's IrScope and my IrScrutinizer (really, the package HarcHardware) implements the host computations. If you can implement something in this sense IrWidget compatible, you may be able to use IrScope and/or IrScrutinizer with no or small changes.

Both IrScope and IrScrutinizer are free software with GPL3-license. The package HarcHardware is included in binary form in IrScrutinizer, will be released later this year in source form. PM me if you (or anyone else) do not want to wait.

So I have a thought that the Arduino should determine the carrier frequency and its Carrier On/Off periods without any problem, with the more powerful host computer processing the raw data transmitted from the Arduino.

I've done such an Arduino project which uses the Input Capture feature (ICP) with a time resolution of 1 / 16MHz. It captures a whole waveform and buffers it till the end. Depending on the RAM of the ATMega it can capture up to 3600 level changes (with an ATMega2560). An ATmega328 can capture 1080 level changes.

Great job! I knew this could be done. One first comment is that you are using a non-inverting sensor, while "most" other seem to be using inverting (light on -> output low) sensors, so it would be useful to have one user switch in the software allowing for usage of inverting sensors.

One first comment is that you are using a non-inverting sensor, while "most" other seem to be using inverting (light on -> output low) sensors, so it would be useful to have one user switch in the software allowing for usage of inverting sensors.

The SDP8600 sensor which emits the raw, modulated waveform is non-inverting, but the demodulating TSOP1738 emits the inverted waveform. The Arduino code currently only handles positive logic, but it can be easily changed to support negative logic.

Barf wrote:

I will try to support your stuff in IrScrutinizer.

That would be very nice!

The original project was meant to be an example how to use the Input Capture mode, so it might need to be adapted to fit your needs.
What exactly do you need? Is it just different formatting or other units (e.g. cycles instead of nanoseconds)?

In the end, I need frequency (a number in Hz), and the "demodulated" times in microseconds. If the duty cycle is available, I "take" it too.

I made a version which prints the output in the ICT format, but I don't have any IR diode with me, so my real tests have to wait for some days.
You can find it in the diagnostic area.
It contains some test data, so it can be used without an IR diode. To enable the test data, remove the comment before the #define USE_DUMMY_DATA.