From: Stefan K. <sk...@gm...> - 2014-05-20 20:55:27
|
Hello List, I'm using a Raspberry Pi as IR remote with gpio controlled IR-led using lirc_rpi uname -a Linux raspberrypi 3.12.19+ #682 PREEMPT Mon May 12 23:27:36 BST 2014 armv6l GNU/Linux lircd -v lircd 0.9.0-pre1 Sending and receiving SPACE_ENC remote codes works perfectly fine. receiving RCMM codes with irw works, but sending with irsend does not. command executed: irsend SEND_ONCE KathreinRC660 KEY_OK symptoms: IR-led flashes once, than nothing happens. Following irsend runs into a timeout running lirc in debug mode: sudo lircd -n -d /dev/lirc0 lircd-0.9.0-pre1[6020]: lircd(default) ready, using /var/run/lirc/lircd lircd-0.9.0-pre1[6020]: accepted new client on /var/run/lirc/lircd lircd-0.9.0-pre1[6020]: removed client lircd-0.9.0-pre1[6020]: accepted new client on /var/run/lirc/lircd client is after approx 30 sec removed again, during this time irsend runs into the timeout problem occurs/reproduced in raspbian, openelec and archlinux There were also discussions about that problem at the mailing list in 2012 (on a ubuntu system) but without a clear solution. Is this fixed in the new version or still a bug? What should I do to get this fixed / any help? greetings stefan Used lircd.conf: begin remote name KathreinRC660 bits 16 flags RCMM|CONST_LENGTH eps 10 aeps 130 header 500 185 three 217 700 two 217 560 one 217 367 zero 210 185 ptrail 250 pre_data_bits 16 pre_data 0x2290 gap 16777215 toggle_bit 17 min_repeat 0 frequency 36000 duty_cycle 50 begin codes KEY_0 0x0000 KEY_1 0x0001 KEY_2 0x0002 KEY_3 0x0003 KEY_4 0x0004 KEY_5 0x0005 KEY_6 0x0006 KEY_7 0x0007 KEY_8 0x0008 KEY_9 0x0009 KEY_INFO 0x000F KEY_OK 0x005C KEY_STAND_BY 0x000C KEY_MUTE 0x000D KEY_CURSOR_RIGHT 0x005B KEY_CURSOR_LEFT 0x005A KEY_CURSOR_UP 0x0058 KEY_CURSOR_DOWN 0x0059 KEY_VOLUME_UP 0x0010 KEY_VOLUME_DOWN 0x0011 KEY_RED 0x006D KEY_GREEN 0x006E KEY_YELLOW 0x006F KEY_BLUE 0x0070 KEY_EPG 0x00CC KEY_EXIT 0x0055 KEY_MENU 0x0054 KEY_CHANNEL_UP 0x001E KEY_CHANNEL_DOWN 0x001F KEY_PLAY 0x0038 KEY_STOP 0x0031 KEY_RECORD 0x0037 KEY_PAUSE 0x0039 KEY_FASTFORWARD 0x0020 KEY_REWIND 0x0021 KEY_TEXT 0x003C end codes end remote |
From: Alec L. <lea...@gm...> - 2014-05-20 21:13:33
|
On 2014-05-20 22:56, Stefan Kienzl wrote: > Hello List, > > I'm using a Raspberry Pi as IR remote with gpio controlled IR-led > using lirc_rpi > > [cut > Sending and receiving SPACE_ENC remote codes works perfectly fine. > receiving RCMM codes with irw works, but sending with irsend does not. > > command executed: irsend SEND_ONCE KathreinRC660 KEY_OK > > symptoms: IR-led flashes once, than nothing happens. Following irsend > runs into a timeout > [cut] > client is after approx 30 sec removed again, during this time irsend > runs into the timeout > > problem occurs/reproduced in raspbian, openelec and archlinux > There were also discussions about that problem at the mailing list in > 2012 (on a ubuntu system) but without a clear > solution. > > Is this fixed in the new version or still a bug? It's probably not fixed, I see no references to it in the git log. > What should I do to get this fixed / any help? > > Frankly speaking: I have no idea. As a starter, a link to the 2012 discussion would perhaps be useful. But in the end this boils down to someone with with enough skills, motivation and test setup to t fix it. Lacking all of these, I'm certainly not that person. --alec |
From: Stefan K. <sk...@gm...> - 2014-05-21 07:58:22
|
Am 2014-05-20 23:13, schrieb Alec Leamas: >> >> Is this fixed in the new version or still a bug? > > It's probably not fixed, I see no references to it in the git log. Unfortunately, that is what I expected. Is there any bug reporting tool or developer that I can contact? I tried to find something on die LIRC homepage or the SF site but there is no clear reference. Is LIRC still maintained? >> What should I do to get this fixed / any help? > > Frankly speaking: I have no idea. As a starter, a link to the 2012 discussion would perhaps be useful. Here's the link, describing the exact same problem I have. Looks like this only affects lirc version >=0.9.0: http://sourceforge.net/p/lirc/mailman/message/29223881 stefan |
From: Alec L. <lea...@gm...> - 2014-05-21 08:43:47
|
On 2014-05-21 09:59, Stefan Kienzl wrote: > Is there any bug reporting tool or developer that I can contact? It's basically this list, sorry. > Here's the link, describing the exact same problem I have. Looks like this only affects lirc version >=0.9.0: > http://sourceforge.net/p/lirc/mailman/message/29223881 > Hm... The key difference between 0.8,7 and 0.9.0 in this respect is that 0.8.7 used a mceusb kernel driver built by lirc whereas 0.9.0 uses the kernel builtin mceusb driver. If we could isolate this problem to be a kernel driver bug (which I suspect) this should be reported to the kernel bugtracker. The first step would be to rebuild lirc with debug enabled, reproduce the error with maximum debug logging and post the logs. Cheers! --alec |
From: Stefan K. <sk...@gm...> - 2014-05-21 09:49:52
|
> Hm... The key difference between 0.8,7 and 0.9.0 in this respect is that 0.8.7 used a mceusb kernel driver built by lirc > whereas 0.9.0 uses the kernel builtin mceusb driver. If we could isolate this problem to be a kernel driver bug (which I > suspect) this should be reported to the kernel bugtracker. I guess that this is not directly related to this case, because I don't use the mceusb driver. Instead the lirc_rpi kernel module is used, which is based on the lirc_serial module as stated here: http://aron.ws/projects/lirc_rpi/ > The first step would be to rebuild lirc with debug enabled, reproduce the error with maximum debug logging and post the > logs. I'll give it a try. - stefan |
From: Alec L. <lea...@gm...> - 2014-05-21 10:19:54
|
On 2014-05-21 11:51, Stefan Kienzl wrote: > I guess that this is not directly related to this case, because I don't use the mceusb driver. Instead the lirc_rpi > kernel module is used, which is based on the lirc_serial module as stated here: > http://aron.ws/projects/lirc_rpi/ > Yes, of course, sorry. But this actually opens a new possibility: if you could establish a "good" state by checking out the .0.8.7 tag in the git repo and verify the bug is not there you could use git bisect to find the offending commit. At that point it should really be possible to hunt down the bug. --alec |
From: Stefan K. <sk...@gm...> - 2014-05-21 15:35:16
|
Am 2014-05-21 12:19, schrieb Alec Leamas: > On 2014-05-21 11:51, Stefan Kienzl wrote: >> I guess that this is not directly related to this case, because I don't use the mceusb driver. Instead the lirc_rpi >> kernel module is used, which is based on the lirc_serial module as stated here: >> http://aron.ws/projects/lirc_rpi/ >> > Yes, of course, sorry. But this actually opens a new possibility: if you could establish a "good" state by checking out > the .0.8.7 tag in the git repo and verify the bug is not there you could use git bisect to find the offending commit. At > that point it should really be possible to hunt down the bug. tried 0.8.7 lircd and irsend binary, (still the same lirc_rpi module) but exactly the same problem. So I compiled 0.9.0 again with debug. What I found out so far are 2 things. - there is a nearly 30 sec gap between receiving command and clearing buffer, wich correlates to the 30sec irsend timeout. May 21 17:22:33 raspberrypi lircd: accepted new client on /var/run/lirc/lircd May 21 17:22:33 raspberrypi lircd: driver supports both sending and receiving May 21 17:22:33 raspberrypi lircd: received command: "SEND_ONCE sat KEY_CHANNEL_UP" May 21 17:23:00 raspberrypi lircd: clearing transmit buffer May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 500 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 185 - if you lower the gap in the lircd.conf by about 1/100, than everything looks normal, but the remote codes are still not working, which is I think due to the wrong gap. with timeout: gap = 16777215 without timeout: gap = 167772 full debug output for one irsend: ay 21 17:22:33 raspberrypi lircd: registering local client May 21 17:22:33 raspberrypi lircd: accepted new client on /var/run/lirc/lircd May 21 17:22:33 raspberrypi lircd: driver supports both sending and receiving May 21 17:22:33 raspberrypi lircd: received command: "SEND_ONCE sat KEY_CHANNEL_UP" May 21 17:23:00 raspberrypi lircd: clearing transmit buffer May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 500 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 185 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 210 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 185 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 217 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 560 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 210 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 185 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 217 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 560 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 217 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 560 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 217 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 367 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 210 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 185 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 210 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 185 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 210 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 185 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 210 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 185 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 210 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 185 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 210 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 185 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 210 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 185 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 217 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 367 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 217 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 700 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 217 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 560 May 21 17:23:00 raspberrypi lircd: adding to transmit buffer: 250 May 21 17:23:00 raspberrypi lircd: transmit buffer ready May 21 17:23:00 raspberrypi lircd: removed client |
From: Alec L. <lea...@gm...> - 2014-05-21 16:18:23
|
On 2014-05-21 17:36, Stefan Kienzl wrote: > > - if you lower the gap in the lircd.conf by about 1/100, than everything looks normal, but the remote codes are still > not working, which is I think due to the wrong gap. > > with timeout: gap = 16777215 > without timeout: gap = 167772 > > Hm... is this some kind of overflow? Of the ~2000 config file we have, the largest gap is 1399999, less then 1/10 of that gap... Only two files have gaps >= 1000000 That would perhaps explan things, and it would not be the first one. But to find such an overflow will not be easy. I have skimmed through the code in lircd.c which does the actual job ( send_core() ), but I see nothing obvious. What I do see is that there is almost no logging... --alec |
From: Alec L. <lea...@gm...> - 2014-05-22 05:28:56
|
On 2014-05-21 17:36, Stefan Kienzl wrote: > - if you lower the gap in the lircd.conf by about 1/100, than everything looks normal, but the remote codes are still > not working, which is I think due to the wrong gap. > > with timeout: gap = 16777215 > without timeout: gap = 167772 > After a night's sleep I see this this clearer: A 16 seconds+ gap doesn't really make sense, does it? Where does this come from? If it's recorded using irrecord there was certainly some problems at that point, perhaps driver-related. --alec |
From: Stefan K. <sk...@gm...> - 2014-05-22 08:41:16
|
Am 2014-05-22 07:28, schrieb Alec Leamas: > On 2014-05-21 17:36, Stefan Kienzl wrote: >> - if you lower the gap in the lircd.conf by about 1/100, than everything looks normal, but the remote codes are still >> not working, which is I think due to the wrong gap. >> >> with timeout: gap = 16777215 >> without timeout: gap = 167772 >> > After a night's sleep I see this this clearer: A 16 seconds+ gap doesn't really make sense, does it? Where does this > come from? If it's recorded using irrecord there was certainly some problems at that point, perhaps driver-related. > I don't know very much about the IR protocol, so I can't interpret the values in a correct manner, but what you are saying sounds reasonable to me. The configuration comes directly from my linux based sattelite receiver (Kathrein UFS910) which does of course only receive IR signals but the problem only occurs when sending the codes. Receiving the codes on my Raspberry Pi works flawlessly too. stefan |
From: Alec L. <lea...@gm...> - 2014-05-22 09:37:27
|
On 2014-05-22 10:42, Stefan Kienzl wrote: > > Am 2014-05-22 07:28, schrieb Alec Leamas: >> On 2014-05-21 17:36, Stefan Kienzl wrote: >>> - if you lower the gap in the lircd.conf by about 1/100, than everything looks normal, but the remote codes are still >>> not working, which is I think due to the wrong gap. >>> >>> with timeout: gap = 16777215 >>> without timeout: gap = 167772 >>> >> After a night's sleep I see this this clearer: A 16 seconds+ gap doesn't really make sense, does it? Where does thiscome from? If it's recorded using irrecord there was certainly some problems at that point, perhaps driver-related. >> > I don't know very much about the IR protocol, so I can't interpret the values in a correct manner, but what you are > saying sounds reasonable to me. The configuration comes directly from my linux based sattelite receiver (Kathrein > UFS910) which does of course only receive IR signal What does "comes direct from" really mean in this context? Has the vendor supplied a lircd.conf file?! Or have you been using irrecord? Or what? --alec |
From: Stefan K. <sk...@gm...> - 2014-05-22 10:33:59
|
Am 2014-05-22 11:37, schrieb Alec Leamas: > On 2014-05-22 10:42, Stefan Kienzl wrote: >> >> Am 2014-05-22 07:28, schrieb Alec Leamas: >>> On 2014-05-21 17:36, Stefan Kienzl wrote: >>>> - if you lower the gap in the lircd.conf by about 1/100, than everything looks normal, but the remote codes are still >>>> not working, which is I think due to the wrong gap. >>>> >>>> with timeout: gap = 16777215 >>>> without timeout: gap = 167772 >>>> >>> After a night's sleep I see this this clearer: A 16 seconds+ gap doesn't really make sense, does it? Where does >>> thiscome from? If it's recorded using irrecord there was certainly some problems at that point, perhaps driver-related. >>> >> I don't know very much about the IR protocol, so I can't interpret the values in a correct manner, but what you are >> saying sounds reasonable to me. The configuration comes directly from my linux based sattelite receiver (Kathrein >> UFS910) which does of course only receive IR signal > What does "comes direct from" really mean in this context? Has the vendor supplied a lircd.conf file?! Or have you been > using irrecord? Or what? The satellite receiver has a serial port and network interface over which you get root console access to the OS (Linux). Therefore you are able to manage processes, browse through the file system and edit files. So I copied the lircd.conf from the sat receiver to the Raspberry Pi. So to speak, this is a vendor supplied config file which is actually used on the device. Hope that's clearer now :) Now I also tried to lower the gap on the Raspberry Pi lircd.conf to gap = 167772 to find out if the gap has any influence on receiving the signals - it hasn't. Every key is detected. All Keys where detected normally like with gap = 16777215, so perhaps this value is just wrong but has no influence on receiving but only sending signals? |
From: Stefan K. <sk...@gm...> - 2014-05-22 12:46:38
|
Am 2014-05-22 12:44, schrieb Alec Leamas: > Anyway, this config file is just plain wrong since it has an unreasonable 16 seconds+ gap. Perhaps you should try to > record your own using irrecord to see if you get something more sane? That's it!! I used the lirc supplied RCMM-32.conf as config template for irrecord and found out, that the key codes are pretty much the same as in the lircd.conf from the vendor. So i exchanged only the header information with that from RCMM-32.conf and my satellite receiver now responds to the IR signals send out by my Raspberry Pi. Here is a diff of the headers (left column vendor | right LIRC RCMM-32 template) name Kathrein | name RCMM-32 bits 16 | bits 32 flags RCMM|CONST_LENGTH flags RCMM|CONST_LENGTH eps 10 | eps 2 aeps 130 | aeps 100 header 500 185 | header 417 278 three 217 700 | three 167 778 two 217 560 | two 167 611 one 217 367 | one 167 444 zero 210 185 | zero 167 278 ptrail 250 | ptrail 167 pre_data_bits 16 | pre_data_bits 0 pre_data 0x2290 | gap 99817 gap 16777215 | repeat_bit 0 toggle_bit 17 < min_repeat 0 < frequency 36000 < duty_cycle 50 < I could have tried that much earlier. :-/ Don't now how the receiving could work in both ways with such different values in the two config files. However, problem solved! Now I can continue my Raspberry Remote project. Thanks a lot Alec for you help and input! greetings stefan |
From: Alec L. <lea...@gm...> - 2014-05-22 13:36:20
|
On 2014-05-22 14:48, Stefan Kienzl wrote: > That's it!! > I used the lirc supplied RCMM-32.conf as config template for irrecord and found out, that the key codes are pretty much > the same as in the lircd.conf from the vendor. So i exchanged only the header information with that from RCMM-32.conf > and my satellite receiver now responds to the IR signals send out by my Raspberry Pi. Glad that it works for you! Cheers! --alec |
From: Alec L. <lea...@gm...> - 2014-05-22 10:44:45
|
On 2014-05-22 12:35, Stefan Kienzl wrote: > The satellite receiver has a serial port and network interface over which you get root console access to the OS (Linux). > Therefore you are able to manage processes, browse through the file system and edit files. So I copied the lircd.conf > from the sat receiver to the Raspberry Pi. So to speak, this is a vendor supplied config file which is actually used onthe device. > Hope that's clearer now :) > Yup, now. It wasn't my first thought, so to speak. Anyway, this config file is just plain wrong since it has an unreasonable 16 seconds+ gap. Perhaps you should try to record your own using irrecord to see if you get something more sane? --alec |