Possibility for multiple instances of LIRC?

[Davros-]

Thanks for the responses.

Reading everything above my post gave me hope that I could run the four IR emitters from one Pi by utilizing either of the drivers discussed so I am little dissappointed to find out otherwise.

However, I only need to send the same command on each IR transmitter and if you folks suggest trying a hardware system I would be inclined to think that is best. Hiass for example clearly knows allot about the subject and suggested it.


Could use some guidance on that helpful. Pointing out examples, guides, etc would be helpful to me. Or even just educating me on the basic concept. Realize we are talking about making a circuit that cuts off all but one transmitter and takes a signal to change which transmitter is active at any one time but I do not know even the first step in achieving that. If I was given the general idea I would be fine doing research and learning more to build it on my own.

Nedryland, as you said you built a type of switchboard for your project I am now asking you if you documented it anywhere or have anything you would point me to in order to get started.

I should probably also ask the 4th year electronic engineering student at work when I go in for my shift tonight.

Thanks to all of you for your help, BTW. And thanks to people like PhilE and others who actually develop the software tools we need to make these things.

[HiassofT]

You could, for example, use the good old 74HC08 quad 2-input AND gate for this purpose.

Connect pin 14 of the '08 (VCC) to 3.3V and pin 7 (GND) to GND.

Then connect the IR output GPIO (18) to one input of each AND gate (pins 1, 4, 10, 13).

Connect 4 GPIOs of the RPi to the other inputs (pins 2, 5, 9, 12).

Then use the 4 AND gate outputs (pins 3, 6, 8, 11) to drive the IR transmitters - just like you'd hook them up to the RPi's GPIOs.

With the 4 GPIOs you can control which of the 4 IR transmitters will be active. If the corresponding GPIO is high, the AND beween IR_TX_OUT and "high" is IR_TX_OUT - so you get the IR signal. If the corresponding GPIO is low AND between IR_TX_OUT and "low" is "low" - i.e. no signal on the output of the AND gate.

so long,

Hias

[Davros-]

Hias, thank you very much for posting that.

I have to go to work soon so I will wait until later for all my detail questions, but I will fire a basic one out now.

To use this, software wise, should I be using the gpio-ir-tx overlay or the pwm-ir-tx overlay? Based on the example pin you used in your post I am guessing the answer is gpio-ir-tx.

Thanks. Will post more later.

[HiassofT]

I'd recommend pwm-ir-tx which by default uses GPIO 18 (pin 12 of the header).

You'll have to remove / comment out "dtparam=audio=on" for that to work

so long,

Hias

[Davros-]

I appreciate everyone helping me, and I hope all this extra stuff does not bother the original poster, Vicary. Hias, very much appreciate your continuing help and describing wiring up a hardware solution.

Did more research using your info and I learned about this and that. Would it be just as good to buy a demultiplexer and wire my 4 infrared LEDs into it? Seems to be the same overall concept your described. Perhaps the difference between an AND gate and a demultiplexer is so small as to not matter in this case and I am asking a pointless question. Maybe it is my lack of small electronics knowledge but the demultiplexer chips seem to be more straight forward and work generally the same. And I can get one locally.

Thanks.

[HiassofT]

A demultiplexer will work fine, too. You only have to make sure you get the polarity right, eg the popular 74xx138 3-to-8 demultiplexers have inverting outputs.

The 74HC238 has non-inverting outputs, so that one should work:

Wire /E1 and /E2 to GND and E3 to the RPi IR out GPIO, A0 and A1 to 2 GPIOs to select the LED number and A3 to GND - then you'll have active-high output on Y0-Y3, depending on the state of A0/A1.

Keep in mind that the 74xx series chips don't have a high current drive/sink capabilities , so you'll also need transistors to drive the LEDs - like in most circuits you'll find on the 'net that hook up directly to the RPi's GPIO pins.

The main difference between the AND gate solution and a demux is that the AND gate allows you to drive all LEDs at the same time (or even none, or 1-3 of them), but you need 2 more GPIOs. With a demux you can only drive a single LED, but need less GPIOs.

BTW: you can also use 74LS or 74HCT series chips for the purpose, you need to connect VCC to 5V in that case (these are 5V chips), but their inputs are compatible to the RPi's 3.3V outputs.

so long,

Hias

[Davros-]

Hiass, thank you so very much for your continuing help.

The appeal of using less GPIO pins is powerful. Especially as I may want to attach buttons, swtiches, etc to the same Pi unit later. I did not realize that I could use all the IR emmitters at once with the AND gate chip though. That is not that important, but it has appeal for sure. Additionally, I did not realize the need for transisters on the demultiplexer chip and it would be nice to avoid soldering those on a bunch of wires.


Reared your original post and it was very good, giving specific instructions, but I want to make sure I interpretted it correctly due to my lack of knowledge on the subject. If I were to use the 74HC08 chip I would use in total Power (3.3v), Ground, plus 5 other GPIO pins. Is that correct?

When you say "output GPIO (18) to one input of each AND gate" I believe you mean solder 4 small wires to the wire going into GPIO pin 18, thus only using one GPIO pin to control the four AND gates. Is this correct?

With the 74HC08 I can both control the IR LEDs individually and all at the same time? I realize you described the abilities of this approach but this aspect is important enough that I wanted to read it again to be sure before I commit.


If the above is correct, then I would still have a bunch of GPIO pins left to use. Super duper embarassed to ask this, but I am not sure if I can use the specific function GPIO pins as general purpose pins. Pins like Physical pin 8 (BCM 14) is a UART pin and Physical pin 19 (BCM pin 10) is a MOSI pin. Can they can be used for general purposes as well? I realize that if the answer is yes some configuration changes to the Pi may be needed in a few cases such as disabling the serial console to use an UART pin.

I will have to think about it, but now that you spoke of the differences I am kind of leaning towards your first suggestion, the 74HC08.

Less GPIO pin usage is nice, but so is doing less soldering (adding the transisters) and flexibility is always a great thing (controlling all LEDs at once in addiation to controlling them individually). Will think about it, but the 74HC08 chip is sounding good.

Thank you again so much for your continuing help.

[HiassofT]

The appeal of using less GPIO pins is powerful. Especially as I may want to attach buttons, swtiches, etc to the same Pi unit later. I did not realize that I could use all the IR emmitters at once with the AND gate chip though. That is not that important, but it has appeal for sure. Additionally, I did not realize the need for transisters on the demultiplexer chip and it would be nice to avoid soldering those on a bunch of wires.

Actually you should use the transistor with the AND gate as well.

To properly drive the IR LED you'll need typically around 20mA (it depends on the LED, you'll have to check the datasheet).

74HCxx and 74HCTxx chips are designed to source/sink typically around 4-5mA and although the absolute maximum spec is around 20-25mA I'd not recommend to go that far - if you exceed the limits you could damage the chips.

74LSxx can source even less current, typically less than 0.5-1mA (this is when you connect the LED + current limiting resistor between 74LSxx output and GND). But it can sink quite a bit more, typically around 15mA (when you connect the LED between VCC and 74LSxx output - eg in if you use inverting outputs).

There are 74xx chips that are designed as buffers/drivers can source/sink higher currents but they might be harder to get and/or you need separate driver chips, in addition to the AND/demuxer.

Using a transistor is probably easier and work with all setups, without you having to do a lot of research.

Reared your original post and it was very good, giving specific instructions, but I want to make sure I interpretted it correctly due to my lack of knowledge on the subject. If I were to use the 74HC08 chip I would use in total Power (3.3v), Ground, plus 5 other GPIO pins. Is that correct?

Yes.

When you say "output GPIO (18) to one input of each AND gate" I believe you mean solder 4 small wires to the wire going into GPIO pin 18, thus only using one GPIO pin to control the four AND gates. Is this correct?

Yes. This GPIO will be used in all 4 AND gates.

With the 74HC08 I can both control the IR LEDs individually and all at the same time? I realize you described the abilities of this approach but this aspect is important enough that I wanted to read it again to be sure before I commit.

Yes. Think of this chips as electrical versions of boolean logic - just like you have in programming languages. Each 74xx08 chip contains 4 AND gates, so you'll have

IROUT AND GPIO1
IROUT AND GPIO2
IROUT AND GPIO3
IROUT AND GPIO4

(GPIO1-4 just being arbitrary numbers, to illustrate what it'd look like)

By setting GPIO1-4 you can choose any combination of active inactive LEDs 0, 1, 2, 3, 4 - whatever you like/want.

If the above is correct, then I would still have a bunch of GPIO pins left to use. Super duper embarassed to ask this, but I am not sure if I can use the specific function GPIO pins as general purpose pins. Pins like Physical pin 8 (BCM 14) is a UART pin and Physical pin 19 (BCM pin 10) is a MOSI pin. Can they can be used for general purposes as well? I realize that if the answer is yes some configuration changes to the Pi may be needed in a few cases such as disabling the serial console to use an UART pin.

Yes, you can repurpose these as well. In addition to ALTx all the GPIOs (if I'm not mistaken) can be configured as normal GPIOs as well.

so long,

Hias

[Davros-]

Hias, thanks again for your continuing help. Sorry for the delayed post, work is super busy and after my transplant surgery a little over 6 months ago I still have many medical appointments.

If you or anyone has a suggestion for an IR LED I would like to know what it is, otherwise I guess I will buy whatever is available or one I see being used in some Raspberry Pi remote control tutorial.

The electronics engineering student at work advised me I would need transistors regardless. Thank you for warning me though, definitely thoughtful. Kind of thinking that more GPIOs is better as other things may be added in the future. Also the people who can give me local help seem to just generally like a demultiplexer better although they all verbally said it does not matter. The 74139 was talked about it and a local place can get it for me. Thinking of using it.

BTW, "electrical versions of boolean logic" made it more clear to me. Great analogy.

Any thoughts about the above are appreciated but I would like to discuss the software part, unintentionally getting to the real original topic on this post.

I need to use RC-5 as my transmission protocol which I believe runs at 36khz.

So to control all this I would start with the device tree overlay.

Would the following be correct assuming I am using GPIO pin 26 to send the signal out?
Edit /boot/config.txt to have the line dtoverlay=pwm-ir-tx,gpio_pin=25


How would I then send a signal out through say a Python script? Or any kind of script/application? Perhaps I need to send terminal commands from the script to use ir-ctl? Assume I would need to configure it to work with the right output pin and the pwm-ir-tx driver?

Definitely need guidance on how to send a signal of my choice once the hardware is put together.

Thanks.

[HiassofT]

Basically any IR LED should work, they typically transmit at about 940-950nm wavelength so should work fine with IR receivers.

The most important differences between the different IR LEDs are power and opening (vieweing) angle / directivity. So you'll probably have to test which one works best for your application.

Depending on the forward voltage of the LED and the power you'll also have to adjust the current limiting resistor and if you use a high power LED you'll need a more powerful transistor as well. IR LED nominal current ranges from 20-150mA (often with peak currents allowed well above that), but your typical BC548 transistor can't handle more than 100mA - you'll need to use something else, like a 2N2222 if you need more power.

It's no problem to use a high-power LED at lower currents, just use a higher value current limiting resistor - then the LED will draw less power and be less bright.

Vishay (the manufacturer of the well known TSOP34438 IR receiver) mentions their TSAL6200 IR LED in the TSOP datasheet - haven't used that one myself yet, but if you can get it it shouldn't be the wrong type

If in doubt have a look at the datasheets of the LEDs, they should contain the info you might be looking for.

BTW: It'd probably be best if you start with a single LED (plus transistor etc) on a breadboard, then you can test if the viewing angle and brightness of the LED are fine for your application - and easily swap in another LED or a different current limiting resistor or transistor.

As for the software: pwm-ir-tx on GPIO 25 doesn't work. Only GPIO 18 (pin 12) and GPIO 12 (pin 32) can be configured as PWM0 outputs. The former is the default, for the latter you have to use "dtoverlay=pwm-ir-tx,gpio_pin=12,func=4"

Not sure if there's any python library for transmitting IR signals, I'd just use "ir-ctl -S rc5:..." to do that - I've been using that quite often myself and it worked just fine.

so long,

Hias

[DropbearNinja]

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

Hi, I'm also trying to set up lirc to run with multiple transmitters. I got multiple devices setup and working thanks to PhilE's code above, but what I'd like to be able to do is assign a a device to individual lircd.conf files - i.e. individual remotes. (e.g. remote1.conf uses lirc0, remote2.conf uses lirc1 etc)

At present, according to http://www.lirc.org/html/lircd.conf.html, you can assign a driver to a conf, but not a device? Is there some way I could set specific remotes to work with a specific device without using a script/hardware?

Many many thanks!

[HiassofT]

To use multiple devices with independent configs you'll have to run multiple lirc instances (each with it's own lirc-options.conf and lircd.conf file).

Unless you have a very specific need to use lirc I'd suggest to use ir-ctl. You don't need to run a bunch of background processses but can just specify which /dev/lircX device to use (eg ir-ctl -d /dev/lirc2 -S ...)

so long,

Hias

[DropbearNinja]

Thanks Hias. ir-ctl works well.

I can record raw IR with "ir-ctl -d /dev/lirc1 -r/home/pi/remote" and send it back with" ir-ctl -d /dev/lirc0 -s /home/pi/remote"

But i cannot figure out scancodes. With LIRC I recorded raw IR and manually converted to hex values, e.g. 0x88C0051 is key_power, and that code works in LIRC. However LIRC doesn't report a protocol, and trying every protocol in ir-ctl none work (most say invalid scancode, some do actually run, and an IR signal is sent, but the device doesn't respond).

I tried to use ir-keytable -t to get protocol information, but it doesn't give me any output. I believe I just need to enable more protocols, but i can't seem to do that: Perhaps you can make sense of this please?

Code: Select all

[email protected]:/home/pi# ir-keytable
Found /sys/class/rc/rc1/ (/dev/input/event0) with:
        Driver gpio-rc-recv, table rc-rc6-mce
        Supported protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
        Enabled protocols: lirc
        Name: gpio_ir_recv
        bus: 25, vendor/product: 0001:0001, version: 0x0100
        Repeat delay = 500 ms, repeat period = 125 ms
Couldn't find any node at /sys/class/rc/rc0/input*.

[email protected]:/home/pi# ir-keytable -d /sys/class/rc/rc1/
EVIOCGNAME: Inappropriate ioctl for device
EVIOCGID: Inappropriate ioctl for device

[email protected]:/home/pi# ir-keytable -d /sys/class/rc/rc1/ --protocol=all
Unable to query evdev protocol version: Inappropriate ioctl for device
[email protected]:/home/pi#

my config.txt

Code: Select all

dtoverlay=gpio-ir-tx,gpio_pin=22
#dtoverlay=gpio-ir-tx,gpio_pin=24
dtoverlay=gpio-ir,gpio_pin=23

[HiassofT]

ir-keytable in Debian/Raspbian trips on transmit-only IR devices. This is fixed in newer versions, you could compile v4l-utils 1.14.2 (or master) and use ir-keytable from there.

This also includes the "all" protocol option but it won't help you much as IIRC ir-keytable -t only outputs the scancode but not the protocol (not 100% sure, I'd need to check). So better enable protocols one by one and check for scancodes (eg ir-keytable -p rc5 -t).

With multiple devices it's best to use the "-s rc0" ir-keytable option to choose the device (with -d you specify the event device).

If ir-keytable in Debian still trips, just disable the transmit-only devices temporarily so you only have one (receiver) IR device to get the scancodes.

The scancodes in lirc are rather different to the ones from ir-keytable so better use only the latter.

so long,

Hias

[DropbearNinja]

Thanks again Hias, your help is spot on and really appreciated.

Code: Select all

 ir-keytable -t -s rc0 -p nec

works as intended for all my remotes except one. None of the protocols work for this remote. Though ir-ctl does correctly record raw data and sending that raw data works on the device. Can I assume at this point that either the remote uses a protocol that isn't supported by ir-keytable, or perhaps it doesn't conform to a supported protocol?

Either way, I'm happy enough to use raw data. In this regard, it seems as if I'll need a separate file for each button. Is there a neater way to combine the raw data into a single file and reference key codes?

Thanks.

[HiassofT]

Glad you got it working!

It could well be that the remote uses a non standard protocol - there's a lot of really odd remotes and proprietary protocols out there.

In this case raw data recording/transmission is needed, and with ir-ctl you'll need to use separate files per button for that.

so long,

Hias