Feature Request

[DH*]

I asked for this a few years back from NetMedia. Frank Manning reacted positively but nothing ever came of it.

I (and I'm sure others) would like to send IR codes to control AV gear, etc. It would be nice to have a built-in function to accomplish this. Something like:

PutBurst(freq, cycles, state)

where freq is the IR carrier frequency in kHz (32-57kHz), cycles is the number of carrier cycles, and state is 1 for carrier on and 0 for carrier off.

[dkinzer]

I don't yet understand what this would actually do or how it would be used. Does it implement an OutputCapture() on pin 27 where the pulse data is inferred from the frequency and number of cycles? If so, is the duty cycle 50%?

[DH*]

For freq=38kHz, cycles=19, state=1 it would output 500µs of 38kHz (19 * 1/38000) or a 0.5ms pulse of IR.

For freq=38kHz, cycles=57, state=0 it would output nothing for 1500µs (57 * 1/38000) or 1.5ms of no IR.

If the output capture pin is the only choice then it would need to use that pin. The duty cycle for the carrier can be 50% or less.

It might have been clearer had I used periods (i.e. 1/freq) instead of cycles. This parameter is only used for timing purposes. Philips Pronto CCF files which have become the lingua franca of IR codes use the cycles terminolgy so anyone familiar with them would grasp my intent. And, most MCUs can count cycles directly. It's also the way most manufacturers describe their IR protocols. For example: http://www.cpcares.com/pdf/UPD6121G-001.PDF

One way to do it might be to add a freq parameter for OutputCapture but I would prefer being able to define each pulse and space individually as then all you need to know is how to define a leadin sequence, a "1" bit, a "0" bit and a leadout sequence and you can define any code for any IR protocol with just a few bytes. The example 0.5ms/1.5ms pulse/space sequence is a "1" bit in several IR protocols.

If it were possible to make freq=120kHz, it could even be used for direct X-10 (through an isolation transformer) without needing a PL513/TW523. Jack Schoof said it was possible but I couldn't convince him to add it.

[dkinzer]

So, if I understand correctly, you would need two calls (one with state=1 followed by one with state = 0) to emit the IR for pulse for one bit. If that is the case, perhaps it would be better to use something like:

[DH*]

In general, since they are always in pulse/space pairs, your suggested PutBurst format will work. The off state can be adjusted to account for overhead. I would still prefer being able to set CyclesOn separately. PulseOut on Pin 0 could be used to handle spaces. In many cases, the pulse length is fixed with the space width determining 1 or 0.

Freq would make for more readable code but a table relating units to frequency would suffice. Most IR receivers have fairly wide bandwidth (±5kHz is typical) so the accuracy of the carrier frequency is not critical. Freq also has the advantage that Cycles/Frequency=burst (or space) duration.

The lower the duty cycle, the more current that can be used to drive the IR emitter. Most can handle several amps if the duty cycle is low enough. This really isn't necessary, though. I was able to get 100' range using a single emitter and only the 3.3V available in a PDA.

I hadn't considered the faster speed of the ZX. It might be possible to do this using OutputCapture to define the frequency and CyclesOn and PulseOut on Pin 0 to define CyclesOff. There would obviously be more overhead.

If you can meet the X-10 specs with X10Cmd, I would think this would be possible at 120kHz.

BTW, any estimate when you'll have X10 input and output working in the background?

[stevech]

If Don or anyone wants it - a couple of years ago I wrote a lot of C code for the AVR2313 to do IR. This software fits in a 2313's flash and meager RAM.

It listens for IR and sends the pulse times to a PC via the serial port. It also sends a two-byte equivalent of the IR data (key code) out the serial port. So the PC can take either raw timing data or the key code.

To send IR, it takes the same timing data from the PC and generates an IR data stream. To do so, it generates a 38KHz waveform on a timer. In the data ones and zeros, it uses the pulse duration to turn on/off the 38KHz to recreate the timing, and pass that to an IR diode to transmit.

Neither of these care about the remote's key coding or bits per keycode.

It's written in C and I will upload it or email it if anyone wants.
The hardware was just a $3 IR receiver and to transmit, just an IR diode and transistor connected to the AVR timer output.

WOrked well. But I bought an "irMan" unit for $30 or so and I use that.
The USB-UIRT and others exist now, and are cheap.

[stevech]

I forgot to say - the 38KHz is generated by the timer without the AVR CPU's help. The AVR timer is setup in the "toggle output" mode, meaning this output pin has 38KHz. The CPU just stops and starts the timer to create 38KHz bursts, according to the needed bit-times.

[spamiam]

[DH*]

And I do the same thing using a PIC12F683 ($1.56) and its hardware PWM. But that requires added hardware and, if you want to vary the frequency, additional pins to communicate with the PIC.