Issues related to Bit-banging transceiver modules

Question

I have two Infrared Transceiver modules from TFDU4101-TR3 on two separate boards each interfaced to ATMega164PA microcontroller. To drive these transceivers an endec is needed which I have not used in my design due to budget constraints.

So what I am trying to do is bit-banging. The RX and TX follow normal standard, RX is active low and TX is active high. I am toggling the TxD pin one 'Board A' 50 times at 5 Khz to send 50 pulses to the receiver. On 'Board B' I have implemented a PIN change interrupt which should technically receive 100 pulses (2 pulses for each transmit pulse that it receives). This is not the final design, I just learning and experimenting how to transmit data from one board to another.

Now the problem is that when I send 50 pulses from Board A to Board B, I do not get 100 pulses, but instead I sometimes get 90 or 81 or 98. In short I don't get the intended number of pulses. Is there something wrong with my approach?

Please let me know if any further information is needed.

Answer 1

The general approach sounds OK but you need to be careful that you don't exceed the maximum transmit pulse length. It appears from the datasheet 20 uS is a typical pulse length and if exceeded by too much you can see it will cause the LED driver to be disabled:

This Schmitt-Trigger input is used to transmit serial data when SD is low. An on-chip protection circuit disables the LED driver if the TXD pin is asserted for longer than 50 μs (max. 300 μs).

So assuming your 5 KHz is a square wave you'll have exceeded that pulse duration. Once that's sorted out things should be more reliable, although the last time I used an IrDA transceiver I was getting on or two percent of packets that were corrupted so it's worth considering error detection depending on what you're doing.

It's also worth noting that some Atmel (and other) microcontrollers have a USART mode that complies with IrDA timing, although after a quick look at the datasheet that particular part doesn't appear to have that feature.

Answer 2

The TFDU4101 is designed to transmit data at 115.2 kbit/s. That is one of the IrDA standard speeds. So the device is optimised around that.

So one bit duration is about 1,000,000us/1152.kbit/s = 8.7us

The datasheet says the typical RXD (received) pulse width is specified as 2.2us, which would mean 4 pulses per bit of a roughly 460,800kHz carrier signal. So it looks like it adds up.

You don't have to send data at that rate. However aim to use similar base-carrier modulation, and then the chip won't be fighting you. Use an integer number of cycles of that carrier frequency to send your data, with a distinctive number of cycles to represent 0 an d 1, and it should be reasonably robust and reliable. Though you might need to use error detection as well.

460,800kHz is quite high-speed to bit bang, though it is do-able. You might start by trying to send data that way.

I try to get the base carrier modulation signal done in hardware to reduce the load on the CPU.

The way I do transmission is to set up an MCU timer to get be as close to the base-modulation cycle time as practical, and use that to drive the transmitter LED. Some of the ATmel timers let you set the maximum count, and with a capture/compare value of 1/2 maximum count, it'll generate a square wave. (An alternative is to divide the clock, using a pre-scale value)

Then I use the capture/compare register value (0 or max, depending on the modulation scheme) to gate that signal with the data. The base carrier signal will be generated correctly using a compare value of 1/2 maximum count, even if my software is a bit busy.