lirc-list Mailing List for LIRC

i have been using the USB IR Toy from Dangerous Prototypes for years 
with my Raspberry Pi systems to control all of my entertainment devices 
(TV, Sound Bar, DVR, Apple TV, etc).
back when i was experimenting a lot, i used to have to re-update the 
firmware more frequently than i expected, but the most recent load had 
lasted me over 2 years; until this week.
i always used the fw_update(.exe) command under Windows because that was 
the only examples i could find online. works fine. i even customised 
my firmware binary files to include custom a "Serial Number" for each of 
my devices, so i could differentiate them in udev rules on the Pi.
now, this week, i was experimenting again and messed up the Toy and must 
now re-update the firmware again to get it to function. i wonder about 
the possibility of doing so from the Pi to avoid dragging the old 
Windows laptop out again, and dragging the Toy out from the 
entertainment center to work on the Toy (jumping PGC/PGD). the Toy 
"firmware update" page mentions being able to use a serial connection to 
activate the bootloader. Linux has the "setserial" command that ought 
to function like the "terminal" command on Windows.
has anyone successfully done a firmware update using UNIX/Linux alone?
even assuming i can put the Toy in bootloader mode, does anyone know 
what to use under Linux to replace the Windows fw_update 
command/executable functionality? just use "cat" to dump the contents 
of the binary file into the serial stream after sending "$" to enter 
bootloader mode?
Pi: Raspberry Pi 4 Model B Rev 1.1 with 2 gig of memory
OS: Debian GNU/Linux 12 (bookworm)
Toy: http://dangerousprototypes.com/docs/USB_IR_Toy_firmware_update 

On Mon, Sep 15, 2025 at 09:29:35AM +0200, Mariusz Ferdyn wrote:
> So ir-ctl is shipped out of the box? I thought it is LIRC, so in that case
> what section is needed only https://github.com/MariuszFerdyn/AirConditionIoTCentral/blob/main/02-InfraRedReceiver/01-InstallLIRC.sh
> (You can always contribute).
ir-ctl is part of v4l-utils, not lirc. I think Raspberry Pi OS installs that
by default. Installing lirc isn't going to help.
Looks like we have a bug for gpio-ir-tx on RPi 1. I think the problem is that
the current loop for generating the signal is too slow, so that the result
is just garbage. 
Sean

On 9/14/2025 11:16 PM, Sean Young wrote:
> On Sun, Sep 14, 2025 at 05:38:22PM +0200, Mariusz Ferdyn wrote:
>> @Sean Thank you fro your help - moving to pwm-ir-tx for sending (receive was
>> OK) - /boot/firmware/config.txt:
>> dtoverlay=pwm-ir-tx,gpio_pin=18
>> dtoverlay=gpio-ir,gpio_pin=22
> That's great! The pwm-ir-tx driver really only becomes reliable in kernel
> v6.8, with commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363d0e56285e80cda997d41d94c22313b673557d
>
> In earlier kernels, under load the generated IR might be garbage. YMMV
>
> Best to update to the latest bookworm version with kernel 6.12.
>
>> It is working for Raspbery Pi 1 - for TV Samsung, Sound Bar Creative and Air
>> Condition!
>>
>>
>> Thanks for help.
> Glad to be of help.
>
>> It is part of bigger project:
>> https://github.com/MariuszFerdyn/AirConditionIoTCentral - anyway you can
>> link it to LIRC links.
> Very nice. I am not really understanding the setup though. You're using
> ir-ctl, yet there are various references to lircd. Is lircd used at all,
> if so what for what?
>
> Note that ir-ctl doesn't require or use lircd.
>
>
> Sean
>
So ir-ctl is shipped out of the box? I thought it is LIRC, so in that 
case what section is needed only 
https://github.com/MariuszFerdyn/AirConditionIoTCentral/blob/main/02-InfraRedReceiver/01-InstallLIRC.sh 
(You can always contribute).
Mariusz

On Sun, Sep 14, 2025 at 05:38:22PM +0200, Mariusz Ferdyn wrote:
> @Sean Thank you fro your help - moving to pwm-ir-tx for sending (receive was
> OK) - /boot/firmware/config.txt:
> dtoverlay=pwm-ir-tx,gpio_pin=18
> dtoverlay=gpio-ir,gpio_pin=22
That's great! The pwm-ir-tx driver really only becomes reliable in kernel
v6.8, with commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363d0e56285e80cda997d41d94c22313b673557d
In earlier kernels, under load the generated IR might be garbage. YMMV
Best to update to the latest bookworm version with kernel 6.12.
> It is working for Raspbery Pi 1 - for TV Samsung, Sound Bar Creative and Air
> Condition!
> 
> 
> Thanks for help.
Glad to be of help.
> It is part of bigger project:
> https://github.com/MariuszFerdyn/AirConditionIoTCentral - anyway you can
> link it to LIRC links.
Very nice. I am not really understanding the setup though. You're using
ir-ctl, yet there are various references to lircd. Is lircd used at all,
if so what for what?
Note that ir-ctl doesn't require or use lircd.
Sean

@Sean Thank you fro your help - moving to pwm-ir-tx for sending (receive 
was OK) - /boot/firmware/config.txt:
dtoverlay=pwm-ir-tx,gpio_pin=18
dtoverlay=gpio-ir,gpio_pin=22
It is working for Raspbery Pi 1 - for TV Samsung, Sound Bar Creative and 
Air Condition!
Thanks for help.
It is part of bigger project: 
https://github.com/MariuszFerdyn/AirConditionIoTCentral - anyway you can 
link it to LIRC links.
Mariusz
On 9/13/2025 5:58 PM, Sean Young wrote:
> On Sat, Sep 13, 2025 at 11:34:59AM +0200, Mariusz Ferdyn wrote:
>> I am using:
>>
>> IR Receiver + Wire - Iduino SE027
>>
>> IR 940nm Transmitter + Wire - Iduino SE028
>>
>>
>> I can record:
>>
>> ir-ctl -rtv.ir -d /dev/lirc1
>>
>> cat tv.ir
>> +4541 -4401 +603 -1622 +623 -1631 +617 -1621 +629 -494 +623 -505 +623 -506
>> +622 -505 +624 -504 +627 -1620 +621 -1623 +629 -1630 +606 -507 +632 -495
>> +621 -504 +623 -505 +625 -504 +622 -505 +624 -1639 +634 -480 +622 -503 +649
>> -481 +622 -506 +621 -506 +623 -505 +649 -1601 +624 -500 +649 -1600 +617
>> -1625 +621 -1627 +619 -1623 +632 -1619 +613 -1623 +646 -24922
>> +4519 -4404 +615 -1624 +618 -1626 +644 -1601 +647 -479 +648 -481 +654 -476
>> +621 -504 +624 -505 +647 -1600 +647 -1599 +622 -1624 +627 -510 +646 -480
>> +645 -491 +606 -508 +620 -502 +649 -477 +626 -1625 +627 -493 +652 -481 +642
>> -486 +630 -496 +645 -475 +622 -503 +622 -1626 +645 -482 +623 -1635 +634
>> -1600 +618 -1625 +620 -1625 +640 -1606 +631 -1617 +647 -27229
>> +4532 -4394 +641 -1607 +610 -1626 +622 -1626 +643 -481 +647 -480 +621 -514
>> +646 -474 +647 -490 +642 -1598 +642 -1600 +643 -1601 +644 -481 +647 -483
>> +657 -470 +644 -482 +648 -482 +644 -482 +647 -1601 +619 -507 +647 -481 +648
>> -479 +627 -502 +643 -483 +644 -485 +643 -1603 +646 -482 +645 -1601 +642
>> -1613 +616 -1620 +645 -1599 +642 -1604 +642 -1603 +655 -19502
>> +4556 -4370 +641 -1605 +642 -1605 +638 -1602 +643 -484 +644 -485 +645 -484
>> +642 -484 +644 -483 +643 -1614 +639 -1596 +639 -1607 +639 -484 +643 -485
>> +643 -484 +644 -485 +656 -472 +643 -487 +642 -1603 +647 -488 +635 -483 +644
>> -483 +642 -485 +643 -488 +652 -474 +643 -1604 +642 -484 +642 -1605 +641
>> -1607 +640 -1615 +636 -1594 +641 -1623 +626 -1601 +640 -21768
>>
>>
>>
>> but when I execute:
>>
>> ir-ctl -stv.ir
>> warning: tv.ir:4: trailing space ignored
>>
>>
>> I see that IR is working (Iduino SE028 has LED and using my mobile camera),
>> but TV is not switching ON.
> That's odd.
>
> 1) The first thing that springs to mind is that you're not
> setting the transmit carrier. This is necx so you could try:
>
> ir-ctl -c 38400 -stv.ir
>
> Note this should be almost equivalent:
>
> ir-ctl -S necx:0x70702
>
> This does not repeat it for four times, but this does:
>
> ir-ctl -S necx:0x70702 -S necx:0x70702 -S necx:0x70702 -S necx:0x70702
>
> 2) What raspberry pi OS and hardware are you using?
>
> 3) Since you're using gpio-ir-tx you need a raspberry pi which isn't ancient.
> Beter to use pwm-ir-tx on a recent kernel.
>
> 4) Can you do ir-ctl -r in one window and ir-ctl -s in another? Is the output
> what you expect?
>
>> cat /etc/lirc/lirc_options.conf
>> # These are the default options to lircd, if installed as
>> # /etc/lirc/lirc_options.conf. See the lircd(8) and lircmd(8)
>> # manpages for info on the different options.
>> #
>> # Some tools including mode2 and irw uses values such as
>> # driver, device, plugindir and loglevel as fallback values
>> # in not defined elsewhere.
>>
>> [lircd]
>> nodaemon    = False
>> driver     = devinput
>> device     = auto
>> output     = /var/run/lirc/lircd
>> pidfile     = /var/run/lirc/lircd.pid
>> plugindir    = /usr/lib/arm-linux-gnueabihf/lirc/plugins
>> permission   = 666
>> allow-simulate = No
>> repeat-max   = 600
>> #effective-user =
>> #listen     = [address:]port
>> #connect    = host[:port]
>> #loglevel    = 6
>> #release    = true
>> #release_suffix = _EVUP
>> #logfile    = ...
>> #driver-options = ...
>>
>> [lircmd]
>> uinput     = False
>> nodaemon    = False
>>
>> # [modinit]
>> # code = /usr/sbin/modprobe lirc_serial
>> # code1 = /usr/bin/setfacl -m g:lirc:rw /dev/uinput
>> # code2 = ...
>>
>>
>> # [lircd-uinput]
>> # add-release-events = False
>> # release-timeout  = 200
>> # release-suffix   = _EVUP
>>
>> driver  = default
>> device  = /dev/lirc0
>>
>> driver  = default
>> device  = /dev/lirc0
> The lirc daemon is not used at all in your way of doing this. Which makes
> it off-topic for this list.
>
>
> Sean
>

On Sat, Sep 13, 2025 at 06:17:42PM +0200, Mariusz Ferdyn wrote:
> I did the following:
> 
> 
> ir-ctl -c 38400 -r -d /dev/lirc1
> warning: /dev/lirc1: does not support setting send carrier
> +4539 -4387 +625 -1624 +622 -1627 +615 -1617 +626 -499 +633 -495 +629 -499
> +629 -500 +629 -499 +630 -1631 +624 -1611 +624 -1617 +626 -498 +629 -497
> +629 -500 +646 -483 +631 -498 +628 -498 +628 -1618 +628 -498 +629 -499 +628
> -499 +627 -504 +616 -522 +618 -497 +628 -1618 +626 -508 +621 -1628 +628
> -1606 +614 -1648 +599 -1643 +595 -1649 +586 -1640 +605 -20639
> +4516 -4412 +599 -1641 +603 -1648 +597 -1647 +597 -522 +628 -500 +607 -521
> +606 -522 +605 -522 +608 -1641 +602 -1656 +596 -1643 +605 -511 +607 -519
> +605 -522 +607 -522 +606 -523 +621 -507 +606 -1645 +609 -513 +605 -522 +606
> -522 +606 -536 +602 -519 +609 -511 +611 -1639 +601 -522 +605 -1664 +582
> -1642 +604 -1644 +610 -1642 +600 -1635 +603 -1641 +603 -22905
The first number should be near +9000. The reason the TV is not responding
is because garbage is being sent.
> +4521 -4404 +605 -1636 +611 -1632 +616 -1637 +609 -508 +636 -490 +656 -474
> +640 -487 +615 -511 +643 -1605 +641 -1617 +637 -1608 +625 -486 +611 -515
> +641 -486 +643 -485 +641 -486 +642 -489 +639 -1620 +624 -485 +644 -485 +643
> -486 +641 -486 +642 -495 +604 -515 +643 -1609 +650 -478 +634 -1604 +611
> -1636 +637 -1606 +638 -1616 +653 -1592 +628 -1612 +632 -24149
> +4546 -4387 +632 -1603 +643 -1604 +641 -1606 +636 -486 +641 -495 +635 -485
> +641 -488 +641 -487 +643 -1608 +638 -1604 +639 -1629 +632 -479 +640 -487
> +667 -457 +634 -485 +641 -489 +650 -477 +632 -1614 +648 -489 +648 -469 +638
> -487 +640 -487 +636 -493 +637 -490 +640 -1608 +638 -492 +645 -1600 +635
> -1609 +635 -1610 +634 -1611 +635 -1621 +639 -1607 +621 -26450
> 
> 
> 
> +4484 -4439 +575 -1666 +579 -1663 +581 -1662 +582 -545 +582 -544 +583 -545
> +589 -539 +583 -546 +605 -1640 +581 -1665 +580 -1663 +607 -520 +594 -540
> +586 -548 +595 -521 +582 -544 +583 -544 +583 -1665 +582 -544 +584 -543 +623
> -506 +607 -520 +607 -519 +609 -530 +597 -1639 +606 -519 +624 -1631 +608
> -1630 +606 -1638 +608 -1638 +607 -1639 +606 -1653 +600 -28186
> +4516 -4412 +603 -1637 +608 -1639 +604 -1637 +608 -518 +610 -517 +610 -518
> +634 -502 +612 -507 +615 -1644 +603 -1641 +595 -1636 +618 -513 +610 -510
> +610 -517 +628 -502 +636 -492 +610 -517 +612 -1639 +607 -516 +625 -503 +612
> -516 +610 -517 +618 -511 +610 -517 +636 -1614 +631 -492 +612 -1636 +610
> -1636 +623 -1636 +607 -1634 +623 -1609 +611 -1642 +606 -20470
> 
> It is during reading and - warning: /dev/lirc1: does not support setting
> send carrier - is it hardware problem?
That's a software problem. I don't understand this; the gpio-ir-tx driver
has supported setting the tx carrier since the earliest version. 
Could you please send the dmesg please? I'd like to see the kernel version
and the IR messages.
> Each time I see different digits.
> 
> 
> I am using Raspbery Pi 1. Should I use newer hardware?
Generating the carrier wave on Raspberry Pi 1 in software might not work.
I would recommend either faster hardware or using the pwm-ir-tx driver.
Still the not being able to set the carrier needs an explanation.
> cat /etc/os-release
> PRETTY_NAME="Raspbian GNU/Linux 12 (bookworm)"
> NAME="Raspbian GNU/Linux"
> VERSION_ID="12"
> VERSION="12 (bookworm)"
> VERSION_CODENAME=bookworm
> ID=raspbian
> ID_LIKE=debian
> HOME_URL="http://www.raspbian.org/"
> SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
> BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
> 
> 
> ir-ctl -c 38400 -screative.ir
> and in other window ir-ctl -c 38400 -r -d /dev/lirc1
> Each time I execute ir-ctl -c 38400 -screative.ir I receive different digits
> - but not series only one line like:
> 
> 
> +43 -20874
> 
> content of creative.ir is:
> 
> cat creative.ir      +9056 -4514 +572 -547 +593 -538 +611 -522 +610
> -522 +610 -522 +587 -1694 +586 -538 +607 -520 +609 -1658 +583 -1685 +585
> -1682 +605 -1667 +605 -1660 +606 -523 +614 -1655 +623 -1646 +614 -1653 +609
> -520 +611 -522 +611 -1659 +608 -518 +615 -521 +611 -519 +626 -511 +615 -515
> +612 -1657 +635 -1633 +610 -520 +613 -1657 +620 -1650 +608 -1657 +610 -1657
> +610 -32641
> +9082 -2236 +609 -31152
> +9051 -2262 +607 -12929
There is definitely a problem there. The IR looks like valid nec or necx
with some repeats, looks good. There should be no issue sending and receiving
that.
Sean

I did the following:
ir-ctl -c 38400 -r -d /dev/lirc1
warning: /dev/lirc1: does not support setting send carrier
+4539 -4387 +625 -1624 +622 -1627 +615 -1617 +626 -499 +633 -495 +629 
-499 +629 -500 +629 -499 +630 -1631 +624 -1611 +624 -1617 +626 -498 +629 
-497 +629 -500 +646 -483 +631 -498 +628 -498 +628 -1618 +628 -498 +629 
-499 +628 -499 +627 -504 +616 -522 +618 -497 +628 -1618 +626 -508 +621 
-1628 +628 -1606 +614 -1648 +599 -1643 +595 -1649 +586 -1640 +605 -20639
+4516 -4412 +599 -1641 +603 -1648 +597 -1647 +597 -522 +628 -500 +607 
-521 +606 -522 +605 -522 +608 -1641 +602 -1656 +596 -1643 +605 -511 +607 
-519 +605 -522 +607 -522 +606 -523 +621 -507 +606 -1645 +609 -513 +605 
-522 +606 -522 +606 -536 +602 -519 +609 -511 +611 -1639 +601 -522 +605 
-1664 +582 -1642 +604 -1644 +610 -1642 +600 -1635 +603 -1641 +603 -22905
+4521 -4404 +605 -1636 +611 -1632 +616 -1637 +609 -508 +636 -490 +656 
-474 +640 -487 +615 -511 +643 -1605 +641 -1617 +637 -1608 +625 -486 +611 
-515 +641 -486 +643 -485 +641 -486 +642 -489 +639 -1620 +624 -485 +644 
-485 +643 -486 +641 -486 +642 -495 +604 -515 +643 -1609 +650 -478 +634 
-1604 +611 -1636 +637 -1606 +638 -1616 +653 -1592 +628 -1612 +632 -24149
+4546 -4387 +632 -1603 +643 -1604 +641 -1606 +636 -486 +641 -495 +635 
-485 +641 -488 +641 -487 +643 -1608 +638 -1604 +639 -1629 +632 -479 +640 
-487 +667 -457 +634 -485 +641 -489 +650 -477 +632 -1614 +648 -489 +648 
-469 +638 -487 +640 -487 +636 -493 +637 -490 +640 -1608 +638 -492 +645 
-1600 +635 -1609 +635 -1610 +634 -1611 +635 -1621 +639 -1607 +621 -26450
+4484 -4439 +575 -1666 +579 -1663 +581 -1662 +582 -545 +582 -544 +583 
-545 +589 -539 +583 -546 +605 -1640 +581 -1665 +580 -1663 +607 -520 +594 
-540 +586 -548 +595 -521 +582 -544 +583 -544 +583 -1665 +582 -544 +584 
-543 +623 -506 +607 -520 +607 -519 +609 -530 +597 -1639 +606 -519 +624 
-1631 +608 -1630 +606 -1638 +608 -1638 +607 -1639 +606 -1653 +600 -28186
+4516 -4412 +603 -1637 +608 -1639 +604 -1637 +608 -518 +610 -517 +610 
-518 +634 -502 +612 -507 +615 -1644 +603 -1641 +595 -1636 +618 -513 +610 
-510 +610 -517 +628 -502 +636 -492 +610 -517 +612 -1639 +607 -516 +625 
-503 +612 -516 +610 -517 +618 -511 +610 -517 +636 -1614 +631 -492 +612 
-1636 +610 -1636 +623 -1636 +607 -1634 +623 -1609 +611 -1642 +606 -20470
It is during reading and - warning: /dev/lirc1: does not support setting 
send carrier - is it hardware problem?
Each time I see different digits.
I am using Raspbery Pi 1. Should I use newer hardware?
 cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 12 (bookworm)"
NAME="Raspbian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
ir-ctl -c 38400 -screative.ir
and in other window ir-ctl -c 38400 -r -d /dev/lirc1
Each time I execute ir-ctl -c 38400 -screative.ir I receive different 
digits - but not series only one line like:
+43 -20874
content of creative.ir is:
cat creative.ir      +9056 -4514 +572 -547 +593 -538 +611 -522 +610 
-522 +610 -522 +587 -1694 +586 -538 +607 -520 +609 -1658 +583 -1685 +585 
-1682 +605 -1667 +605 -1660 +606 -523 +614 -1655 +623 -1646 +614 -1653 
+609 -520 +611 -522 +611 -1659 +608 -518 +615 -521 +611 -519 +626 -511 
+615 -515 +612 -1657 +635 -1633 +610 -520 +613 -1657 +620 -1650 +608 
-1657 +610 -1657 +610 -32641
+9082 -2236 +609 -31152
+9051 -2262 +607 -12929
Mariusz Ferdyn
On 9/13/2025 5:58 PM, Sean Young wrote:
> On Sat, Sep 13, 2025 at 11:34:59AM +0200, Mariusz Ferdyn wrote:
>> I am using:
>>
>> IR Receiver + Wire - Iduino SE027
>>
>> IR 940nm Transmitter + Wire - Iduino SE028
>>
>>
>> I can record:
>>
>> ir-ctl -rtv.ir -d /dev/lirc1
>>
>> cat tv.ir
>> +4541 -4401 +603 -1622 +623 -1631 +617 -1621 +629 -494 +623 -505 +623 -506
>> +622 -505 +624 -504 +627 -1620 +621 -1623 +629 -1630 +606 -507 +632 -495
>> +621 -504 +623 -505 +625 -504 +622 -505 +624 -1639 +634 -480 +622 -503 +649
>> -481 +622 -506 +621 -506 +623 -505 +649 -1601 +624 -500 +649 -1600 +617
>> -1625 +621 -1627 +619 -1623 +632 -1619 +613 -1623 +646 -24922
>> +4519 -4404 +615 -1624 +618 -1626 +644 -1601 +647 -479 +648 -481 +654 -476
>> +621 -504 +624 -505 +647 -1600 +647 -1599 +622 -1624 +627 -510 +646 -480
>> +645 -491 +606 -508 +620 -502 +649 -477 +626 -1625 +627 -493 +652 -481 +642
>> -486 +630 -496 +645 -475 +622 -503 +622 -1626 +645 -482 +623 -1635 +634
>> -1600 +618 -1625 +620 -1625 +640 -1606 +631 -1617 +647 -27229
>> +4532 -4394 +641 -1607 +610 -1626 +622 -1626 +643 -481 +647 -480 +621 -514
>> +646 -474 +647 -490 +642 -1598 +642 -1600 +643 -1601 +644 -481 +647 -483
>> +657 -470 +644 -482 +648 -482 +644 -482 +647 -1601 +619 -507 +647 -481 +648
>> -479 +627 -502 +643 -483 +644 -485 +643 -1603 +646 -482 +645 -1601 +642
>> -1613 +616 -1620 +645 -1599 +642 -1604 +642 -1603 +655 -19502
>> +4556 -4370 +641 -1605 +642 -1605 +638 -1602 +643 -484 +644 -485 +645 -484
>> +642 -484 +644 -483 +643 -1614 +639 -1596 +639 -1607 +639 -484 +643 -485
>> +643 -484 +644 -485 +656 -472 +643 -487 +642 -1603 +647 -488 +635 -483 +644
>> -483 +642 -485 +643 -488 +652 -474 +643 -1604 +642 -484 +642 -1605 +641
>> -1607 +640 -1615 +636 -1594 +641 -1623 +626 -1601 +640 -21768
>>
>>
>>
>> but when I execute:
>>
>> ir-ctl -stv.ir
>> warning: tv.ir:4: trailing space ignored
>>
>>
>> I see that IR is working (Iduino SE028 has LED and using my mobile camera),
>> but TV is not switching ON.
> That's odd.
>
> 1) The first thing that springs to mind is that you're not
> setting the transmit carrier. This is necx so you could try:
>
> ir-ctl -c 38400 -stv.ir
>
> Note this should be almost equivalent:
>
> ir-ctl -S necx:0x70702
>
> This does not repeat it for four times, but this does:
>
> ir-ctl -S necx:0x70702 -S necx:0x70702 -S necx:0x70702 -S necx:0x70702
>
> 2) What raspberry pi OS and hardware are you using?
>
> 3) Since you're using gpio-ir-tx you need a raspberry pi which isn't ancient.
> Beter to use pwm-ir-tx on a recent kernel.
>
> 4) Can you do ir-ctl -r in one window and ir-ctl -s in another? Is the output
> what you expect?
>
>> cat /etc/lirc/lirc_options.conf
>> # These are the default options to lircd, if installed as
>> # /etc/lirc/lirc_options.conf. See the lircd(8) and lircmd(8)
>> # manpages for info on the different options.
>> #
>> # Some tools including mode2 and irw uses values such as
>> # driver, device, plugindir and loglevel as fallback values
>> # in not defined elsewhere.
>>
>> [lircd]
>> nodaemon    = False
>> driver     = devinput
>> device     = auto
>> output     = /var/run/lirc/lircd
>> pidfile     = /var/run/lirc/lircd.pid
>> plugindir    = /usr/lib/arm-linux-gnueabihf/lirc/plugins
>> permission   = 666
>> allow-simulate = No
>> repeat-max   = 600
>> #effective-user =
>> #listen     = [address:]port
>> #connect    = host[:port]
>> #loglevel    = 6
>> #release    = true
>> #release_suffix = _EVUP
>> #logfile    = ...
>> #driver-options = ...
>>
>> [lircmd]
>> uinput     = False
>> nodaemon    = False
>>
>> # [modinit]
>> # code = /usr/sbin/modprobe lirc_serial
>> # code1 = /usr/bin/setfacl -m g:lirc:rw /dev/uinput
>> # code2 = ...
>>
>>
>> # [lircd-uinput]
>> # add-release-events = False
>> # release-timeout  = 200
>> # release-suffix   = _EVUP
>>
>> driver  = default
>> device  = /dev/lirc0
>>
>> driver  = default
>> device  = /dev/lirc0
> The lirc daemon is not used at all in your way of doing this. Which makes
> it off-topic for this list.
>
>
> Sean
>

On Sat, Sep 13, 2025 at 11:34:59AM +0200, Mariusz Ferdyn wrote:
> I am using:
> 
> IR Receiver + Wire - Iduino SE027
> 
> IR 940nm Transmitter + Wire - Iduino SE028
> 
> 
> I can record:
> 
> ir-ctl -rtv.ir -d /dev/lirc1
> 
> cat tv.ir
> +4541 -4401 +603 -1622 +623 -1631 +617 -1621 +629 -494 +623 -505 +623 -506
> +622 -505 +624 -504 +627 -1620 +621 -1623 +629 -1630 +606 -507 +632 -495
> +621 -504 +623 -505 +625 -504 +622 -505 +624 -1639 +634 -480 +622 -503 +649
> -481 +622 -506 +621 -506 +623 -505 +649 -1601 +624 -500 +649 -1600 +617
> -1625 +621 -1627 +619 -1623 +632 -1619 +613 -1623 +646 -24922
> +4519 -4404 +615 -1624 +618 -1626 +644 -1601 +647 -479 +648 -481 +654 -476
> +621 -504 +624 -505 +647 -1600 +647 -1599 +622 -1624 +627 -510 +646 -480
> +645 -491 +606 -508 +620 -502 +649 -477 +626 -1625 +627 -493 +652 -481 +642
> -486 +630 -496 +645 -475 +622 -503 +622 -1626 +645 -482 +623 -1635 +634
> -1600 +618 -1625 +620 -1625 +640 -1606 +631 -1617 +647 -27229
> +4532 -4394 +641 -1607 +610 -1626 +622 -1626 +643 -481 +647 -480 +621 -514
> +646 -474 +647 -490 +642 -1598 +642 -1600 +643 -1601 +644 -481 +647 -483
> +657 -470 +644 -482 +648 -482 +644 -482 +647 -1601 +619 -507 +647 -481 +648
> -479 +627 -502 +643 -483 +644 -485 +643 -1603 +646 -482 +645 -1601 +642
> -1613 +616 -1620 +645 -1599 +642 -1604 +642 -1603 +655 -19502
> +4556 -4370 +641 -1605 +642 -1605 +638 -1602 +643 -484 +644 -485 +645 -484
> +642 -484 +644 -483 +643 -1614 +639 -1596 +639 -1607 +639 -484 +643 -485
> +643 -484 +644 -485 +656 -472 +643 -487 +642 -1603 +647 -488 +635 -483 +644
> -483 +642 -485 +643 -488 +652 -474 +643 -1604 +642 -484 +642 -1605 +641
> -1607 +640 -1615 +636 -1594 +641 -1623 +626 -1601 +640 -21768
> 
> 
> 
> but when I execute:
> 
> ir-ctl -stv.ir
> warning: tv.ir:4: trailing space ignored
> 
> 
> I see that IR is working (Iduino SE028 has LED and using my mobile camera),
> but TV is not switching ON.
That's odd. 
1) The first thing that springs to mind is that you're not
setting the transmit carrier. This is necx so you could try:
ir-ctl -c 38400 -stv.ir 
Note this should be almost equivalent:
ir-ctl -S necx:0x70702
This does not repeat it for four times, but this does:
ir-ctl -S necx:0x70702 -S necx:0x70702 -S necx:0x70702 -S necx:0x70702
2) What raspberry pi OS and hardware are you using?
3) Since you're using gpio-ir-tx you need a raspberry pi which isn't ancient.
Beter to use pwm-ir-tx on a recent kernel.
4) Can you do ir-ctl -r in one window and ir-ctl -s in another? Is the output
what you expect?
> cat /etc/lirc/lirc_options.conf
> # These are the default options to lircd, if installed as
> # /etc/lirc/lirc_options.conf. See the lircd(8) and lircmd(8)
> # manpages for info on the different options.
> #
> # Some tools including mode2 and irw uses values such as
> # driver, device, plugindir and loglevel as fallback values
> # in not defined elsewhere.
> 
> [lircd]
> nodaemon    = False
> driver     = devinput
> device     = auto
> output     = /var/run/lirc/lircd
> pidfile     = /var/run/lirc/lircd.pid
> plugindir    = /usr/lib/arm-linux-gnueabihf/lirc/plugins
> permission   = 666
> allow-simulate = No
> repeat-max   = 600
> #effective-user =
> #listen     = [address:]port
> #connect    = host[:port]
> #loglevel    = 6
> #release    = true
> #release_suffix = _EVUP
> #logfile    = ...
> #driver-options = ...
> 
> [lircmd]
> uinput     = False
> nodaemon    = False
> 
> # [modinit]
> # code = /usr/sbin/modprobe lirc_serial
> # code1 = /usr/bin/setfacl -m g:lirc:rw /dev/uinput
> # code2 = ...
> 
> 
> # [lircd-uinput]
> # add-release-events = False
> # release-timeout  = 200
> # release-suffix   = _EVUP
> 
> driver  = default
> device  = /dev/lirc0
> 
> driver  = default
> device  = /dev/lirc0
The lirc daemon is not used at all in your way of doing this. Which makes
it off-topic for this list.
Sean

I am using:
IR Receiver + Wire - Iduino SE027
IR 940nm Transmitter + Wire - Iduino SE028
I can record:
ir-ctl -rtv.ir -d /dev/lirc1
cat tv.ir
+4541 -4401 +603 -1622 +623 -1631 +617 -1621 +629 -494 +623 -505 +623 
-506 +622 -505 +624 -504 +627 -1620 +621 -1623 +629 -1630 +606 -507 +632 
-495 +621 -504 +623 -505 +625 -504 +622 -505 +624 -1639 +634 -480 +622 
-503 +649 -481 +622 -506 +621 -506 +623 -505 +649 -1601 +624 -500 +649 
-1600 +617 -1625 +621 -1627 +619 -1623 +632 -1619 +613 -1623 +646 -24922
+4519 -4404 +615 -1624 +618 -1626 +644 -1601 +647 -479 +648 -481 +654 
-476 +621 -504 +624 -505 +647 -1600 +647 -1599 +622 -1624 +627 -510 +646 
-480 +645 -491 +606 -508 +620 -502 +649 -477 +626 -1625 +627 -493 +652 
-481 +642 -486 +630 -496 +645 -475 +622 -503 +622 -1626 +645 -482 +623 
-1635 +634 -1600 +618 -1625 +620 -1625 +640 -1606 +631 -1617 +647 -27229
+4532 -4394 +641 -1607 +610 -1626 +622 -1626 +643 -481 +647 -480 +621 
-514 +646 -474 +647 -490 +642 -1598 +642 -1600 +643 -1601 +644 -481 +647 
-483 +657 -470 +644 -482 +648 -482 +644 -482 +647 -1601 +619 -507 +647 
-481 +648 -479 +627 -502 +643 -483 +644 -485 +643 -1603 +646 -482 +645 
-1601 +642 -1613 +616 -1620 +645 -1599 +642 -1604 +642 -1603 +655 -19502
+4556 -4370 +641 -1605 +642 -1605 +638 -1602 +643 -484 +644 -485 +645 
-484 +642 -484 +644 -483 +643 -1614 +639 -1596 +639 -1607 +639 -484 +643 
-485 +643 -484 +644 -485 +656 -472 +643 -487 +642 -1603 +647 -488 +635 
-483 +644 -483 +642 -485 +643 -488 +652 -474 +643 -1604 +642 -484 +642 
-1605 +641 -1607 +640 -1615 +636 -1594 +641 -1623 +626 -1601 +640 -21768
but when I execute:
ir-ctl -stv.ir
warning: tv.ir:4: trailing space ignored
I see that IR is working (Iduino SE028 has LED and using my mobile 
camera), but TV is not switching ON.
My config:
ir-ctl -f -d /dev/lirc0
Receive features /dev/lirc0:
 - Device cannot receive
Send features /dev/lirc0:
 - Device can send raw IR
 - IR scancode encoder
 - Set carrier
 - Set duty cycle
ir-ctl -f -d /dev/lirc1
Receive features /dev/lirc1:
 - Device can receive raw IR
 - Can report decoded scancodes and protocol
 - Receiving timeout 12664 microseconds
 - Can set receiving timeout min 1 microseconds, max 1250000 microseconds
Send features /dev/lirc1:
 - Device cannot send
cat /boot/firmware/config.txt
# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
# Additional overlays and parameters are documented
# /boot/firmware/overlays/README
# Automatically load overlays for detected cameras
camera_auto_detect=1
# Automatically load overlays for detected DSI displays
display_auto_detect=1
# Automatically load initramfs files, if found
auto_initramfs=1
# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1
# Disable compensation for displays with overscan
disable_overscan=1
# Run as fast as firmware / board allows
arm_boost=1
[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1
[cm5]
dtoverlay=dwc2,dr_mode=host
[all]
dtoverlay=gpio-ir,gpio_pin=27
dtoverlay=gpio-ir-tx,gpio_pin=22
cat /etc/lirc/lirc_options.conf
# These are the default options to lircd, if installed as
# /etc/lirc/lirc_options.conf. See the lircd(8) and lircmd(8)
# manpages for info on the different options.
#
# Some tools including mode2 and irw uses values such as
# driver, device, plugindir and loglevel as fallback values
# in not defined elsewhere.
[lircd]
nodaemon    = False
driver     = devinput
device     = auto
output     = /var/run/lirc/lircd
pidfile     = /var/run/lirc/lircd.pid
plugindir    = /usr/lib/arm-linux-gnueabihf/lirc/plugins
permission   = 666
allow-simulate = No
repeat-max   = 600
#effective-user =
#listen     = [address:]port
#connect    = host[:port]
#loglevel    = 6
#release    = true
#release_suffix = _EVUP
#logfile    = ...
#driver-options = ...
[lircmd]
uinput     = False
nodaemon    = False
# [modinit]
# code = /usr/sbin/modprobe lirc_serial
# code1 = /usr/bin/setfacl -m g:lirc:rw /dev/uinput
# code2 = ...
# [lircd-uinput]
# add-release-events = False
# release-timeout  = 200
# release-suffix   = _EVUP
driver  = default
device  = /dev/lirc0
driver  = default
device  = /dev/lirc0
Any idea?

Hi Mariusz,
On Fri, Sep 12, 2025 at 08:31:30PM +0200, Mariusz Ferdyn wrote:
> I have these devices:
> 
> IR Receiver + Wire - Iduino SE027
> 
> IR 940nm Transmitter + Wire - Iduino SE028
> 
> when I issue: ir-ctl -f -d /dev/lirc0 - I see:
> Receive features /dev/lirc0:
> - Device can receive raw IR
> - Can report decoded scancodes and protocol
> - Receiving timeout 12664 microseconds
> - Can set receiving timeout min 1 microseconds, max 1250000 microseconds
> Send features /dev/lirc0:
> - Device cannot send
You should have two /dev/lirc devices, /dev/lirc0 and /dev/lirc1. One is for
sending and one is for receiving.
> My config is:
> 
> cat /etc/modules
> # /etc/modules: kernel modules to load at boot time.
> #
> # This file contains the names of kernel modules that should be loaded
> # at boot time, one per line. Lines beginning with "#" are ignored.
> # Parameters can be specified after the module name.
> 
> i2c-dev
> lirc_dev
> lirc_rpi gpio_in_pin=27 gpio_out_pin=22
> lirc_dev
> lirc_rpi gpio_in_pin=27 gpio_out_pin=22
> lirc_dev
> lirc_rpi gpio_in_pin=27 gpio_out_pin=22
> lirc_dev
> lirc_rpi gpio_in_pin=27 gpio_out_pin=22
> lirc_dev
> lirc_rpi gpio_in_pin=27 gpio_out_pin=22
lirc_rpi is no longer supported/used on recent Raspberry Pi OS. Unless you're
using an ancient version, these lines do nothing any more.
> cat /boot/firmware/config.txt
> # For more options and information see
> # http://rptl.io/configtxt
> # Some settings may impact device functionality. See link above for details
> 
> # Uncomment some or all of these to enable the optional hardware interfaces
> #dtparam=i2c_arm=on
> #dtparam=i2s=on
> #dtparam=spi=on
> 
> # Enable audio (loads snd_bcm2835)
> dtparam=audio=on
> 
> # Additional overlays and parameters are documented
> # /boot/firmware/overlays/README
> 
> # Automatically load overlays for detected cameras
> camera_auto_detect=1
> 
> # Automatically load overlays for detected DSI displays
> display_auto_detect=1
> 
> # Automatically load initramfs files, if found
> auto_initramfs=1
> 
> # Enable DRM VC4 V3D driver
> dtoverlay=vc4-kms-v3d
> max_framebuffers=2
> 
> # Don't have the firmware create an initial video= setting in cmdline.txt.
> # Use the kernel's default instead.
> disable_fw_kms_setup=1
> 
> # Disable compensation for displays with overscan
> disable_overscan=1
> 
> # Run as fast as firmware / board allows
> arm_boost=1
> 
> [cm4]
> # Enable host mode on the 2711 built-in XHCI USB controller.
> # This line should be removed if the legacy DWC2 controller is required
> # (e.g. for USB device mode) or if USB support is not required.
> otg_mode=1
> 
> [cm5]
> dtoverlay=dwc2,dr_mode=host
> 
> [all]
> dtoverlay=gpio-ir,gpio_pin=27
You'll need to enable gpio-ir-tx or pwm-ir-tx with the correct pin for
sending; and use the correct /dev/lirc[01] device.
Let us know how you've connected things and what version of Raspberry Pi OS
you're using.
Thanks,
Sean

I have these devices:
IR Receiver + Wire - Iduino SE027
IR 940nm Transmitter + Wire - Iduino SE028
when I issue: ir-ctl -f -d /dev/lirc0 - I see:
Receive features /dev/lirc0:
 - Device can receive raw IR
 - Can report decoded scancodes and protocol
 - Receiving timeout 12664 microseconds
 - Can set receiving timeout min 1 microseconds, max 1250000 microseconds
Send features /dev/lirc0:
 - Device cannot send
My config is:
cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.
i2c-dev
lirc_dev
lirc_rpi gpio_in_pin=27 gpio_out_pin=22
lirc_dev
lirc_rpi gpio_in_pin=27 gpio_out_pin=22
lirc_dev
lirc_rpi gpio_in_pin=27 gpio_out_pin=22
lirc_dev
lirc_rpi gpio_in_pin=27 gpio_out_pin=22
lirc_dev
lirc_rpi gpio_in_pin=27 gpio_out_pin=22
cat /boot/firmware/config.txt
# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
# Additional overlays and parameters are documented
# /boot/firmware/overlays/README
# Automatically load overlays for detected cameras
camera_auto_detect=1
# Automatically load overlays for detected DSI displays
display_auto_detect=1
# Automatically load initramfs files, if found
auto_initramfs=1
# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1
# Disable compensation for displays with overscan
disable_overscan=1
# Run as fast as firmware / board allows
arm_boost=1
[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1
[cm5]
dtoverlay=dwc2,dr_mode=host
[all]
dtoverlay=gpio-ir,gpio_pin=27

Hi, 
I need help controlling a Sony KDL-52W5500 TV via LIRC but don't have the original remote.
**My setup:**
- NixOS
- IguanaWorks USB IR Transceiver (ID 1781:0938) 
- Device detected as /dev/lirc0
- lircd service running successfully
Looking at online LIRC databases, there are many Sony config files and I'm unsure which one is compatible with my specific model.
Could someone help me identify:
1. Which existing Sony config file might work with the KDL-52W5500?
2. Are there any generic Sony TV configs that typically work across KDL-W series models?
3. Any recommended approach for testing configs without the original remote?
The IguanaWorks transceiver appears to be working (detected and /dev/lirc0 exists), but I need the right remote configuration to start sending commands.
Any pointers?;)
-- 
Esben Stien is b0ef@e s a
 http://www. s t n m
 irc://irc. b - i . e/%23contact
 sip:b0ef@ e e
 jid:b0ef@ n n

On Sun, Jun 08, 2025 at 10:41:52AM -0400, Paul Fox wrote:
> sean wrote:
> > On Sun, Jun 08, 2025 at 06:56:39AM -0400, Paul Fox wrote:
> > > sean wrote:
> > > > On Sat, May 31, 2025 at 06:51:00PM -0400, Paul Fox wrote:
> > > > > patrick wrote:
> > > > > > I cobbled together this command on the RPi, hoping it would send the IR
> > > > > > signals to the MythTV computer in the same way the HDHR did but it doesn't
> > > > > > seem to be working. I'm running irw on the 192.168.1.2 computer but it's
> > > > > > not receiving any signals.
> > > > > > 
> > > > > > /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
> > > > > > udp-datagram:[1]192.168.1.2:5000,broadcast
> > > > > > 
> > > > > > I'm hoping someone else has done this or has experience with it and could
> > > > > > offer me some assistance please.
> > > > > 
> > > > > Unless something has changed recently (and I doubt it), irtext2udp
> > > > > is broken, because it matches the documentation of the UDP protocol, which
> > > > > is also broken. I submitted patches for these issues in March 2022:
> > > > > https://sourceforge.net/p/lirc/tickets/370/
> > > > > I also sent mail to the (this) list about it at the same time -- I'm sure
> > > > > it's in the archives. So that's probably at least part of your problem.
> > > > 
> > > > I've applied a fix. I think it's easier to simply fix plugins/udp.c rather
> > > > than making everything compatible with something that is clearly a bug.
> > > > 
> > > 
> > > No, I don't think you can do that. You're changing an existing
> > > protocol. There is code out in the wild that's decades old at this
> > > point, which depends on the current behavior. (I know, I wrote some:
> > > https://sourceforge.net/projects/airboard-ir/ )
> > > 
> > > If your patch were the right thing, I would have submitted it initially.
> > > 
> > > As it stands now, as soon as a new release a lirc makes it's way to
> > > debian, half the devices in my house, and likely other peoples', will
> > > stop working.
> > 
> > The lirc source tree contains two implementations of the udp protocol, one
> > uses high bit set for pulse, the other space. The documentation says high
> > bit set for pulse, and this also makes more sense. One or the other has to
> > fixed.
> 
> Can you point me at the other implementation? I didn't know there
> were two. Sigh.
So the udp protocol is implemented by irtext2udp and plugins/udp.c. It is
also documented in various places, which is pretty unambiguous that a set
bit means pulse.
If we fix irtext2udp, that breaks the users of irtext2udp, however that might
be.
If we fix plugins/udp.c, then that breaks those users.
Either way you're breaking something for someone. Might as well do the right
think and implement the protocol as it is documented.
Sean

sean wrote:
 > On Sun, Jun 08, 2025 at 06:56:39AM -0400, Paul Fox wrote:
 > > sean wrote:
 > > > On Sat, May 31, 2025 at 06:51:00PM -0400, Paul Fox wrote:
 > > > > patrick wrote:
 > > > > > I cobbled together this command on the RPi, hoping it would send the IR
 > > > > > signals to the MythTV computer in the same way the HDHR did but it doesn't
 > > > > > seem to be working. I'm running irw on the 192.168.1.2 computer but it's
 > > > > > not receiving any signals.
 > > > > > 
 > > > > > /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
 > > > > > udp-datagram:[1]192.168.1.2:5000,broadcast
 > > > > > 
 > > > > > I'm hoping someone else has done this or has experience with it and could
 > > > > > offer me some assistance please.
 > > > > 
 > > > > Unless something has changed recently (and I doubt it), irtext2udp
 > > > > is broken, because it matches the documentation of the UDP protocol, which
 > > > > is also broken. I submitted patches for these issues in March 2022:
 > > > > https://sourceforge.net/p/lirc/tickets/370/
 > > > > I also sent mail to the (this) list about it at the same time -- I'm sure
 > > > > it's in the archives. So that's probably at least part of your problem.
 > > > 
 > > > I've applied a fix. I think it's easier to simply fix plugins/udp.c rather
 > > > than making everything compatible with something that is clearly a bug.
 > > > 
 > > 
 > > No, I don't think you can do that. You're changing an existing
 > > protocol. There is code out in the wild that's decades old at this
 > > point, which depends on the current behavior. (I know, I wrote some:
 > > https://sourceforge.net/projects/airboard-ir/ )
 > > 
 > > If your patch were the right thing, I would have submitted it initially.
 > > 
 > > As it stands now, as soon as a new release a lirc makes it's way to
 > > debian, half the devices in my house, and likely other peoples', will
 > > stop working.
 > 
 > The lirc source tree contains two implementations of the udp protocol, one
 > uses high bit set for pulse, the other space. The documentation says high
 > bit set for pulse, and this also makes more sense. One or the other has to
 > fixed.
Can you point me at the other implementation? I didn't know there
were two. Sigh.
=----------------------
paul fox, pg...@fo... (arlington, ma, where it's 69.1 degrees)

On Sun, Jun 08, 2025 at 06:56:39AM -0400, Paul Fox wrote:
> sean wrote:
> > On Sat, May 31, 2025 at 06:51:00PM -0400, Paul Fox wrote:
> > > patrick wrote:
> > > > I cobbled together this command on the RPi, hoping it would send the IR
> > > > signals to the MythTV computer in the same way the HDHR did but it doesn't
> > > > seem to be working. I'm running irw on the 192.168.1.2 computer but it's
> > > > not receiving any signals.
> > > > 
> > > > /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
> > > > udp-datagram:[1]192.168.1.2:5000,broadcast
> > > > 
> > > > I'm hoping someone else has done this or has experience with it and could
> > > > offer me some assistance please.
> > > 
> > > Unless something has changed recently (and I doubt it), irtext2udp
> > > is broken, because it matches the documentation of the UDP protocol, which
> > > is also broken. I submitted patches for these issues in March 2022:
> > > https://sourceforge.net/p/lirc/tickets/370/
> > > I also sent mail to the (this) list about it at the same time -- I'm sure
> > > it's in the archives. So that's probably at least part of your problem.
> > 
> > I've applied a fix. I think it's easier to simply fix plugins/udp.c rather
> > than making everything compatible with something that is clearly a bug.
> > 
> 
> No, I don't think you can do that. You're changing an existing
> protocol. There is code out in the wild that's decades old at this
> point, which depends on the current behavior. (I know, I wrote some:
> https://sourceforge.net/projects/airboard-ir/ )
> 
> If your patch were the right thing, I would have submitted it initially.
> 
> As it stands now, as soon as a new release a lirc makes it's way to
> debian, half the devices in my house, and likely other peoples', will
> stop working.
The lirc source tree contains two implementations of the udp protocol, one
uses high bit set for pulse, the other space. The documentation says high
bit set for pulse, and this also makes more sense. One or the other has to
fixed.
Sean

sean wrote:
 > On Sat, May 31, 2025 at 06:51:00PM -0400, Paul Fox wrote:
 > > patrick wrote:
 > > > I cobbled together this command on the RPi, hoping it would send the IR
 > > > signals to the MythTV computer in the same way the HDHR did but it doesn't
 > > > seem to be working. I'm running irw on the 192.168.1.2 computer but it's
 > > > not receiving any signals.
 > > > 
 > > > /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
 > > > udp-datagram:[1]192.168.1.2:5000,broadcast
 > > > 
 > > > I'm hoping someone else has done this or has experience with it and could
 > > > offer me some assistance please.
 > > 
 > > Unless something has changed recently (and I doubt it), irtext2udp
 > > is broken, because it matches the documentation of the UDP protocol, which
 > > is also broken. I submitted patches for these issues in March 2022:
 > > https://sourceforge.net/p/lirc/tickets/370/
 > > I also sent mail to the (this) list about it at the same time -- I'm sure
 > > it's in the archives. So that's probably at least part of your problem.
 > 
 > I've applied a fix. I think it's easier to simply fix plugins/udp.c rather
 > than making everything compatible with something that is clearly a bug.
 > 
No, I don't think you can do that. You're changing an existing
protocol. There is code out in the wild that's decades old at this
point, which depends on the current behavior. (I know, I wrote some:
https://sourceforge.net/projects/airboard-ir/ )
If your patch were the right thing, I would have submitted it initially.
As it stands now, as soon as a new release a lirc makes it's way to
debian, half the devices in my house, and likely other peoples', will
stop working.
You can argue that the code is buggy (and I might agree), but you
can't fix it there, without causing more breakage.
paul
=----------------------
paul fox, pg...@fo... (arlington, ma, where it's 59.4 degrees)

On Sat, May 31, 2025 at 06:51:00PM -0400, Paul Fox wrote:
> patrick wrote:
> > I cobbled together this command on the RPi, hoping it would send the IR
> > signals to the MythTV computer in the same way the HDHR did but it doesn't
> > seem to be working. I'm running irw on the 192.168.1.2 computer but it's
> > not receiving any signals.
> > 
> > /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
> > udp-datagram:[1]192.168.1.2:5000,broadcast
> > 
> > I'm hoping someone else has done this or has experience with it and could
> > offer me some assistance please.
> 
> Unless something has changed recently (and I doubt it), irtext2udp
> is broken, because it matches the documentation of the UDP protocol, which
> is also broken. I submitted patches for these issues in March 2022:
> https://sourceforge.net/p/lirc/tickets/370/
> I also sent mail to the (this) list about it at the same time -- I'm sure
> it's in the archives. So that's probably at least part of your problem.
I've applied a fix. I think it's easier to simply fix plugins/udp.c rather
than making everything compatible with something that is clearly a bug.
Sean

patrick wrote:
 > I cobbled together this command on the RPi, hoping it would send the IR
 > signals to the MythTV computer in the same way the HDHR did but it doesn't
 > seem to be working. I'm running irw on the 192.168.1.2 computer but it's
 > not receiving any signals.
 > 
 > /usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat -
 > udp-datagram:[1]192.168.1.2:5000,broadcast
 > 
 > I'm hoping someone else has done this or has experience with it and could
 > offer me some assistance please.
Unless something has changed recently (and I doubt it), irtext2udp
is broken, because it matches the documentation of the UDP protocol, which
is also broken. I submitted patches for these issues in March 2022:
 https://sourceforge.net/p/lirc/tickets/370/
I also sent mail to the (this) list about it at the same time -- I'm sure
it's in the archives. So that's probably at least part of your problem.
For various reasons (mostly historical, but also having to do with my
network topology), I don't do lircd processing on the raspberry pi boxes
that are scattered around the house, each with an IR receiver. Instead,
I forward the IR to a central server, where there's an instance of
lircd running for every client. Since UDP can't make it through
my firewall, I send it over tcp, through an ssh tunnel, and convert
back to UDP at the destination.
For all of those reasons, I don't use irtext2udp. I use my own script
(attached), which takes mode2 format and converts it to the UDP
format, and sends it to a tcp port. You'll see that it sends to a port
on "localhost" -- that's because it's actually being forwarded across
an ssh tunnel.
On the receiving end, I have a listener that gets data from the other end
of the ssh tunnel. The meat of it is this line:
 socat -u tcp4-listen:88${octet},reuseaddr,fork UDP:localhost:87${destoctet}
The 88xx address is what the ssh server delivers to, and the 87xx
address is the appropriate lircd daemon.
Hope some part of this helps.
paul
=----------------------
paul fox, pg...@fo... (arlington, ma, where it's 59.2 degrees)

Hello,
My Silicondust HDHomeRun DUAL (Model: HDHR-US) ATSC tuner that I was using
for over a decade to receive and send IR signals to my MythTV box via UDP
(port 5000) has stopped working.
I have a Raspberry Pi in the same TV room that has a working IR receiver on
it so I was hoping to reproduce the function of the HDHomeRun DUAL's IR
receiver using the Raspberry Pi.
I cobbled together this command on the RPi, hoping it would send the IR
signals to the MythTV computer in the same way the HDHR did but it doesn't
seem to be working. I'm running irw on the 192.168.1.2 computer but it's
not receiving any signals.
/usr/bin/mode2 -d /dev/lirc0 | irtext2udp | socat - udp-datagram:
192.168.1.2:5000,broadcast
I'm hoping someone else has done this or has experience with it and could
offer me some assistance please.
Thanks

> I would suggest using a 7809 which drops the voltage to 9V. Someone else
> suggested a 7805, and that's not what you want because its output
> voltage is 5V which falls far short of the minimum of 8V that you cite.
No, I didn't write what output voltage I need, and certainly not that I
need 8 V at the output. But now I write that I need 5 V as the signal level.
I connect the DCD line to the Arduino Mega 2560 and use the IRremote
library.
And in reality, I don't even know which voltage regulator is used in my
circuit. The circuit is built into a DE-9F connector that I bought 20
years ago as LIRC-compatible home-brew IR-receiver. I used it for a long
time on the serial port of multiple mainboards. I can't open it without
cutting the heat shrink tubing. And that's why I'm not opening it.
Everything I know I read here: https://lirc.org/receivers.html
It is written there:
"For most standard PC serial ports this will be approximately 10V. IC2
will convert the input voltage to exactly 5V. ... So you should make
sure that your serial port delivers at least 8V of output voltage."
I need exactly 5 V for Arduino Mega 2560. And I trust that my
LIRC-compatible home-brew IR-receiver converts the input voltage to 5 V
and I get 5 V as signal level for Arduino Mega 2560. I don't have an
oscilloscope to check the signal level. I tested my LIRC-compatible
home-brew IR-Receiverwith 12 V supply voltage. It works very well with
RC5 remote control and neither IR-receivernor Arduinobroke.

On 24/03/2025 20:12, Eduard Refinius via LIRC-list wrote:
> Hello.
>
> I have a home-brew IR receiver as described on
> https://lirc.org/receivers.html
>
> I've read, that supply voltage range 8 V .. 10 V is ok for this circuit.
> Is it ok for the voltage regulator to be supplied by 12 V or is it too
> much? I don't want to damage the IR receiver.
>
>
I would suggest using a 7809 which drops the voltage to 9V. Someone else
suggested a 7805, and that's not what you want because its output
voltage is 5V which falls far short of the minimum of 8V that you cite.

The 7805 voltage regulator drops any supplied input voltage to 5V. The 7805
has a maximum voltage of around 25V. The drawback of using higher voltages
is that the 7805 needs to drop/lower the voltage more, it does so through
heat. The higher the voltage you use the more heat will need to be
dissipated by the 7805. However, the heat generated is also proportional to
the amount of current or power being used, and in this case the IR diode
draws a small amount. As such I would say 12V is safe to use, worst case
add a small heatsink to the 7805 Regulator.
On Tue, Mar 25, 2025 at 12:26 PM Eduard Refinius via LIRC-list <
lir...@li...> wrote:
> Hello.
>
> I have a home-brew IR receiver as described on
> https://lirc.org/receivers.html
>
> I've read, that supply voltage range 8 V .. 10 V is ok for this circuit.
> Is it ok for the voltage regulator to be supplied by 12 V or is it too
> much? I don't want to damage the IR receiver.
>
>
>

Hello.
I have a home-brew IR receiver as described on
https://lirc.org/receivers.html
I've read, that supply voltage range 8 V .. 10 V is ok for this circuit.
Is it ok for the voltage regulator to be supplied by 12 V or is it too
much? I don't want to damage the IR receiver.

Hi there, maybe answer to my problem is allready somewhere on the 
internet, if so please point me.
I use Lirc on my Raspberry Pi, installed with sudo apt install lirc. So 
far so good.
No I want to make a python script to interact with my OS "Raspberry Pi 
OS with desktop" 64 bit kernel 6.6. Based on Debian Bookworm. Python 3.1.
Now my python was making problems about all kind of rights on files. So 
the project became a mess and i have made a new MicroSD card.
Starting all over I have looked into the way pip i working these days. 
Virtual envirements.
So, now the Lirc, global wide installed isn't in reach of python. So I 
installed lirc with pip install lirc. Now no more problems finding Lirc.
But here is the problem, in the pip version of lirc there is no 
RawConnections to use. So, how to solve this?
Thx, in advance, Pit

On 9/16/24 10:41, Sean Young wrote:
> On Sun, Sep 15, 2024 at 01:48:19PM +0200, Mariusz Ferdyn wrote:
>> The captured codes are:
>>
>>
>> mf@pi1:~ $ mode2 -H default -d /dev/lirc0
>> Using driver default on device /dev/lirc0
>> Trying device: /dev/lirc0
>> Using device: /dev/lirc0
>> pulse 8985
>> space 4468
>> pulse 617
>> space 1651
>> pulse 601
>> space 1652
>> pulse 604
>> space 499
> -snip-
>
> This looks good, this is probably the nec protocol.
Actually, the timing is that of the NEC protocol, but the payload is 104
bytes, instead of 32 for NEC. (Air conditioning?) The second signal can
be described in the IRP notation as
{568,msb}<1,-1|1,-3>(16,-8,A:104,1,-299m){A=0xc3fe070006000400000000a2e7}
Returning to your first question:
 > I would like to send these ad-hock mode without writing them to
the config file etc. How to do it?
Lirc is not intended for this use case. I once submitted a patch to the
then-maintainer Christoph Bartelmus, who was vehemently against it,
meaning that it is cleaner if data bases reside on the server. See
http://www.harctoolbox.org/lirc_ccf.html, but note that article is not
up-to-data any longer.
Have a look at IrScrutinizer (http://www.harctoolbox.org/lirc_ccf.html);
possibly you can use it for your purpose?
Bengt