1

I installed the current lirc package (0.9.0~pre1-1.2) on a Raspian jessie (no pixel) (everything updated and upgraded) and connected to the (lirc default) GPIO ports:

  • to gpio port 17 - an IR LED via transistor etc
  • to gpio port 18 - an IR receiver nodule

The receiver part works perfectly:

  • mode2 command receiving raw data from transmitter
  • the IR code recognition of previously recorded keys works

However, the IR LED only works only while lirc is not involved:

  • a shell script can switch the IR LED on and off with no problem

The only thing that doesn't work:

  • irsend does not make the IR transmitter emit anything, however no error message is shown

So the hardware, especially the IR LED is definitely working, while lirc cannot make the LED emit any configured IR code.

Please note that this seems to be a duplicate of

Unfortunately it is not. The "solution" provided there was placing the data for /etc/modules into the file /etc/modules-load.d/lirc_rpi.conf. I tried that as well, but it makes no difference.

Any help is greatly appreciated!

Configuration data follows - if any other data is required, I'd be happy to add it! TIA!


System and lirc Configuration

Extract fom: /boot/config.txt

dtoverlay=lirc-rpi,gpio_in_pin=18,gpio_out_pin=17,debug=on

Extract of: /etc/modules

lirc_dev
lirc_rpi gpio_in_pin=18 gpio_out_pin=17

(not sure if that is necessary at all, does not make a difference if this is not configured!? Any hint apppreciated)

All active entries in: /etc/lirc/hardware.conf

LIRCD_ARGS="--uinput"
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"
LIRCD_CONF=""
LIRCMD_CONF=""

Some system output

1) The driver is loaded, output of following command right after boot, output of: dmesg | grep lirc

lirc_dev: IR Remote Control driver registered, major 245
lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
lirc_rpi: to_irq 178
lirc_rpi: auto-detected active low receiver on GPIO pin 18
lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
lirc_rpi: driver registered!
input: lircd as /devices/virtual/input/input0
lirc_rpi: Interrupt 178 obtained

2) the service is started and running, output of: systemctl status lirc

? lirc.service - LSB: Starts LIRC daemon.
   Loaded: loaded (/etc/init.d/lirc)
   Active: active (running) since Mo 2017-06-12 20:04:03 CEST; 2h 58min ago
  Process: 377 ExecStart=/etc/init.d/lirc start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/lirc.service
           +-437 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --uinput

3) the modules are loaded, output of: lsmod | grep Module;lsmod | grep lirc

Module                  Size  Used by
lirc_rpi                8453  3
lirc_dev               10211  1 lirc_rpi
rc_core                23776  1 lirc_dev

I followed the troubleshooting steps in the (outdated) manual at http://aron.ws/projects/lirc_rpi/ to get some more information.

Output of: cat /sys/kernel/debug/gpio

gpiochip0: GPIOs 0-53, parent: platform/20200000.gpio, pinctrl-bcm2835:
 gpio-35  (                    |?                   ) in  hi
 gpio-47  (                    |?                   ) out lo

I have seen that output also in this case:

This user is as irritated by that output as I am - can somebody please tell why gpio-35 and gpio-47 are listed here? shouldn't it be gpio-17 and gpio-18?

Output of: cat /proc/interrupts | grep lirc

178:        875  pinctrl-bcm2835  18 Edge      lirc_rpi

This matches the dmesg output on having obtained interrupt 178

Any other dmesg output of lircd, no matter what action, is repeatedly (most likely due to the debug option set) only

lirc_rpi: SET_SEND_CARRIER
lirc_rpi: in init_timing_params, freq=38000 pulse=13157, space=13158
lirc_rpi: SET_SEND_DUTY_CYCLE
lirc_rpi: in init_timing_params, freq=38000 pulse=13157, space=13158
cla
  • 83
  • 1
  • 6
  • After having tested the identical system & lirc config (all config changes/test commands scripted!) on various combinatons of hard- and sofware during the last 5 days * on another identical Pi Model B * on raspbian wheezy and jessie * with LAN and WLAN * with a stronger power supply * with/out IR Receiver, it did not work. Yesterday I tried a different IR receiver (TSOP4838 instead of TSOP31436), **IT SUDDENLY WORKED**. Then I tested more combinations, incl. the TSOP31436 again - **it still worked and still does today**. The config is the same as above, so I can't tell why. Any suggestions!? – cla Jun 15 '17 at 08:42
  • Same problem showed up again, when I tried to extend with a second IR LED. While the above circuit still works, the other one on the breadboard shows the poblem described above - no matter if I use one or two IR LEDs. It is just weird... – cla Sep 07 '17 at 18:49

1 Answers1

2

Having restarted testing again after some time for to build up a test copy of the circuit, the problem occurred again. And now, after some more month of much testing, having asked lots of people for help (no one could help), even having purchased and built up a cheap mini USB oscilloscope kit for to examine the hardware further, I finally found the solution.

Long story short: everything in the configuration was correct, and all of the attached hardware was fine. The problem was the testing script - see my remark on

"a shell script can switch the IR LED on and off with no problem"

and as I did not put it in the above description, nobody could have found the solution myself....

The script uses the pseudo files in /sys/class/gpio, see an example here:

At the end of the script a command writes to /sys/class/gpio/unexport for cleanup purposes, and this step seems to reset a GPIO port to always end up in the state of being configured for input. As a result LIRC is not longer able to control this GPIO port, since it seems to configure the GPIO port for output only during system boot, and after that always expecting the port to be in that state.

I tracked the problem down to this point by using the gpio utility from the wirinpi package (install with sudo apt-get wiringpi), executing gpio readall and checking for differences.

The time when everything suddenly worked again, I simply may have fogotten about to run my testscript before testing LIRC, which I otherwise always did...

Luckily the problem with the port configuration can easily be fixed without having to reboot the system. Again I use the gpio utility to reset reset the used port for output, where in the below example

  • the default output port 17 for LIRC is used and
  • the parameter -g lets the utility use the ordinary GPIO port numbering and not that very different one of the wiringpi package and library

Here is the command, after having executed this last in my test script, LIRC can properly send IR codes again:

gpio -g mode 17 out
cla
  • 83
  • 1
  • 6