Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 453493 - Lirc fails to activate set top receiver when using f7 tested scripts
Summary: Lirc fails to activate set top receiver when using f7 tested scripts
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: lirc
Version: 9
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Ville Skyttä
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-01 00:37 UTC by Todd Bailey
Modified: 2008-10-13 15:29 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-13 15:29:05 UTC


Attachments (Terms of Use)
dish net lircd config file with remote codes (deleted)
2008-07-01 00:37 UTC, Todd Bailey
no flags Details

Description Todd Bailey 2008-07-01 00:37:55 UTC
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:

Comment 1 Todd Bailey 2008-07-01 00:37:55 UTC
Created attachment 310630 [details]
dish net lircd config file with remote codes

Comment 2 Todd Bailey 2008-07-01 00:43:18 UTC
 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


Comment 3 Todd Bailey 2008-07-01 00:47:34 UTC
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

Comment 4 Jarod Wilson 2008-07-01 14:55:16 UTC
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?

Comment 5 Todd Bailey 2008-07-02 14:25:50 UTC
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.

Comment 6 Jarod Wilson 2008-07-02 14:48:03 UTC
(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?



Comment 7 Todd Bailey 2008-07-02 23:41:20 UTC
tried changing spd_normal to spd_vhi , no change
also tried setting baud_base to 38400, also no change.

Comment 8 Todd Bailey 2008-07-03 04:42:33 UTC
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.

Comment 9 Todd Bailey 2008-07-13 15:55:16 UTC
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. 

Comment 10 Jarod Wilson 2008-07-14 17:27:57 UTC
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).

Comment 11 Todd Bailey 2008-07-14 18:55:53 UTC
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. 

Comment 12 Todd Bailey 2008-07-15 04:56:55 UTC
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. ?

Comment 13 Todd Bailey 2008-07-17 01:40:38 UTC
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.  



Comment 14 Todd Bailey 2008-07-22 00:55:54 UTC
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

Comment 15 Need Real Name 2008-07-27 12:47:59 UTC
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.


Comment 16 Need Real Name 2008-07-27 15:00:02 UTC
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

Comment 17 Todd Bailey 2008-07-30 05:01:20 UTC
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.
 



Comment 18 Todd Bailey 2008-07-30 05:03:42 UTC
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




Comment 19 Todd Bailey 2008-07-30 14:19:49 UTC
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. 


Comment 20 Jarod Wilson 2008-08-04 20:34:51 UTC
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...

Comment 21 Jarod Wilson 2008-08-04 20:36:58 UTC
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.

Comment 22 Jarod Wilson 2008-10-13 15:29:05 UTC
Going to close this out since its working now.


Note You need to log in before you can comment on or make changes to this bug.