User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Possibility for multiple instances of LIRC?

Wed Feb 14, 2018 9:08 am

I am looking into the possibilities for a Raspberry Pi to do IR communications in 4 different directions, both transmitting and receiving for each direction.

These are what I've found so far and stuck at the last one,
  1. bengtmartensson/lirc_rpi supports multiple transmitters, but not multiple receivers.
  2. https://www.mythtv.org/wiki/Multiple_LIRC_Drivers gives us a way to run multiple LIRC daemons, each managing it's own /dev/lirc* device, but it does not know GPIO, hence lirc-rpi.
  3. Thanks to PhilE in previous thread theoretically we can patch the device tree to load multiple sets of parameters, but it seems lirc-rpi did all the GPIO to /dev mappings and I have no idea where to tap into the driver to device process.

Does anyone have ideas? I could really use some advise here.

HiassofT
Posts: 105
Joined: Fri Jun 30, 2017 10:07 pm

Re: Possibility for multiple instances of LIRC?

Wed Feb 14, 2018 2:03 pm

I'd recomment switching to kernel 4.14 which includes the upstream gpio-ir-tx and pwm-ir-tx drivers in addition to the gpio-ir-receiver driver.

Then use a DT overlay like this to create multiple receiver and transmitter instances:

Code: Select all

/dts-v1/;
/plugin/;

/ {
        compatible = "brcm,bcm2708";

        [email protected] {
                target = <&gpio>;
                __overlay__ {
                        ir_rx1_pins: ir-rx1-pins {
                                brcm,pins = <23>;
                                brcm,function = <1>;    // out
                        };
                        ir_rx2_pins: ir-rx2-pins {
                                brcm,pins = <24>;
                                brcm,function = <1>;    // out
                        };
                        ir_tx1_pins: ir-tx1-pins {
                                brcm,pins = <25>;
                                brcm,function = <0>;    // in
                        };
                        ir_tx2_pins: ir-tx2-pins {
                                brcm,pins = <26>;
                                brcm,function = <0>;    // in
                        };
                };
        };

        [email protected] {
                target-path = "/";
                __overlay__ {
                        gpio_ir_rx1: gpio-ir-receiver-1 {
                                compatible = "gpio-ir-receiver";
                                pinctrl-names = "default";
                                pinctrl-0 = <&ir_rx1_pins>;

                                gpios = <&gpio 23 1>;   // active-low
                        };
                        gpio_ir_rx2: gpio-ir-receiver-2 {
                                compatible = "gpio-ir-receiver";
                                pinctrl-names = "default";
                                pinctrl-0 = <&ir_rx2_pins>;

                                gpios = <&gpio 24 1>;   // active-low
                        };
                        gpio_ir_tx1: gpio-ir-transmitter-1 {
                                compatible = "gpio-ir-tx";
                                pinctrl-names = "default";
                                pinctrl-0 = <&ir_tx1_pins>;

                                gpios = <&gpio 25 0>;   // active-high
                        };
                        gpio_ir_tx2: gpio-ir-transmitter-2 {
                                compatible = "gpio-ir-tx";
                                pinctrl-names = "default";
                                pinctrl-0 = <&ir_tx2_pins>;

                                gpios = <&gpio 26 0>;   // active-high
                        };

                };
        };
};
That overlay will create 2 receivers and 2 transmitters, each with it's own /dev/lircX device - use udev rules to add symlinks for consistent names.

so long,

Hias

User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Re: Possibility for multiple instances of LIRC?

Thu Feb 15, 2018 8:12 am

Thanks for the quick reply.

I followed your dts and it created 8 devices, AFAIK lirc-rpi was able to handle a pair of TX/RX in one process.

Shall I split up those TX/RX pairs and run lircd 8 times?

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1864
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Possibility for multiple instances of LIRC?

Thu Feb 15, 2018 9:53 am

HiassofT was right to steer you towards gpio-ir and gpio-ir-tx - lirc-rpi isn't built in the 4.15 kernel tree.

To make it easier to use multiple gpio-ir instances the overlays (gpio-ir and gpio-ir-tx) now use the magic "reg" property to prevent name clashes.

User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Re: Possibility for multiple instances of LIRC?

Thu Feb 15, 2018 1:00 pm

I must say that I am quite new to kernel programming, to me everything looks fresh; Apologies for my curiosity.

Do you mean starting from 4.15 lircd is going to handle two /dev/lirc* generated by gpio-ir and gpio-ir-tx; Or is there a way to “merge” them into one single I/O device with some dts syntax that I’m yet to learn?

HiassofT
Posts: 105
Joined: Fri Jun 30, 2017 10:07 pm

Re: Possibility for multiple instances of LIRC?

Thu Feb 15, 2018 1:19 pm

If you want to use lircd (the userspace program) you have to start separate instances for each /dev/lircX device.

lirc_dev was a combined receiver and transmitter, but with gpio-ir-receiver / gpio-ir-tx these are now separate.

Depending on what you exactly want to do you maybe can get away without using userspace lircd:

The IR receiver drivers from the rc-core subsystem support in-kernel decoding of most of the popular protocols (like rc-5, rc-6 and NEC). You can configure the protocol and scancodes-to-key mapping with ir-keytable. The kernel then generates normal input events, just as with a normal keyboard.

To transmit IR signals you can use ir-ctl. You can either transmit arbitrary raw files (pulse/space trains, which you can record with ir-ctl) or, for the most popular protocols, you can pass in a scancode. eg::

Code: Select all

ir-ctl -S rc5:0x1234
If you want't to go the ir-ctl route for transmitting it's best you compile the latest version yourself (ir-ctl and ir-keytable come from the v4l-utils package which you can get from here: https://linuxtv.org/downloads/v4l-utils/ - current version is 1.14.2)

I recently ran into a few bugs in both ir-ctl and lircd/irsend, the lircd/irsend bug isn't fixed yet but the latest ir-ctl version contains the fixes and adds a some other nice features for transmitting IR signals.

so long,

Hias

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1864
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Possibility for multiple instances of LIRC?

Thu Feb 15, 2018 2:09 pm

Thanks for covering the lircd daemon, HiassofT - it's not something I've played with yet other than in the most basic way.

vicary - we like curiosity around these parts, so keep on asking questions. My reply assumed too much knowledge, so I'll try to correct that now.

The change I've made should make it unnecessary to create special n-channel gpio-ir (and -tx) overlays because multiple instances of the same overlay are able to coexist. Applying an overlay is like unpacking a .zip file in that it creates nodes (like directories) and properties (like files) in particular places in the Device Tree (like your SD card). If you extract the contents of a zip file, change some of the file contents (which is what the overlay parameters do), then unpack the same zip file again you are going to overwrite your changes. The new overlays make use of a relatively recent mechanism to rename the nodes so that they don't clash. In this case the gpio_pin value becomes part of the node names, so provided you don't try to create two gpio-ir instances on the same pin (which is clearly an error) then you should theoretically be able to have one per GPIO. In practice, you're likely to run out of some resource before you get that far.

Once you have the new versions of the overlays installed (I can upload them somewhere if you are very keen, otherwise wait for the next rpi-update release), putting this in your config.txt should (I've not tested it) be equivalent to using HiassofT's custom overlay:

Code: Select all

dtoverlay=gpio-ir,gpio_pin=23
dtoverlay=gpio-ir,gpio_pin=24
dtoverlay=gpio-ir-tx,gpio_pin=25
dtoverlay=gpio-ir-tx,gpio_pin=26

HiassofT
Posts: 105
Joined: Fri Jun 30, 2017 10:07 pm

Re: Possibility for multiple instances of LIRC?

Thu Feb 15, 2018 2:55 pm

PhilE wrote:
Thu Feb 15, 2018 9:53 am
To make it easier to use multiple gpio-ir instances the overlays (gpio-ir and gpio-ir-tx) now use the magic "reg" property to prevent name clashes.
Thanks a lot, this is a really nice feature! (although personally I have no use for multiple IR receivers/transmitters it will certainly be helpful for vicary)

One thing I just noticed is that the gpio-ir overlay is missing the (required) pinctrl-0 and (optional) pinctrl-names properties - the -tx overlays have them. Could you add these to gpio-ir-overlay.dts?

so long & thanks a lot,

Hias

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1864
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Possibility for multiple instances of LIRC?

Thu Feb 15, 2018 4:06 pm

One thing I just noticed is that the gpio-ir overlay is missing the (required) pinctrl-0 and (optional) pinctrl-names properties - the -tx overlays have them. Could you add these to gpio-ir-overlay.dts?
You're quite right - that's fixed now.

User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Re: Possibility for multiple instances of LIRC?

Mon Feb 19, 2018 5:35 am

Sorry was off for CNY gatherings, thanks for all the replies.
Depending on what you exactly want to do you maybe can get away without using userspace lircd:

The IR receiver drivers from the rc-core subsystem support in-kernel decoding of most of the popular protocols (like rc-5, rc-6 and NEC). You can configure the protocol and scancodes-to-key mapping with ir-keytable. The kernel then generates normal input events, just as with a normal keyboard.
My main script is written in Node.js, and available wrappers are mostly, if not all, in LIRC.

The script itself serves two main purpose:
  1. Sending the hostname and the TX port direction (UP, DOWN, LEFT, RIGHT), ending with a KEY_0 each time, in terms of remote keystrokes.
  2. Combine incoming keystrokes into KEY_0 separated lines and send them into other Node.js components for further processing.
AFAICT mapping them into uinput events is not necessary in my case.

I was doing irsend SEND_ONCE every few seconds; Still looking for a suitable remote with all the ASCII keys though.
The change I've made should make it unnecessary to create special n-channel gpio-ir (and -tx) overlays because multiple instances of the same overlay are able to coexist. ... In practice, you're likely to run out of some resource before you get that far.
In fact that's exactly how I failed in my previous attempt, I made 4 software UARTS for 8 different pins and the CPU time was quickly saturated. :?
I can upload them somewhere if you are very keen, otherwise wait for the next rpi-update release
That's very kind of you! I really want to try out most of the options during CNY, would you please email it to me at [email protected]?

User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Re: Possibility for multiple instances of LIRC?

Tue Feb 20, 2018 4:04 am

A little more searching I found IrCOMM, and it in fact does most of the things out of the box. *ouch*

Will it work with the new drivers?

HiassofT
Posts: 105
Joined: Fri Jun 30, 2017 10:07 pm

Re: Possibility for multiple instances of LIRC?

Tue Feb 20, 2018 10:03 am

If you mean the ircomm protocol driver in the kernel - this has nothing to do with infrared remotes. The ircomm protocol emulates a serial port on IRDA interfaces.

Code: Select all

$ cat drivers/staging/irda/net/ircomm/Kconfig
config IRCOMM
        tristate "IrCOMM protocol"
        depends on IRDA && TTY
        help
          Say Y here if you want to build support for the IrCOMM protocol.
          To compile it as modules, choose M here: the modules will be
          called ircomm and ircomm_tty.
          IrCOMM implements serial port emulation, and makes it possible to
          use all existing applications that understands TTY's with an
          infrared link.  Thus you should be able to use application like PPP,
          minicom and others.
so long,

Hias

User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Re: Possibility for multiple instances of LIRC?

Wed Feb 21, 2018 4:38 am

I have made both ir-ctl and ir-keytable working, managing key maps require more works but it still works. Thanks for your help!
HiassofT wrote:
Tue Feb 20, 2018 10:03 am
If you mean the ircomm protocol driver in the kernel - this has nothing to do with infrared remotes. The ircomm protocol emulates a serial port on IRDA interfaces.

Yes. IrCOMM is in fact my next step, the drivers are so new I guess I can only ask here.

Please let me tell you more about my project.

I want to build blocks of hot-swappable 4-way IR transceivers in the form of Pi Zero W, they will construct a logical map by
  1. IR for direction, and
  2. Bluetooth signal strength for a rough distance
I can then specify these via HTTP at any one of the nodes,
  1. A type of remote
  2. The hostname of a node
  3. An IR direction
I can then blast an IR key code at any one of the connected nodes, only pre-configured IR ports will blast that IR key code outwards.

My project would require these to work
  1. BLE signal strength for a rough distance (I've done this)
  2. Understands all the remotes (I've done this too thanks for your help)
  3. Sends the hostname and direction via IR
I looked up the whole remote database there is all but devinput which has all the ASCII keys and it does not support sending at all.

I guess I have to either mock up a remote.conf of a whole keyboard with the default driver, or use something like IrCOMM to send the hostnames.

Will it, the IrCOMM, by any chance also work with the gpio-ir drivers?

HiassofT
Posts: 105
Joined: Fri Jun 30, 2017 10:07 pm

Re: Possibility for multiple instances of LIRC?

Fri Feb 23, 2018 12:56 pm

Ah, no. As I wrote before IrCOMM has nothing to do - and can't work with - infrared remote drivers.

IrCOMM is designed to be used with IRDA ports, which the RPi doesn't have. Also IRDA uses a completely different way to transmit data than infrared remotes.

Infrared remotes typically send bursts of IR pulses, modulated at 36-40kHz. See for example these descriptions of the NEC and RC-5 protocols: https://www.sbprojects.net/knowledge/ir/nec.php https://www.sbprojects.net/knowledge/ir/rc5.php

When using the gpio-ir-tx overlay the driver has to quickly turn on and off the GPIO (at the configured 36-40kHz modulation) to generate the proper signal on the GPIO. If possible it's better to use the pwm-ir-tx driver, it uses the RPi's PWM to generate the 36-40kHz signal and the driver only has to enable/disable the PWM on the start and end of each burst.

Transmitting the same signal on multiple gpio-ir-tx instances at the same time is probably not going to work. You'll have interference between your various IR LEDs and I suspect the timing will be rather off as well.

If you want to do such a thing (eg transmit the same signal via 2-4 LEDs at the same time) it's better to use a different approach and solve this at the electrical level: configure a single gpio-ir-tx or pwm-ir-tx device and use 4 GPIOs to enable/disable transmission of each IR LED. Then just combine the ir driver output GPIO and enable GPIOs using standard AND/OR/... gates and hook up your IR LEDs to that.

If I understand you correctly your goal is not to control household equipment via IR but to transmit some data. In this case you probably don't need the IR scancode to linux input code mapping but can just deal with scancodes. i.e. use ir-ctl to transmit scancodes using some protocol (eg "ir-ctl -S rc5:0x42") and configure the receiver for the same protocol (eg "ir-keytable -p rc5") and check for EV_MSC scancode events on the linux input event device.

so long,

Hias

User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Re: Possibility for multiple instances of LIRC?

Tue Feb 27, 2018 7:23 pm

HiassofT wrote:
Fri Feb 23, 2018 12:56 pm
...

If I understand you correctly your goal is not to control household equipment via IR but to transmit some data. In this case you probably don't need the IR scancode to linux input code mapping but can just deal with scancodes. i.e. use ir-ctl to transmit scancodes using some protocol (eg "ir-ctl -S rc5:0x42") and configure the receiver for the same protocol (eg "ir-keytable -p rc5") and check for EV_MSC scancode events on the linux input event device.

so long,

Hias

I was in fact sending both, with the ending node blasting real IR signals. I guess using scancodes as a protocol to send the hostnames would also work.

I have been learning udev rules, TBH the result is kind of confusing.

In short, I eventually made meaningful symlinks for each device; But ir-keytable needs /dev/input/event* where gpio-ir drivers only make /dev/lirc*.

In the middle of my fiddling with udev rules, for once I am pretty sure I've seen all gpio-ir-receivers as symlinks to /dev/input/event*, then I can never make it happen again. Is there a correct way to do that?

EDIT: I read this thread, will try it and gives more updates.

User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Re: Possibility for multiple instances of LIRC?

Wed Feb 28, 2018 7:40 am

Following up my tests regarding this thread, not sure if I should post there instead, please let me know.

My initial test is to have one of the gpio-ir device receiving KEY_* events from the same transceiver under a gpio-ir-tx driver instance, I am simplifying the case down to one transceiver at the moment.

Code: Select all

$ ls -l /sys/class/rc/rc*
lrwcrwcrwc 1 root root 0 Feb 28 14:46 /sys/class/rc/rc0 -> ../../devices/platform/1a.gpio-ir-transmitter/rc/rc0
lrwcrwcrwc 1 root root 0 Feb 28 14:46 /sys/class/rc/rc1 -> ../../devices/platform/6.ir-receiver/rc/rc1
I have the above devices right now

Code: Select all

$ ls -l /sys/class/rc/rc*/
/sys/class/rc/rc0/:
total 0
lrwcrwcrwc 1 root root 0 Feb 28 15:01 device -> ../../../1a.gpio-ir-transmitter
lrwcrwcrwc 1 root root 0 Feb 28 15:01 lirc0
lrwcrwcrwc 1 root root 0 Feb 28 15:01 power
lrwcrwcrwc 1 root root 0 Feb 28 15:01 subsystm -> ../../../../../class/rc
lrwcrwcrwc 1 root root 0 Feb 28 15:01 uevent

/sys/class/rc/rc1/:
total 0
lrwcrwcrwc 1 root root 0 Feb 28 15:01 device -> ../../../6.ir-receiver
lrwcrwcrwc 1 root root 0 Feb 28 15:01 input2
lrwcrwcrwc 1 root root 0 Feb 28 15:01 lirc1
lrwcrwcrwc 1 root root 0 Feb 28 15:01 power
lrwcrwcrwc 1 root root 0 Feb 28 15:01 protocols
lrwcrwcrwc 1 root root 0 Feb 28 15:01 subsystm -> ../../../../../class/rc
lrwcrwcrwc 1 root root 0 Feb 28 15:01 uevent
I've learn that rc* is just symlinks to lirc*, or vise versa.

Code: Select all

$ ir-ctl -d /dev/lirc0 -S rc5:0x1f00 # 1st boot: hauppauge KEY_1
$ ir-ctl -d /dev/lirc0 -S nec:0x0801 # 2nd boot: Picked a random remote (alink_dtu_m) KEY_1
Scancodes are sending without errors, I can see the IR LED flashing with a camera.

Code: Select all

dtoverlay=gpio-ir,gpio_pin=6,rc-map-name=rc-hauppauge # 1st boot
dtoverlay=gpio-ir,gpio_pin=6,rc-map-name=rc-alink-dtu-m # 2nd boot
I am editing /boot/config.txt to force a single rc_keymap before each test.

Code: Select all

$ sudo ir-keytable -s rc1 -t # 1st boot
$ evtest /dev/input/event2 # 2nd boot
But ir-keytable and evtest shows nothing when I blast scancodes from the LED right next to the receiver.

With mode2 I can confirm it is receiving something, but it somehow didn't translate into input events.

Is it the bug you mentioned before? I am giving my last shot at building [email protected] from source in my Pi Zero, it might take eons but I can only hope...

HiassofT
Posts: 105
Joined: Fri Jun 30, 2017 10:07 pm

Re: Possibility for multiple instances of LIRC?

Wed Feb 28, 2018 10:23 am

When you run ir-keytable -t you may have to specify the protocol, eg use "ir-keytable -p rc5 -t". When you run mode2 it'll disable all in-kernel decoders.

If you run "ir-keytable" it'll show which decoders are available and which ones are enabled. eg:

Code: Select all

# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event1) with:
        Driver: gpio-rc-recv, table: rc-rc6-mce
        lirc device: /dev/lirc0
        Supported protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
        Enabled protocols: lirc rc-5
        Name: gpio_ir_recv
        bus: 25, vendor/product: 0001:0001, version: 0x0100
        Repeat delay = 750 ms, repeat period = 125 ms
The "lirc protocol" will always be enabled, actually that's not a real protocol, it means you can get the raw signals via /dev/lircX (what mode2 or ir-ctl -r use).

Once you have configured the protocol you should also get the raw scancodes as EV_MSC events in evtest.

Another hint for compiling v4l-utils: you don't have to build the full v4l-utils package, after running ./configure you can just build ir-ctl and ir-keytable with "make -C utils/ir-ctl" and "make -C utils/keytable" - this saves quite some time. Then just use the ir-ctl/ir-keytable executables from these directories.

so long,

Hias

User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Re: Possibility for multiple instances of LIRC?

Wed Feb 28, 2018 11:02 am

Just done compiling, using the new ir-keytable still yields nothing.

Code: Select all

$ v4l-utils-1.14.2/utils/keytable/ir-keytable          
Found /sys/class/rc/rc0/ (/dev/input/event0) with:
	Driver: gpio-rc-recv, table: rc-alink-dtu-m
	lirc device: /dev/lirc0
	Supported protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp 
	Enabled protocols: lirc nec 
	Name: gpio_ir_recv
	bus: 25, vendor/product: 0001:0001, version: 0x0100
	Repeat delay = 500 ms, repeat period = 125 ms
Since it is gpio-ir it supports both of rc5 (hauppauge) and nec (alink_dtu_m), now off for tests.

Code: Select all

dtoverlay=gpio-ir,gpio_pin=6,rc-map-name=rc-hauppauge

Code: Select all

$ sudo v4l-utils-1.14.2/utils/keytable/ir-keytable -p rc5 -t &
[1] 604
Protocols changed to rc-5 
Testing events. Please, press CTRL-C to abort.
$ sudo v4l-utils-1.14.2/utils/ir-ctl/ir-ctl -d /dev/lirc1 -S rc5:0x1f00
$ sudo v4l-utils-1.14.2/utils/ir-ctl/ir-ctl -d /dev/lirc1 -S rc5:0x1e01
hauppauge doesn't work.

Code: Select all

dtoverlay=gpio-ir,gpio_pin=6,rc-map-name=rc-alink-dtu-m

Code: Select all

# devices swapped place after reboot, not bothering with udev right now.
$ sudo v4l-utils-1.14.2/utils/keytable/ir-keytable -s rc1 -p nec -t &
[1] 635
Protocols changed to nec
Testing events. Please, press CTRL-C to abort.
$ sudo v4l-utils-1.14.2/utils/ir-ctl/ir-ctl -d /dev/lirc0 -S nec:0x0801
Random remote is also silent.

User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Re: Possibility for multiple instances of LIRC?

Wed Feb 28, 2018 1:53 pm

I just did a fresh install of Raspbian Lite, upgraded kernel and built v4l-utils gain; No luck. :|

HiassofT
Posts: 105
Joined: Fri Jun 30, 2017 10:07 pm

Re: Possibility for multiple instances of LIRC?

Wed Feb 28, 2018 2:41 pm

Hmmm this seems to work fine here on RPi2.

config.txt:

Code: Select all

dtoverlay=gpio-ir,gpio_pin=17
dtoverlay=gpio-ir-tx,gpio_pin=18
Terminal 1:

Code: Select all

[email protected]:~# ir-keytable -s rc1 -p rc5 -t
Protocols changed to rc-5
Testing events. Please, press CTRL-C to abort.
1519828026.219516: event type EV_MSC(0x04): scancode = 0x1234
1519828026.219516: event type EV_SYN(0x00).
Terminal 2:

Code: Select all

[email protected]:~# ir-ctl -d /dev/lirc0 -S rc5:0x1234
Receiving the signal the RPi is sending out could be too much / timing critical though, especially on RPi0.

The gpio-ir-recv driver, and also the lirc_rpi driver, are very sensitive to interrupt latency, so if the kernel is blocking the timing will be messed up and decoding fails. The same is true for the gpio-ir-tx driver - it needs to bitbang the GPIO in rather precise intervals to create the 36-40kHz modulated signal.

Try running this on 2 separate RPis and/or use the pwm-ir-tx overlay - this is nicer on CPU utilization.

so long,

Hias

User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Re: Possibility for multiple instances of LIRC?

Wed Feb 28, 2018 4:06 pm

OH MY GAWD you nailed it, input events are popping up when I use a second Pi0 for blasting!

That means I'll have do create some switching protocol to work with 8 channels, and even if it works a single round of effective 4-way communication could easily cost minutes... :roll:

Nedryland
Posts: 1
Joined: Mon Mar 05, 2018 8:06 am

Re: Possibility for multiple instances of LIRC?

Mon Mar 05, 2018 8:08 am

Instead of running two instances on my pi I opted to make what is essentially a transistor switchboard (on a breadboard). I call each send command from a script which first runs another script that that turns on one of three GPIOs, activating one of three transistors, and thus exposing one of three IR transmitters to receive signal from the single LIRC gpio.

This actually works very well, and I was able to put this together in less time than it takes to read the tutorials on multiple instances and drivers. I needed this ability because I have multiple components which are of the same make and therefore receive some of the same codes such as power. If each device didn't have it's own transmitter I wouldn't be able to control one device without the other non intended device also responding to the command.

Davros-
Posts: 48
Joined: Sun Aug 30, 2015 6:33 pm

Re: Possibility for multiple instances of LIRC?

Tue Mar 27, 2018 6:51 pm

Hello guys. I too would like to run multiple (4) infrared transmitters from one Raspberry Pi and general research took me here. However vicary knows more about the overall sitatuition than I do so I still have some questions about what to do next after loading the pwm-ir-tx kernel module. Would very much aprpeciate being educated on the matter. Apologies if this feels like I am taking over the thread or I should have posted follow up and detail question in another, non device tree realted, section.

In my case I only need transmission and the the four transmitters can send their signal one after another. (IR transmitter one can fire, then one second later transmitter two can fire, one second after that transmitter three can fire, etc.) Having one Pi unit control four transmitters instead having four Pi devices would be so very good for us. The lights I want to control came with an IR remote and I already decoded its signals using a utility that is part of LIRC.


So I get the suggestion to load the pwm-ir-tx kernel module using the device tree overlay. However, I do not know how to control things from there though and am seeking to be educated on the matter. Do I have to be proactive with my software to utilize the speedy powers of pwm-ir-tx? That is to say is just the act of loading it using the device tree overaly enough to make sure it gets used for commands directed at the specified GPIO pins or do I need to do something more proactive with my application?

How do I in general transmit codes with it loaded? Do I have to look at the decoded file I made and try to figure out the pulses and then write commands to immitate the pulses, creating them myself individually? Such as typing the code equivalent of "on for Xmilliseconds, off for Ymillisecpmds, on for Xmillimisecondss, off"? Any easier way to do that since I have all the signals decoded and in a file? Just asking that as an example, regardless of how it is done I would like to know software wise what do I do to transmit an IR code if I go the pwm-ir-tx route.

It would be great if whatever I need to do I could pull it off with a Python script, but if I have to learn more about a lower level language I will.

(I am asking about this because I just read about it as an option in this thread, however, I am open to any suggestions for other approaches to get four IR transmitters working as well.)

Please know I appreicate help with this.


BTW, while we are stuck with the flood lights we have no other hardware has been purchased so I can go with what is needed.


Thanks.

User avatar
vicary
Posts: 27
Joined: Tue Jul 17, 2012 4:37 am
Location: Hong Kong

Re: Possibility for multiple instances of LIRC?

Tue Mar 27, 2018 8:57 pm

Not sure if pwm-ir-tx works the same way as gpio-ir-tx do.

AFAIK when LIRC records in raw mode it spits out a format that looks very much like the examples in ir-ctl.

See the file sending option here
https://www.mankier.com/1/ir-ctl

HiassofT
Posts: 105
Joined: Fri Jun 30, 2017 10:07 pm

Re: Possibility for multiple instances of LIRC?

Wed Mar 28, 2018 10:46 am

From a userspace perspective pwm-ir-tx works identical to gpio-ir-tx - both have the same capabilities (transmit IR, set carrier frequency and duty cycle).

One difference is that you can't easily instantiate more than 1 pwm-ir-tx driver. The current overlay has the first pwm (pwm-0) hardcoded, with a modified overlay you could instantiate 2 drivers - bcm2835 has 2 separate pwm channels that can be used.

Also keep in mind that with the pwm-ir-tx driver you are limited to which GPIO pins you can use - best stick to the default (GPIO 18 / pin 12).

As I wrote before it's probably best to stick to a single IR transmitter device on the RPi and use some additional hardware to control which of the multiple IR leds should be used (eg none, just a single on, or all at the same time).

If possible use the send scancode feature of ir-ctl, as this automatically selects the correct carrier frequency (36kHz for rc-5, 38kHz for NEC, 40kHz for Sony etc).

Most IR receivers (like eg TSOP34438) demodulate at a fixed frequency (the "38" at the end of the part number stands for 38kHz) and while you'll still get some useable signals with eg 36 or 40kHz modulated signals from the receiver you won't know the exact frequency.

So when you recorded the raw signals, eg with ir-ctl -r, you have to specify the carrier frequency manually when transmitting, eg with ir-ctl -s.-The device you're going to control with it could be picky about that.

so long,

Hias

Return to “Device Tree”

Who is online

Users browsing this forum: No registered users and 2 guests