Menu
▾
▴
lirc-list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(29) |
Jul
(51) |
Aug
(40) |
Sep
(35) |
Oct
(58) |
Nov
(64) |
Dec
(70) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(111) |
Feb
(75) |
Mar
(85) |
Apr
(62) |
May
(56) |
Jun
(65) |
Jul
(67) |
Aug
(73) |
Sep
(46) |
Oct
(64) |
Nov
(55) |
Dec
(76) |
| 2002 |
Jan
(119) |
Feb
(74) |
Mar
(101) |
Apr
(128) |
May
(124) |
Jun
(138) |
Jul
(114) |
Aug
(63) |
Sep
(54) |
Oct
(135) |
Nov
(92) |
Dec
(127) |
| 2003 |
Jan
(129) |
Feb
(164) |
Mar
(129) |
Apr
(131) |
May
(181) |
Jun
(136) |
Jul
(118) |
Aug
(220) |
Sep
(116) |
Oct
(177) |
Nov
(206) |
Dec
(114) |
| 2004 |
Jan
(175) |
Feb
(222) |
Mar
(245) |
Apr
(209) |
May
(112) |
Jun
(104) |
Jul
(77) |
Aug
(115) |
Sep
(175) |
Oct
(141) |
Nov
(154) |
Dec
(190) |
| 2005 |
Jan
(198) |
Feb
(171) |
Mar
(164) |
Apr
(113) |
May
(104) |
Jun
(151) |
Jul
(107) |
Aug
(190) |
Sep
(142) |
Oct
(116) |
Nov
(113) |
Dec
(111) |
| 2006 |
Jan
(147) |
Feb
(103) |
Mar
(102) |
Apr
(75) |
May
(110) |
Jun
(82) |
Jul
(119) |
Aug
(77) |
Sep
(103) |
Oct
(188) |
Nov
(132) |
Dec
(155) |
| 2007 |
Jan
(169) |
Feb
(110) |
Mar
(113) |
Apr
(162) |
May
(107) |
Jun
(116) |
Jul
(159) |
Aug
(135) |
Sep
(135) |
Oct
(105) |
Nov
(96) |
Dec
(100) |
| 2008 |
Jan
(122) |
Feb
(93) |
Mar
(57) |
Apr
(80) |
May
(119) |
Jun
(85) |
Jul
(59) |
Aug
(73) |
Sep
(250) |
Oct
(146) |
Nov
(121) |
Dec
(72) |
| 2009 |
Jan
(193) |
Feb
(96) |
Mar
(102) |
Apr
(66) |
May
(99) |
Jun
(130) |
Jul
(206) |
Aug
(308) |
Sep
(117) |
Oct
(99) |
Nov
(170) |
Dec
(232) |
| 2010 |
Jan
(104) |
Feb
(127) |
Mar
(86) |
Apr
(111) |
May
(66) |
Jun
(44) |
Jul
(253) |
Aug
(120) |
Sep
(178) |
Oct
(220) |
Nov
(153) |
Dec
(157) |
| 2011 |
Jan
(80) |
Feb
(85) |
Mar
(129) |
Apr
(232) |
May
(236) |
Jun
(73) |
Jul
(53) |
Aug
(38) |
Sep
(23) |
Oct
(32) |
Nov
(25) |
Dec
(24) |
| 2012 |
Jan
(23) |
Feb
(43) |
Mar
(29) |
Apr
(50) |
May
(25) |
Jun
(15) |
Jul
(26) |
Aug
(26) |
Sep
(4) |
Oct
(10) |
Nov
(17) |
Dec
(18) |
| 2013 |
Jan
(12) |
Feb
(17) |
Mar
(15) |
Apr
(22) |
May
(29) |
Jun
(16) |
Jul
(15) |
Aug
(9) |
Sep
(45) |
Oct
(18) |
Nov
(21) |
Dec
(11) |
| 2014 |
Jan
(35) |
Feb
(34) |
Mar
(13) |
Apr
(14) |
May
(86) |
Jun
(23) |
Jul
(6) |
Aug
(18) |
Sep
(16) |
Oct
(36) |
Nov
(98) |
Dec
(62) |
| 2015 |
Jan
(27) |
Feb
(14) |
Mar
(5) |
Apr
(49) |
May
(27) |
Jun
(9) |
Jul
(11) |
Aug
(20) |
Sep
(26) |
Oct
(71) |
Nov
(2) |
Dec
(7) |
| 2016 |
Jan
(42) |
Feb
(3) |
Mar
(15) |
Apr
(34) |
May
(25) |
Jun
(39) |
Jul
(20) |
Aug
(85) |
Sep
(14) |
Oct
(82) |
Nov
(10) |
Dec
(34) |
| 2017 |
Jan
(29) |
Feb
(88) |
Mar
(78) |
Apr
(4) |
May
(7) |
Jun
(30) |
Jul
(4) |
Aug
(47) |
Sep
(14) |
Oct
(47) |
Nov
(5) |
Dec
(3) |
| 2018 |
Jan
(18) |
Feb
(13) |
Mar
(6) |
Apr
(8) |
May
(11) |
Jun
(1) |
Jul
(11) |
Aug
(1) |
Sep
(4) |
Oct
|
Nov
|
Dec
(23) |
| 2019 |
Jan
(5) |
Feb
(15) |
Mar
(11) |
Apr
(4) |
May
(15) |
Jun
(12) |
Jul
(4) |
Aug
(5) |
Sep
(14) |
Oct
(3) |
Nov
(10) |
Dec
|
| 2020 |
Jan
|
Feb
(5) |
Mar
(23) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2021 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(4) |
Aug
(5) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
(2) |
Dec
(13) |
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
|
Feb
|
Mar
(4) |
Apr
(3) |
May
(2) |
Jun
(4) |
Jul
(3) |
Aug
|
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
(2) |
Jun
(5) |
Jul
|
Aug
|
Sep
(12) |
Oct
|
Nov
|
Dec
|
|
From: Matthew W. <mw...@wt...> - 2025-09-15 21:23:13
|
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 |
|
From: Sean Y. <se...@me...> - 2025-09-15 12:22:47
|
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 |
|
From: Mariusz F. <mf...@fa...> - 2025-09-15 07:29:45
|
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 |
|
From: Sean Y. <se...@me...> - 2025-09-14 21:16:35
|
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 |
|
From: Mariusz F. <mf...@fa...> - 2025-09-14 15:38:38
|
@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 > |
|
From: Sean Y. <se...@me...> - 2025-09-13 21:07:40
|
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 |
|
From: Mariusz F. <mf...@fa...> - 2025-09-13 16:18:00
|
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 > |
|
From: Sean Y. <se...@me...> - 2025-09-13 15:58:35
|
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 |
|
From: Mariusz F. <mf...@fa...> - 2025-09-13 09:35:10
|
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? |
|
From: Sean Y. <se...@me...> - 2025-09-12 20:28:18
|
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 |
|
From: Mariusz F. <mf...@fa...> - 2025-09-12 18:47:12
|
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 |
|
From: Esben S. <b0...@es...> - 2025-09-08 21:01:41
|
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
|
|
From: Sean Y. <se...@me...> - 2025-06-08 20:20:20
|
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 |
|
From: Paul F. <pg...@fo...> - 2025-06-08 14:41:59
|
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) |
|
From: Sean Y. <se...@me...> - 2025-06-08 14:27:18
|
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 |
|
From: Paul F. <pg...@fo...> - 2025-06-08 10:56:51
|
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) |
|
From: Sean Y. <se...@me...> - 2025-06-08 10:26:28
|
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 |
|
From: Paul F. <pg...@fo...> - 2025-05-31 23:10:55
|
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)
|
|
From: Patrick K. <kir...@gm...> - 2025-05-31 20:59:35
|
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 |
|
From: Eduard R. <ere...@gm...> - 2025-03-28 20:47:46
|
> 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. |
|
From: Jan C. <jan...@gm...> - 2025-03-28 16:42:15
|
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. |
|
From: Umar D. <um...@gm...> - 2025-03-25 10:36:59
|
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. > > > |
|
From: Eduard R. <ere...@gm...> - 2025-03-24 19:12:48
|
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. |
|
From: Nico B. <nca...@ic...> - 2024-10-25 12:27:53
|
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 |
|
From: Bengt M. <bu...@be...> - 2024-09-16 11:45:50
|
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
|
125 messages has been excluded from this view by a project administrator.
