IR sender and receiver both work independently, but decoding fails when used simultaneously

[szygmunt]

Hello,

I'm experiencing an issue with infrared communication on my Raspberry Pi running Raspberry Pi OS Bookworm.
Both the IR receiver and transmitter are connected via GPIO, and both are correctly enabled using dtoverlay=gpio-ir and dtoverlay=gpio-ir-tx in config.txt.

Each component works correctly on its own:

• When using an external IR remote (Onkyo audio system), I can successfully and repeatedly receive key codes using ir-keytable with a proper TOML map (/etc/rc_keymaps/onkyo.toml).
• I can also send IR codes using ir-ctl -k /etc/rc_keymaps/onkyo.toml, and both the Onkyo receiver and ir-keytable recognize them properly.

---

❗ The problem:

When I try to use both transmitter and receiver at the same time, things break.

Example test:

1. In terminal window 1:

   ir-ctl -r -d /dev/lirc1

2. In terminal window 2:

   ir-ctl -K KEY_PLAY -k /etc/rc_keymaps/onkyo.toml

→ Instead of receiving clean pulse/space values, I get corrupted or nonsensical data:

+9008 -30854
+188 -20583
-20690
+183 -21426
-20073
+170 -30784
+9033 -32545
+155 -22284
+200 -28634
+9030 -4473 -55569 +194 -23516
+182 -25004
+162 -27080

Each line corresponds to a single IR send command. It seems the decoding of the received signal becomes completely unreliable when the IR transmitter is active.

---

Additional info:

• This same issue already existed on Bullseye, but sometimes a received signal was decoded correctly (maybe 1 in 5 attempts).
• On Bookworm, the decoding never works during transmission.
• Hardware and wiring are verified and functioning.
• Both ir-keytable and ir-ctl are properly configured.
• The issue seems related to concurrent use of the IR receiver and transmitter via GPIO.

[lurch]

@6by9 Does this count as a Linux bug? (if so, could you transfer it please?)

@szygmunt I've never used an IR transmitter or receiver with my Pi, but is it possible that the receiver is accidentally seeing signals (or partially-reflected signals) from the transmitter?

[szygmunt]

Thanks for the reply!

Yes, that was one of the first things I considered — I’ve tested with the IR transmitter and receiver physically separated, even placing a barrier (e.g. thick cardboard) between them to block any possible direct or reflected IR signal.

The issue persists regardless of physical placement, even if the receiver is shielded or moved to another GPIO pin.

Also, the distorted data appears even when the transmitter fires into "empty space", and there is no meaningful IR input from the environment.

As a control test, I also connected an external USB DVB-T dongle (based on RTL2832) with a built-in IR receiver, and it successfully receives clean, correctly decoded signals from the GPIO-connected IR transmitter.
This confirms that the transmitter and signal encoding are functioning properly.

In other words, it doesn't look like an issue of signal reflection — it seems more like a low-level timing or resource conflict when both /dev/lirc0 and /dev/lirc1 are active.

Would you suggest any debugging steps at the kernel level, or ways to log what's happening with the IR subsystem during simultaneous TX/RX?

I’m genuinely interested in resolving this and happy to assist in any way I can — including running additional tests or collecting data that could help identify the root cause.

[lurch]

@szygmunt I'm not able to provide any additional help myself, but in preparation for help from somebody more knowledgeable than me, it'd probably be helpful if you could provide information about which model of Raspberry Pi you'e using, which kernel version you're running, what exact IR receiver & transmitter hardware you've got connected to your GPIO pins, the exact settings you've added to config.txt, etc.

[szygmunt]

Hello,

Thanks for the quick reply! Here are the details that might help diagnose the IR issue:

1. Raspberry Pi model:

Raspberry Pi 3 Model B Plus Rev 1.3

2. Kernel version:

Linux pi 6.12.34+rpt-rpi-v7 raspberrypi/bookworm-feedback#1 SMP Raspbian 1:6.12.34-1+rpt1~bookworm (2025-06-26) armv7l GNU/Linux

3. IR hardware used:

• IR receiver: TSOP38438 (38 kHz, NEC-compatible), recently purchased from TME. It replaced the original receiver on a Chinese PiFi Digi+ v1.0 board.
• IR transmitter: IR LED (model IR17-21C/TR8) connected to GPIO via a series resistor.

4. GPIO pins used:

• Receiver connected to GPIO 26
• Transmitter connected to GPIO 16 (through a series resistor of 820 Ω)

5. Configuration in config.txt:

dtoverlay=gpio-ir,gpio_pin=26
dtoverlay=gpio-ir-tx,gpio_pin=16

6. Additional info about the transmitter resistor:
   Initially, I tried using a 150 Ω resistor (the lowest safe value to maintain GPIO current within limits), but currently I use an 820 Ω resistor to keep the current very low, as the transmitter is very close to the Onkyo receiver and the IR receiver itself.

Please let me know if you need any more info!

Best regards,
Szymon

[szygmunt]

Hi,

I just wanted to check whether this issue has already been reported elsewhere, as it seems to be related to driver bugs rather than the Raspberry Pi software itself. If it has been reported, would you mind sharing the link or providing some guidance on where I can track progress on its resolution?

[pelwell]

From a discussion in another forum:

I don't see any locks that would be held for the tx side - bcm2835_gpio_set uses the SET and CLR registers, avoiding the need to interlock. Similarly, bcm2835_gpio_get just reads the LEV register. Neither driver uses locking itself. Unless IRQs are being masked and unmasked there should be no spinlock usage at all, unless it's in the higher levels of GPIOD, etc.