Description of problem: Unable to get stb to respond to irsend, using existing config files and init scripts. I am using a simple serial ir transmit led & visible led to control a disk network recvr. In Fedora 7, the config files work, in Fedora 9 they do not. When executing irsend, I observe the red led flashing , so I know that lirc is run and talking to the serial port. Version-Release number of selected component (if applicable): 0.8.4-80_cvs20080528.fc9 How reproducible: always Steps to Reproduce: 1.install lirc, custom setup in rc.local 2.copy lircd.conf to /etc 3.connect serial ir transmitter to port and dish net receiver (811) 4.execute command irsend with and parameter Actual results: blinking led, no activity from receiver Expected results: channel chanage Additional info:
Created attachment 310630 [details] dish net lircd config file with remote codes
I use this script in /etc/rc.local to configure lirc and the serial port /bin/setserial /dev/ttyS0 -G /dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200 spd_normal skip_test /sbin/modprobe lirc_serial /sbin/modprobe lirc_i2c /usr/sbin/lircd --driver=default --device=/dev/lirc1 --output=/dev/lircd1 --pidfile=/var/run/lircd1.pid /usr/sbin/lircd --device=/dev/lirc0 --output=/dev/lircd additionally I use this script to manually change or have myth tv change the receiver channels #!/bin/sh REMOTE_NAME=dish1 # wake up ir in receiver irsend --device=/dev/lircd1 send_once dish1 view sleep 0.8 irsend --device=/dev/lircd1 send_once dish1 view sleep 0.8 # for digit in $(echo $1 | sed -e 's/./& /g'); do irsend --device=/dev/lircd1 SEND_ONCE $REMOTE_NAME $digit sleep 0.20 # note, you may have to tweak the interdigit delay up a bit done finally, this is the kernel I am running Fedora (2.6.25.6-55.fc9.i686) irsend --device=/dev/lircd1 SEND_ONCE $REMOTE_NAME select
manually posting got a bit trashed, last command in channel script is to send the select command, a hack to force the 811 to display video
Hrm, one initial thing to note, which may or may not be of consequence... You've got an ATrpms lirc build mixed with the Fedora lirc bits. For sanity's sake, can you remove the ATrpms lirc bits and install only the Fedora lirc bits?
At JWilson's request I uninstalled the atrpms version of lirc and reinstalled the fedora released version instead. However I get the same results as before. I plan to compare the wave forms (o-scope) as produced from lirc to those from the physical remote to assist in determining why F7 works but F9 does not. I might be able to post images as part of the bug form.
(In reply to comment #2) > I use this script in /etc/rc.local to configure lirc and the serial port > > /bin/setserial /dev/ttyS0 -G /dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base > 115200 spd_normal skip_test One oddity here that could be interfering: you set the baud_base to 115200, but then pass in spd_normal, which is 38400. It looks like that *might* still be legit, but does changing spd_normal to spd_vhi help at all?
tried changing spd_normal to spd_vhi , no change also tried setting baud_base to 38400, also no change.
According to my limited O-Scope skills the linux produced waveform is at a much lower frequency than the remote's frequency, once I added a couple of zeros to the lircd conf file, ie: frequency 5600000 from frequency 56000 the wave approaches the hard wired remote wave form in frequency. However the 2 waveforms look different with the remote being a somewhat clean square wave, the waveform from lirc has overshoot, ringing and other artifacts. I currently don't have access to a camera to illustrate the differences. But that could change at any time, out for repair. I suppose I could try to regenerate the config file via receiving a ir signal from a pvr-250 card's ir input.
FYI I recently installed that latest update to lirc and problem remains. The current installed versions of lirc is now at 0.8.3-1.fc9. licr, lirc-devel,lirc-docs and lirc-libs are installed. Also worth noting, when tracking down a different problem, and being instructed to run this command grep video /etc/udev/rules.d/* ttys0 appears in the output [root@mythtv ~]# grep video /etc/udev/rules.d/* /etc/udev/rules.d/50-udev-default.rules:# video4linux /etc/udev/rules.d/50-udev-default.rules:KERNEL=="video0", SYMLINK+="video" /etc/udev/rules.d/50-udev-default.rules:# DVB video /etc/udev/rules.d/50-udev-default.rules:KERNEL=="video1394*", NAME="video1394/%n" /etc/udev/rules.d/51-vdr.rules:KERNEL=="dvb*", GROUP="video", MODE="0660" /etc/udev/rules.d/51-vdr.rules:#KERNEL=="ttyS0", GROUP="video", MODE="0660" /etc/udev/rules.d/51-vdr.rules:#KERNEL=="event2", GROUP="video", MODE="0660" I don't know if this makes any difference or not.
Odd, this seems to be potentially epidemic... http://www.nabble.com/transmitter-worked-in-lirc-0.8.0%2C-but-fails-with-newer-versions-tp18424344p18424344.html Have you had a chance to try regenerating the config file per comment #8? Though I'm still baffled why a self-built lirc would continue to work. (At least, I think I remember you saying a self-build lirc 0.8.3 worked fine).
No. I haven't have a chance to build a new lirc.conf file using a remote as a reference. 2 problems here, I need to find the ir receiver and then study up on how to make it work, ie: configure lirc to listen to a Hauppague(sic?) pvr-250 ir port. The last time I was able to use the ir transmitter (successfully) was under Fedora 7 using the generic lirc 0.8.2, 0.8.3 source from the lirc's web site. I have never been able to get the lirc packaged via yum updates to work, regardless of repository. Taking path of least resistance, self build always worked. using their setup script, make and make install.
I tried out irw & irrecord and neither see the dish network remote, but do see other remotes, but not all of them. maybe I'll have better luck with a direct tv recvr. ?
I tried additional remotes and the only remotes that irw and irrecord see are the 2 remotes I have from Hauppague. I somewhat expected this since the ir receiver is connected to a pvr-250. Taking a different approach, I tried loading various remote profiles for different devices. Out of the 7 different device profiles I tried, none respond to the serial ir transmitter. I tried once again to build the generic lirc but I continue to get this message from make. ERROR: Kernel configuration is invalid Probably best to quit wasting time on this and downgrade to Fedora 7.
An Interesting note here to share, When I installed F7 and used the lirc package that's from the default repos, Lirc fails to activate the stb just like f8 and f9. However when I uninstall lirc and do a setup, make and make install on f7 using the generic lirc code from their web site, the stb responds. Unfortuantely I can not build the generic lirc agains f8 and f9 with out some guidance on why it thinks the kernal config is invalid. I'd be ok sticking with f7 for a while longer but Unfortuantely atrpms no longer supports f7 so I am a bit stick on how to get a f7 box back on line with mtv. I suspect downloading the latest code bases and plowing through the build docs. Perhaps I might what to try building the repo version of Lirc and see if I have any success. Any ideas what makes the repo lirs and the generic lirc different? Any ideas on how to get past the make, main install errors on f8 and f9? thanks
Same here - also installed F9 and am using my F7 lirc config - the system receives key presses from all remotes (incl. the commands from the one I really only use for transmit) - but transmit does not do anything meaningful - on any device I have. As above I also see the control led light up. So the serial port does drive the homebrew transceiver but modulation seems to be wrong - even to the normal eye the control LED looks more red to me than before.
Hmm - I looked at the last kernel SRPM from Fedora 7 and noticed that lirc_serial wasn't there and remembered that on fedora 7 I used the lirc-kmdl from atrpms. So I excluded the lirc rpm's from the fedora 9 repository and installed the ones from atrpms (and removed lirc-doc/lib) - and now it works... [root@tv ~]# rpm -qa | grep lirc lirc-devel-0.8.4-80_cvs20080528.fc9.i386 liblirc_client0-0.8.4-80_cvs20080528.fc9.i386 lirc-kmdl-2.6.25.11-97.fc9-0.8.4-80_cvs20080528.fc9.i686 lirc-0.8.4-80_cvs20080528.fc9.i386 lirc-devices-0.8-4.fc9.noarch
Thanks for looking into this but same effect the dishnet receiver still does not respond to the ir transmitter. same waveform pattern. Like I said before the only way I've been able to get it to work is to compile the generic lirc package from source and install it. Unfortantely, I haven't been able to "connect the dots" to build it under f8 or f9.
here is what I have installed, rpm -qa | grep lirc lirc-devel-0.8.4-80_cvs20080528.fc9.i386 liblirc_client0-0.8.4-80_cvs20080528.fc9.i386 lirc-0.8.4-80_cvs20080528.fc9.i386 lirc-devices-0.8-4.fc9.noarch lirc-doc-0.8.3-1.fc9.i386 lirc-kmdl-2.6.25.11-97.fc9-0.8.4-80_cvs20080528.fc9.i686
OK, Me Bad, After I ran system update and rebooted, Lirc is now working against the receiver using the original setup and remote configuration scripts. thanks again.
So the working setup uses ATrpms lirc kernel modules built out of tree. I'm still quite curious why the in-tree lirc kernel modules apparently aren't working. ...and wow, I just noticed something that I can't believe I didn't notice sooner... In comment #2, you're using irsend via device lircd1... Which should be the lirc_i2c device, not the lirc_serial device, per the module load order. Of course, I have no explanation why the same setup works with the ATrpms kernel modules...
Forgot to mention: an examination of the ATrpms lirc kernel module build process doesn't reveal anything of interest that could explain any differences in behavior.
Going to close this out since its working now.