lirc-list

Re: irsend other remote codes using mceusb - totally stumped!

[Steve <rat...@gm...>]

Hi,

This is kodibuntu - which going to their web page now appears to be
unsupported and out of date - yay!

it's a debian jessie/sid based release and I guess it is pretty old now,
it's been working for ages so I've not touched it!

Kernel is:

~# uname -a
Linux louge 3.13.0-54-generic #91-Ubuntu SMP Tue May 26 19:15:08 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux

I don't really want to upgrade / re-install the whole thing, but if you
think this is just likely to be a bug due to an old version of lirc then I
can try.

I was hoping I'd just missed some obvious piece of configuration that was
needed to send the Samsung commands via the mceusb adapter :(

On 30 December 2016 at 21:37, Alec Leamas <lea...@gm...> wrote:

>
>
> On 30/12/16 22:24, Steve wrote:
> > Hi All,
> >
> > I'm trying to use my mceusb via Lirc with IRSend to send signals to the
> > other devices in my lounge, which I know must work but it won't for me
> > and after spending all evening googling and trying different things out
> .samsung"
> >
> > 2) I then try and send a volume command using:
> >
> > irsend send_once samsung KEY_VOLUMEUP
> >
> > And I get the error message:
> >
> > irsend: command failed: send_once samsung KEY_VOLUMEUP
> > irsend: transmission failed
> >
> > In syslog I see:
> >
> > Dec 30 20:45:17 louge lircd-0.9.0[680]: accepted new client on
>
> Hi!
>
> Sorry to say, but 0.9.0 is a really old version and to be frank I havn't
> a faintest idea what this could be. What's your platform/OS?
>
> I'm not saying that an update would just resolve whatever problems are
> involved here. But  it would make it so much easier to try to understand
> what's going on.
>
> Cheers!
>
> --alec
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>

Re: irsend other remote codes using mceusb - totally stumped!

[Alec L. <lea...@gm...>]

On 30/12/16 22:24, Steve wrote:
> Hi All,
>
> I'm trying to use my mceusb via Lirc with IRSend to send signals to the
> other devices in my lounge, which I know must work but it won't for me
> and after spending all evening googling and trying different things out
.samsung"
>
> 2) I then try and send a volume command using:
>
> irsend send_once samsung KEY_VOLUMEUP
>
> And I get the error message:
>
> irsend: command failed: send_once samsung KEY_VOLUMEUP
> irsend: transmission failed
>
> In syslog I see:
>
> Dec 30 20:45:17 louge lircd-0.9.0[680]: accepted new client on

Hi!

Sorry to say, but 0.9.0 is a really old version and to be frank I havn't 
a faintest idea what this could be. What's your platform/OS?

I'm not saying that an update would just resolve whatever problems are 
involved here. But  it would make it so much easier to try to understand 
what's going on.

Cheers!

--alec

irsend other remote codes using mceusb - totally stumped!

[Steve <rat...@gm...>]

Hi All,

I'm trying to use my mceusb via Lirc with IRSend to send signals to the
other devices in my lounge, which I know must work but it won't for me and
after spending all evening googling and trying different things out I
thought the best thing to do is ask here!

What works so far:

1) Remote works, I'm using Kodi spin of Ubuntu and I can use the MCE remote
via the mceusb box to control Kodi just fine
2) IRSend for the mceusb commands works fine, I can run irsend on the
command line and the transmitter LEDs flash - e.g. by running:

"irsend send_once mceusb KEY_VOLUMEUP"

So I know the hardware is properly detected and works fine for this limited
set of use cases.

What doesn't work:

1) I cannot use the mceusb to send commands for my TV, Amp etc.

What have I tried?

1) I've added an additional "include" line into the /etc/lirc/lircd.conf
file to include the configuration information needed for my Samsung telly:

include "/usr/share/lirc/remotes/samsung/lircd.conf.samsung"

2) I then try and send a volume command using:

irsend send_once samsung KEY_VOLUMEUP

And I get the error message:

irsend: command failed: send_once samsung KEY_VOLUMEUP
irsend: transmission failed

In syslog I see:

Dec 30 20:45:17 louge lircd-0.9.0[680]: accepted new client on
/run/lirc/lircd
Dec 30 20:45:17 louge lircd-0.9.0[680]: invalid send buffer
Dec 30 20:45:17 louge lircd-0.9.0[680]: this remote configuration cannot be
used to transmit
Dec 30 20:45:17 louge lircd-0.9.0[680]: error processing command: send_once
samsung KEY_VOLUMEUP
Dec 30 20:45:17 louge lircd-0.9.0[680]: transmission failed
Dec 30 20:45:17 louge lircd-0.9.0[680]: removed client

I assume it must be possible to send other remote commands out via the
mceusb sender, but I'm clearly missing some step as to how I make this
whole thing work. Do I need to do something to ensure that the mceusb is
used for sending the samsung commands? If so which configuration option do
I need to use?

Any pointers greatly appreciated.

Thank you.

Stephen.

Re: Mode2 continuously displaying codes when no button is pressed on the remote

[Bengt M. <bu...@be...>]

On 12/30/16 20:15, Rikk Sullenberger wrote:
> I am trying to set up lirc on a Raspberry pi B+ the IR sensor is on pins :
>
> Power 3.3v (pin 1)
> Data GPIO 18 (Pin 12
> Ground (pin 6)
>
> This is what I get when I run mode2 --raw --device /dev/lirc0
> It just continues to scroll garbage......

This is a hardware problem (and this list a software list ;-)).

Things to try is solder a capacitator directly between power and gnd on 
the sensor (e.g. 100nF), a pullup (pulldown?) resistor on the data pin, 
a low-pass filter between the data pin and the GPIO. These are often 
shown as example circuits in the data sheets.

Watch out for disturbance lights too, like sunlight.

Greetz,

Bengt

Mode2 continuously displaying codes when no button is pressed on the remote

[Rikk S. <rik...@gm...>]

I am trying to set up lirc on a Raspberry pi B+ the IR sensor is on pins :

Power 3.3v (pin 1)
Data GPIO 18 (Pin 12
Ground (pin 6)

This is what I get when I run mode2 --raw --device /dev/lirc0
It just continues to scroll garbage......

pulse 211
space 2677
pulse 451
space 7337
pulse 200
space 6388
pulse 320
space 10349
pulse 199
space 360
pulse 213
space 4958
pulse 288
space 7254
pulse 207
space 120288
pulse 245
space 4825
pulse 222
space 3076
pulse 189
space 4534
pulse 446
space 8061
pulse 202
space 173995
pulse 185
space 104
pulse 523
space 2602
pulse 223
space 4866
pulse 201
space 3171
pulse 591
space 5131
pulse 221
space 10476
pulse 204
space 6046
pulse 200
space 10838
pulse 239
space 121186
pulse 209
space 3801
pulse 216
space 12518
pulse 205
space 2998
pulse 483
space 5159
pulse 192
space 2920
pulse 197
^C

Re: irsend: fill_string: timeout

[Bengt M. <bu...@be...>]

On 12/12/16 13:34, Phiplex wrote:
> Bengt, case closed!

Ok. There are still some open questions, but my personal goal is rather 
to replace Lirc than to support or improve it :-). (see 
www.harctoolbox.org and https://github.com/bengtmartensson)

> | > Is it possible for you to explain the difference and what's going on
> |here?
> |
> |What I did was to import your lircd.conf in IrScrutinizer (the codes are
> |Sony15, device 48, command number 20, 18, and 19 respectively). Then I
> |exported it as Lirc Raw. This still contained only one copy of each
> |command, so I manually edited it: adding  2*(22200 (gap) + code).
> |
>
> OK, I understand. I have now done the same thing for all remote codes for my
> Sony AMP.
> And it works great to SEND_ONCE with these raw codes times 3, so I don't
> have a problem anymore.
>
> But I don't understand why it's not working using the original LIRC codes
> INcluding the "min_repeat 3".
> Shouldn't it be the same thing using the original code with "min_repeat 3"
> and your raw code manually repeated three times?

Yes, I think it should. But the lircd code for repeating is somewhat ... 
peculiar...


...
>
> I have not done anything of what you propose above, so I still get a
> "AIEEEE" sometimes - below is such a case:
>
> Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run: Sending: SEND_ONCE
> AMP KEY_STANDBY
> Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run, state: 0, input:
> "BEGIN"
> Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run, state: 1, input:
> "SEND_ONCE AMP KEY_STANDBY"
> Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run, state: 2, input:
> "SUCCESS"
> Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run, state: 3, input:
> "END"
> Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run: data:END, status:0
> Dec 12 11:42:06 HomeZAP kernel: [208536.427667] lirc_rpi: AIEEEE: 1 1
> 584e7efe 584e7eec 78de2 33165
>
>
> Do you understand why? (Not important, because I notice no problem, more
> than this message.)

I was hoping you would analyze it ;-). The source reads


                 } else if (deltv > 15) {
                    data = PULSE_MASK; /* really long time */
                         if (!(signal^sense)) {
                                 /* sanity check */
                                 printk(KERN_DEBUG LIRC_DRIVER_NAME
                                        ": AIEEEE: %d %d %lx %lx %lx %lx\n",
                                        signal, sense, tv.tv_sec, 
lasttv.tv_sec,
                                        tv.tv_usec, lasttv.tv_usec);
                                 /*
                                  * detecting pulse while this
                                  * MUST be a space!
                                  */
                                 sense = sense ? 0 : 1;
                         }
                 } else {


Greetz,

Bengt

RE: irsend: fill_string: timeout

[Phiplex <Ph...@te...>]

Bengt, case closed!

| > Is it possible for you to explain the difference and what's going on
|here?
|
|What I did was to import your lircd.conf in IrScrutinizer (the codes are
|Sony15, device 48, command number 20, 18, and 19 respectively). Then I
|exported it as Lirc Raw. This still contained only one copy of each
|command, so I manually edited it: adding  2*(22200 (gap) + code).
|

OK, I understand. I have now done the same thing for all remote codes for my
Sony AMP.
And it works great to SEND_ONCE with these raw codes times 3, so I don't
have a problem anymore.
 
But I don't understand why it's not working using the original LIRC codes
INcluding the "min_repeat 3".
Shouldn't it be the same thing using the original code with "min_repeat 3"
and your raw code manually repeated three times?

I can also tell you that it does work using the original LIRC codes
EXcluding the "min_repeat 3" if I use SEND_START, wait around 600 ms, and
then SEND_STOP. But I guess that's the same as sending a single raw code
several times as in your codes, isn't it?    

So maybe there still is a problem somewhere in LIRC, but my issue is solved
using your work-around.


|You may (at least to test) try another sending device, Alec's file plugin
is the
|simplest one... Another thing to try is to (for test) decrease "frequency"
|in lircd.conf. Still another thing to try is to use IrScutinizer (version
|1.3!) on the RPi addressing /dev/lirc0, sending e.g. Sony15, D = 48, F =
|19 multiple times (note Sending hw -> Count) and see if you can provoke
|
|[581752.856821] lirc_rpi: AIEEEE: 0 0 584ad0a5 584acf5d 601a5 d893b
|
|(BTW, possibly we should try to understand it...)
|

I have not done anything of what you propose above, so I still get a
"AIEEEE" sometimes - below is such a case:

Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run: Sending: SEND_ONCE
AMP KEY_STANDBY
Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run, state: 0, input:
"BEGIN"
Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run, state: 1, input:
"SEND_ONCE AMP KEY_STANDBY"
Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run, state: 2, input:
"SUCCESS"
Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run, state: 3, input:
"END"
Dec 12 11:42:06 HomeZAP zird[10498]: lirc_command_run: data:END, status:0
Dec 12 11:42:06 HomeZAP kernel: [208536.427667] lirc_rpi: AIEEEE: 1 1
584e7efe 584e7eec 78de2 33165


Do you understand why? (Not important, because I notice no problem, more
than this message.) 

Regards /Phiplex

|Greetz,
|
|Bengt
|

Re: Compile fails

[Bengt M. <bu...@be...>]

On 12/11/16 10:30, Dirk Vornheder wrote:
>
> make uninstall
>
> before new install helps ...
>
> Regards,
>
> Dirk
>
>
>> On 12/01/16 20:10, Dirk Vornheder wrote:
>>> Hi !
>>>
>>>
>>> Compile latest version of lirc fails:
>>>
>> ...
>>> Byte-compiling python modules...
>>> config.pymvc_control.pymvc_view.pyTraceback (most recent call last):
>>>    File "<string>", line 16, in <module>
>>>    File "/usr/lib64/python3.4/py_compile.py", line 115, in compile
>>>      raise FileExistsError(msg.format(cfile))
>>> FileExistsError:
>>> /usr/lib/python3.4/site-packages/lirc/__pycache__/mvc_view.cpython-34.pyc
>>> is a symlink and will be changed into a regular file if import writes a
>>> byte-compiled file to it
>>> Makefile:852: recipe for target 'install-pkgpythonPYTHON' failed
>>> make[4]: *** [install-pkgpythonPYTHON] Error 1


Please open a ticket for this at sourceforge: 
https://sourceforge.net/p/lirc/tickets/

Greetz,

Bengt

Re: irsend: fill_string: timeout

[Bengt M. <bu...@be...>]

On 12/10/16 20:30, Phiplex wrote:
 > Partly Success !!
 >
...
 >
 > |Also try replacing the file with
 > |
 > |
 > |# IrScrutinizer parametric export
 > |#
 > |# Creating tool: IrScrutinizer version 1.3.1dev # Creating user: bengt #
 > |Creating date: Sat Dec 10 13:05:30 CET 2016 # Encoding: WINDOWS-1252 # #
 > |Manufacturer:
 > |# Model:
 > |# Displayname:
 > |# Remotename:
 > |#
 > |begin remote
 > |    name    unnamed
 > |    flags    RAW_CODES
 > |    eps    30
 > |    aeps    100
 > |    frequency    40000
 > |    gap    22200
 > |    begin raw_codes
 > |        name KEY_MUTE
 > |            2400 600 600 600 600 600 1200 600
 > |            600 600 1200 600 600 600 600 600
 > |            600 600 600 600 600 600 600 600
 > |            1200 600 1200 600 600 600 600
 > |                         22200 2400 600 600 600 600 600 1200 600
 > |            600 600 1200 600 600 600 600 600
 > |            600 600 600 600 600 600 600 600
 > |            1200 600 1200 600 600 600 600
 > |                         22200 2400 600 600 600 600 600 1200 600
 > |            600 600 1200 600 600 600 600 600
 > |            600 600 600 600 600 600 600 600
 > |            1200 600 1200 600 600 600 600
...
 > |    end raw_codes
 > |end remote
 > |
 >
 > When I tried the IrScrutinizer version above it also gives no 
"fill_string:
 > timeout" messages and now also the ir signal is recognize.
 > Is it possible for you to explain the difference and what's going on 
here?

What I did was to import your lircd.conf in IrScrutinizer (the codes are 
Sony15, device 48, command number 20, 18, and 19 respectively). Then I 
exported it as Lirc Raw. This still contained only one copy of each 
command, so I manually edited it: adding  2*(22200 (gap) + code).

 > And is this the only way to go using raw_codes?

No, as it does not work, as you say. Likely it is some kind of timing 
problem. The experiment has shown that is not a problem caused by 
"repeats", rather the length.

I have many times the last years "preached" that it is not 
technologically sound to use a Linux system to generate a 40kHz PWM in 
software. You may (at least to test) try another sending device, Alec's 
file plugin is the simplest one... Another thing to try is to (for test) 
decrease "frequency" in lircd.conf. Still another thing to try is to use 
IrScutinizer (version 1.3!) on the RPi addressing /dev/lirc0, sending 
e.g. Sony15, D = 48, F = 19 multiple times (note Sending hw -> Count) 
and see if you can provoke

[581752.856821] lirc_rpi: AIEEEE: 0 0 584ad0a5 584acf5d 601a5 d893b

(BTW, possibly we should try to understand it...)

Greetz,

Bengt

Re: Compile fails

[Dirk V. <dir...@ya...>]

make uninstall

before new install helps ...

Regards,

Dirk


> On 12/01/16 20:10, Dirk Vornheder wrote:
>> Hi !
>>
>>
>> Compile latest version of lirc fails:
>>
> ...
>> Byte-compiling python modules...
>> config.pymvc_control.pymvc_view.pyTraceback (most recent call last):
>>    File "<string>", line 16, in <module>
>>    File "/usr/lib64/python3.4/py_compile.py", line 115, in compile
>>      raise FileExistsError(msg.format(cfile))
>> FileExistsError:
>> /usr/lib/python3.4/site-packages/lirc/__pycache__/mvc_view.cpython-34.pyc
>> is a symlink and will be changed into a regular file if import writes a
>> byte-compiled file to it
>> Makefile:852: recipe for target 'install-pkgpythonPYTHON' failed
>> make[4]: *** [install-pkgpythonPYTHON] Error 1
>> make[4]: Leaving directory '/backup/privat/kernel/lirc/tools'
>> Makefile:1018: recipe for target 'install-am' failed
>> make[3]: *** [install-am] Error 2
>> make[3]: Leaving directory '/backup/privat/kernel/lirc/tools'
>> Makefile:1012: recipe for target 'install' failed
>> make[2]: *** [install] Error 2
>> make[2]: Leaving directory '/backup/privat/kernel/lirc/tools'
>> Makefile:660: recipe for target 'install-recursive' failed
>> make[1]: *** [install-recursive] Error 1
>> make[1]: Leaving directory '/backup/privat/kernel/lirc'
>> Makefile:958: recipe for target 'install' failed
>
> Please make a bug report at https://sourceforge.net/p/lirc/tickets/. I
> have had a similar problem since some time by make install; however not
> exactly the same error messages:
>
> /usr/bin/sed -i '/class="footer"/,/p>/d'
> /usr/local/share/doc/lirc/plugindocs/page.xsl
> /usr/bin/python3 ./make_rel_symlink.py \
>      /usr/local/var/lib/lirc/plugins
> /usr/local/share/doc/lirc/plugindocs/var
> Traceback (most recent call last):
>    File "./make_rel_symlink.py", line 44, in <module>
>      os.symlink( link_path, target)
> FileExistsError: [Errno 17] File exists:
> '../../../../var/lib/lirc/plugins' -> 'var'
> Makefile:1246: recipe for target 'install-data-hook' failed
> make[4]: *** [install-data-hook] Error 1
> make[4]: Leaving directory '/home/bengt/lirc/master/doc'
> Makefile:1158: recipe for target 'install-data-am' failed
> make[3]: *** [install-data-am] Error 2
> make[3]: Leaving directory '/home/bengt/lirc/master/doc'
> Makefile:1107: recipe for target 'install-am' failed
> make[2]: *** [install-am] Error 2
> make[2]: Leaving directory '/home/bengt/lirc/master/doc'
> Makefile:671: recipe for target 'install-recursive' failed
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory '/home/bengt/lirc/master'
> Makefile:976: recipe for target 'install' failed
> make: *** [install] Error 2
>
> IIRC, you can fix it by manually cleaning out the already installed
> stuff -- that you will overwrite anyhow.
>
> Alec, I think this is your area of competence?
>
> Greetz,
>
> Bengt
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>

RE: irsend: fill_string: timeout

[Phiplex <Ph...@te...>]

Partly Success !!

|-----Original Message-----
|From: Bengt Martensson [mailto:bu...@be...]
|Sent: Saturday, December 10, 2016 1:20 PM
|To: lir...@li...
|Subject: Re: irsend: fill_string: timeout
|
|On 12/10/16 12:40, Phiplex wrote:
|> Hi Bengt, thanks for helping
|
|> Well, I have previously been using lirc (and the installed lirc_rpi)
|> receiving and sending ir commands for some time now with no problem
|> using my own lirc client c-program and the lirc_client API.
|> This new problem/behavior occurred when I tried sending some new ir
|> commands to a new device (a Sony STR-DE495 amplifier) using a part of
|> the remote definition for a RM-U306A remote found here:
|> http://lirc.sourceforge.net/remotes/sony/RM-U306A
|>
|> Me describing the problem using irsend is just to eliminate my own
|> c-program and any possible self-inflicted errors ;) When using irsend
|> here to show the problem/behavior the /etc/lirc/lirc.conf only
|> includes the following:
|
|Hmm, you should have said that previously ;-).

I did - in my first post, but Alec removed that part ;-)


|>
|> begin remote
|>   name  AMP_VOL
|>   bits            6
|>   flags SPACE_ENC|CONST_LENGTH
|>   eps            30
|>   aeps          100
|>
|>   header       2461   524
|>   one          1265   516
|>   zero          665   516
|>   ptrail        666
|>   post_data_bits  8
|>   post_data      0x6
|>   gap          45043
|>   min_repeat      3
|
|Try removing that last line. It may case the amp not to recognize the
|signal, but don't care for the moment.

Bengt, that helped. The message "fill_string: timeout" do not occur anymore.

But as you guessed - the amp does not recognize the ir signal.


|Also try replacing the file with
|
|
|# IrScrutinizer parametric export
|#
|# Creating tool: IrScrutinizer version 1.3.1dev # Creating user: bengt #
|Creating date: Sat Dec 10 13:05:30 CET 2016 # Encoding: WINDOWS-1252 # #
|Manufacturer:
|# Model:
|# Displayname:
|# Remotename:
|#
|begin remote
|	name	unnamed
|	flags	RAW_CODES
|	eps	30
|	aeps	100
|	frequency	40000
|	gap	22200
|	begin raw_codes
|		name KEY_MUTE
|			2400 600 600 600 600 600 1200 600
|			600 600 1200 600 600 600 600 600
|			600 600 600 600 600 600 600 600
|			1200 600 1200 600 600 600 600
|                         22200 2400 600 600 600 600 600 1200 600
|			600 600 1200 600 600 600 600 600
|			600 600 600 600 600 600 600 600
|			1200 600 1200 600 600 600 600
|                         22200 2400 600 600 600 600 600 1200 600
|			600 600 1200 600 600 600 600 600
|			600 600 600 600 600 600 600 600
|			1200 600 1200 600 600 600 600
|		name KEY_VOLUMEUP
|			2400 600 600 600 1200 600 600 600
|			600 600 1200 600 600 600 600 600
|			600 600 600 600 600 600 600 600
|			1200 600 1200 600 600 600 600
|                         22200 2400 600 600 600 1200 600 600 600
|			600 600 1200 600 600 600 600 600
|			600 600 600 600 600 600 600 600
|			1200 600 1200 600 600 600 600
|                         22200 2400 600 600 600 1200 600 600 600
|			600 600 1200 600 600 600 600 600
|			600 600 600 600 600 600 600 600
|			1200 600 1200 600 600 600 600
|		name KEY_VOLUMEDOWN
|			2400 600 1200 600 1200 600 600 600
|			600 600 1200 600 600 600 600 600
|			600 600 600 600 600 600 600 600
|			1200 600 1200 600 600 600 600
|                         22200 2400 600 1200 600 1200 600 600 600
|			600 600 1200 600 600 600 600 600
|			600 600 600 600 600 600 600 600
|			1200 600 1200 600 600 600 600
|	                22200 2400 600 1200 600 1200 600 600 600
|			600 600 1200 600 600 600 600 600
|			600 600 600 600 600 600 600 600
|			1200 600 1200 600 600 600 600
|	end raw_codes
|end remote
|

When I tried the IrScrutinizer version above it also gives no "fill_string:
timeout" messages and now also the ir signal is recognize.
Is it possible for you to explain the difference and what's going on here? 

And is this the only way to go using raw_codes? - Than all other remote
codes in http://lirc.sourceforge.net/remotes/sony/RM-U306A also has to be
converted. 

Or is there something else that can be done?

Thanks for all help so far. //Phiplex

Re: irsend: fill_string: timeout

[Bengt M. <bu...@be...>]

On 12/10/16 12:40, Phiplex wrote:
> Hi Bengt, thanks for helping

> Well, I have previously been using lirc (and the installed lirc_rpi)
> receiving and sending ir commands for some time now with no problem using my
> own lirc client c-program and the lirc_client API.
> This new problem/behavior occurred when I tried sending some new ir commands
> to a new device (a Sony STR-DE495 amplifier) using a part of the remote
> definition for a RM-U306A remote found here:
> http://lirc.sourceforge.net/remotes/sony/RM-U306A
>
> Me describing the problem using irsend is just to eliminate my own c-program
> and any possible self-inflicted errors ;)
> When using irsend here to show the problem/behavior the /etc/lirc/lirc.conf
> only includes the following:

Hmm, you should have said that previously ;-).


>
> begin remote
>   name  AMP_VOL
>   bits            6
>   flags SPACE_ENC|CONST_LENGTH
>   eps            30
>   aeps          100
>
>   header       2461   524
>   one          1265   516
>   zero          665   516
>   ptrail        666
>   post_data_bits  8
>   post_data      0x6
>   gap          45043
>   min_repeat      3

Try removing that last line. It may case the amp not to recognize the 
signal, but don't care for the moment.

Also try replacing the file with


# IrScrutinizer parametric export
#
# Creating tool: IrScrutinizer version 1.3.1dev
# Creating user: bengt
# Creating date: Sat Dec 10 13:05:30 CET 2016
# Encoding: WINDOWS-1252
#
# Manufacturer:
# Model:
# Displayname:
# Remotename:
#
begin remote
	name	unnamed
	flags	RAW_CODES
	eps	30
	aeps	100
	frequency	40000
	gap	22200
	begin raw_codes
		name KEY_MUTE
			2400 600 600 600 600 600 1200 600
			600 600 1200 600 600 600 600 600
			600 600 600 600 600 600 600 600
			1200 600 1200 600 600 600 600
                         22200 2400 600 600 600 600 600 1200 600
			600 600 1200 600 600 600 600 600
			600 600 600 600 600 600 600 600
			1200 600 1200 600 600 600 600
                         22200 2400 600 600 600 600 600 1200 600
			600 600 1200 600 600 600 600 600
			600 600 600 600 600 600 600 600
			1200 600 1200 600 600 600 600
		name KEY_VOLUMEUP
			2400 600 600 600 1200 600 600 600
			600 600 1200 600 600 600 600 600
			600 600 600 600 600 600 600 600
			1200 600 1200 600 600 600 600
                         22200 2400 600 600 600 1200 600 600 600
			600 600 1200 600 600 600 600 600
			600 600 600 600 600 600 600 600
			1200 600 1200 600 600 600 600
                         22200 2400 600 600 600 1200 600 600 600
			600 600 1200 600 600 600 600 600
			600 600 600 600 600 600 600 600
			1200 600 1200 600 600 600 600
		name KEY_VOLUMEDOWN
			2400 600 1200 600 1200 600 600 600
			600 600 1200 600 600 600 600 600
			600 600 600 600 600 600 600 600
			1200 600 1200 600 600 600 600
                         22200 2400 600 1200 600 1200 600 600 600
			600 600 1200 600 600 600 600 600
			600 600 600 600 600 600 600 600
			1200 600 1200 600 600 600 600
	                22200 2400 600 1200 600 1200 600 600 600
			600 600 1200 600 600 600 600 600
			600 600 600 600 600 600 600 600
			1200 600 1200 600 600 600 600
	end raw_codes
end remote

RE: irsend: fill_string: timeout

[Phiplex <Ph...@te...>]

Hi Bengt, thanks for helping

> -----Original Message-----
> From: Bengt Martensson [mailto:bu...@be...]
> Sent: Saturday, December 10, 2016 9:20 AM
> To: lir...@li...
> Subject: Re: irsend: fill_string: timeout
> 
> On 12/10/16 02:03, Phiplex wrote:
> ...
> >
> > Using dmesg nothing new appears when using irsend.
> > But there are some older messages as follows:
> >
> > [581752.856821] lirc_rpi: AIEEEE: 0 0 584ad0a5 584acf5d 601a5 d893b
> > [590050.519853] lirc_rpi: AIEEEE: 1 1 584af10e 584af0fe bd795 39d4d
> > [590104.290566] lirc_rpi: AIEEEE: 0 0 584af144 584af116 850d9 f04a8
> >
> > And after a reboot - dmesg have the following messages about lirc:
> > [    6.088590] lirc_dev: IR Remote Control driver registered, major 244
> > [    6.115650] lirc_rpi: module is from the staging directory, the
quality
> > is unknown, you have been warned.
> >
> > [    7.130456] lirc_rpi: auto-detected active low receiver on GPIO pin
18
> > [    7.130940] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered
at
> > minor = 0
> > [    7.130962] lirc_rpi: driver registered!
> 
> It appears as if your lirc_rpi is not working correctly. lircd cannot then
send,
> which makes the problem with irsend a secondary problem.

Well, I have previously been using lirc (and the installed lirc_rpi)
receiving and sending ir commands for some time now with no problem using my
own lirc client c-program and the lirc_client API.
This new problem/behavior occurred when I tried sending some new ir commands
to a new device (a Sony STR-DE495 amplifier) using a part of the remote
definition for a RM-U306A remote found here:
http://lirc.sourceforge.net/remotes/sony/RM-U306A

Me describing the problem using irsend is just to eliminate my own c-program
and any possible self-inflicted errors ;)
When using irsend here to show the problem/behavior the /etc/lirc/lirc.conf
only includes the following:
      
begin remote
  name  AMP_VOL
  bits            6
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100
 
  header       2461   524
  one          1265   516
  zero          665   516
  ptrail        666
  post_data_bits  8
  post_data      0x6
  gap          45043
  min_repeat      3
  toggle_bit      0
  
      begin codes
          KEY_MUTE                 0x000000000000000A
          KEY_VOLUMEUP             0x0000000000000012        #  Was: VOL+
          KEY_VOLUMEDOWN           0x0000000000000032        #  Was: VOL-
      end codes
 
end remote

Otherwise my lirc.conf in production is much more complicated including
several different remotes and many more remote codes. 

> 
> Is your actual hardware configuration compatible with
lirc-rpi-overlay.dts? 

I think so - because it has been working previously using several other
remotes/remote codes.
My hardware receiving ir commands is only a TSOP34836 connected to GPIO pin
18.
My hardware sending ir commands is only a few ir leds driven via a
transistor from GPIO pin 17.    


> Is your module compatible with the kernel? Exactly where does your
lirc_rpi
> come from, version? 

If I remember correctly lirc_rpi was part the os Jessie Lite for RPi from
2016-05-27. Can this be right?
I can't remember installing anything specific for lirc_rpi.
What I have done is only configuring /boot/config.txt - today it looks like
this:

# Uncomment this to enable the lirc-rpi module
#DEFAULT--vvvvvvvv       out_pin=17,     in_pin=18
dtoverlay=lirc-rpi
#dtoverlay=lirc-rpi,gpio_out_pin=17,gpio_in_pin=18
dtparam=gpio_in_pull=down 


> What does 
> lsmod | grep lirc
> say?

~> lsmod | grep lirc
Module                  Size  Used by
lirc_rpi                8394  3
lirc_dev               10908  1 lirc_rpi
rc_core                22827  1 lirc_dev

Hope this helps, Bengt
Regards //Phiplex

> 
>  > Info: Cannot configure the rc device for /dev/lirc0
> 
> This is harmless.
> 
> Greetz,
> 
> Bengt
> 
>
----------------------------------------------------------------------------
--
> Developer Access Program for Intel Xeon Phi Processors Access to Intel
Xeon
> Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi

Re: irsend: fill_string: timeout

[Bengt M. <bu...@be...>]

On 12/10/16 02:03, Phiplex wrote:
...
>
> Using dmesg nothing new appears when using irsend.
> But there are some older messages as follows:
>
> [581752.856821] lirc_rpi: AIEEEE: 0 0 584ad0a5 584acf5d 601a5 d893b
> [590050.519853] lirc_rpi: AIEEEE: 1 1 584af10e 584af0fe bd795 39d4d
> [590104.290566] lirc_rpi: AIEEEE: 0 0 584af144 584af116 850d9 f04a8
>
> And after a reboot - dmesg have the following messages about lirc:
> [    6.088590] lirc_dev: IR Remote Control driver registered, major 244
> [    6.115650] lirc_rpi: module is from the staging directory, the quality
> is unknown, you have been warned.
>
> [    7.130456] lirc_rpi: auto-detected active low receiver on GPIO pin 18
> [    7.130940] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at
> minor = 0
> [    7.130962] lirc_rpi: driver registered!

It appears as if your lirc_rpi is not working correctly. lircd cannot 
then send, which makes the problem with irsend a secondary problem.

Is your actual hardware configuration compatible with 
lirc-rpi-overlay.dts? Is your module compatible with the kernel? Exactly 
where does your lirc_rpi come from, version? What does

lsmod | grep lirc

say?

 > Info: Cannot configure the rc device for /dev/lirc0

This is harmless.

Greetz,

Bengt

RE: irsend: fill_string: timeout

[Phiplex <Ph...@te...>]

Hello Alec,

> -----Original Message-----
> From: Alec Leamas [mailto:lea...@gm...]
> Sent: Friday, December 9, 2016 2:25 PM
> To: lir...@li...
> Subject: Re: irsend: fill_string: timeout
> 
> 
> 
> On 08/12/16 17:01, Phiplex wrote:
> > Hello, I have some strange LIRC behavior I need help to sort out.
> 
> [ta a glance, looks fine]

Thanks Alec, for deleting unnecessary info

> > First a working irsend:
> >
> >
> >
> > 1: irsend SEND_ONCE AMP_VOL KEY_VOLUMEUP
> 
> [all good]
> 
> 
> > Next irsend (with two remote codes) not working:
> >
> > 2: irsend SEND_ONCE AMP_VOL KEY_VOLUMEUP KEY_VOLUMEUP
> >
> > irsend: lirc_command_run: Sending: SEND_ONCE AMP_VOL KEY_VOLUMEUP
> > irsend: fill_string: timeout
> > irsend: fill_string: timeout
> >
> > ^C   (ctrl-C)
> >

This is the real problem I have - getting the message "fill_string: timeout"
every second for the second remote code " KEY_VOLUMEUP " in [2:] irsend   

> >
> > Next irsend (after the not working one [2] with two remote codes) also
> > not working:
> >
> > 2: irsend SEND_ONCE AMP_VOL KEY_VOLUMEUP
> >
> > busy: repeating
> >
> > Error running command: Input/output error
> 
> 
> So we have a bad state. First try would be to restart lircd.service. If
this
> helps,  the bad state is a lircd issue. If not (which I suspect) it's a
kernel driver
> issue.
>

The third not working [3:] irsend was just for info and is, I believe, a
consequence of interrupting (ctrl-C) the second one [2:] irsend, and not a
real problem.  
This behavior goes away when continuing with new irsends.

  
> So, please check if restarting lircd makes it possible to use irsend
again. Also,
> raise the loglevel in lircd.service to at least 'trace' so there is some
more
> logging. Please also look into dmesg to see if there is some visible
kernel
> driver errors when irsend fails.
> 

I have restarted lircd.service several times with no luck during the
investigation of this problem [2: irsend].
When using loglevel=9 the problem with getting the message "fill_string:
timeout" every second comes already when using only one remote code.

Dec 10 01:33:39 HomeZAP systemd[1]: Starting Flexible IR remote input/output
application support...
Dec 10 01:33:39 HomeZAP systemd[1]: Started Flexible IR remote input/output
application support.
Dec 10 01:33:39 HomeZAP lircd-0.9.4c[2309]: Info: lircd:  Opening log,
level: Info
Dec 10 01:33:39 HomeZAP lircd-0.9.4c[2309]: Info: Initial device: /dev/lirc0
Dec 10 01:33:39 HomeZAP lircd-0.9.4c[2309]: Info: Initial device: /dev/lirc0
Dec 10 01:33:39 HomeZAP lircd-0.9.4c[2309]: Trace1: lircd:  Opening log,
level: Trace1
Dec 10 01:33:39 HomeZAP lircd-0.9.4c[2309]: Warning: Running as root
Dec 10 01:33:39 HomeZAP lircd-0.9.4c[2309]: Trace: started server socket
Dec 10 01:33:39 HomeZAP lircd-0.9.4c[2309]: Trace1: parsing
'//etc/lirc/lircd.conf'
Dec 10 01:33:39 HomeZAP lircd-0.9.4c[2309]: Trace: parsing remote
Dec 10 01:33:39 HomeZAP lircd-0.9.4c[2309]: Trace1: creating first remote
Dec 10 01:33:39 HomeZAP lircd-0.9.4c[2309]: Info: Using remote: AMP_VOL.
Dec 10 01:33:40 HomeZAP lircd-0.9.4c[2309]: Trace1: flags value: 16400
Dec 10 01:33:40 HomeZAP lircd-0.9.4c[2309]: Trace1:     begin codes
Dec 10 01:33:40 HomeZAP lircd-0.9.4c[2309]: Trace1:     end codes
Dec 10 01:33:40 HomeZAP lircd-0.9.4c[2309]: Trace1: end remote
Dec 10 01:33:40 HomeZAP lircd-0.9.4c[2309]: Trace: lengths: 45043 45043
21858 22458
Dec 10 01:33:40 HomeZAP lircd-0.9.4c[2309]: Trace: config file read
Dec 10 01:33:40 HomeZAP lircd-0.9.4c[2309]: Notice: lircd(default) ready,
using /var/run/lirc/lircd
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace1: lircd:
Opening log, level: Trace1
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Warning: Running as
root
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace: started
server socket
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace1: parsing
'//etc/lirc/lircd.conf'
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace: parsing
remote
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace1: creating
first remote
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Info: Using remote:
AMP_VOL.
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace1: flags
value: 16400
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace1:     begin
codes
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace1:     end
codes
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace1: end remote
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace: lengths:
45043 45043 21858 22458
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace: config file
read
Dec 10 01:33:40 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Notice:
lircd(default) ready, using /var/run/lirc/lircd

:: irsend SEND_ONCE AMP_VOL KEY_VOLUMEUP

Dec 10 01:35:13 HomeZAP lircd-0.9.4c[2309]: Trace: registering local client
Dec 10 01:35:13 HomeZAP lircd-0.9.4c[2309]: Notice: accepted new client on
/var/run/lirc/lircd
Dec 10 01:35:13 HomeZAP lircd-0.9.4c[2309]: Info: Cannot configure the rc
device for /dev/lirc0
Dec 10 01:35:13 HomeZAP lircd-0.9.4c[2309]: Trace: driver supports both
sending and receiving
Dec 10 01:35:13 HomeZAP irsend: lirc_command_run: Sending: SEND_ONCE AMP_VOL
KEY_VOLUMEUP
Dec 10 01:35:13 HomeZAP lircd-0.9.4c[2309]: Trace: received command:
"SEND_ONCE AMP_VOL KEY_VOLUMEUP"
Dec 10 01:35:13 HomeZAP lircd-0.9.4c[2309]: Debug: Sending once, msg:
SEND_ONCE AMP_VOL KEY_VOLUMEUP#012, args: AMP_VOL KEY_VOLUMEUP, once: 1
Dec 10 01:35:13 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace: registering
local client
Dec 10 01:35:13 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Notice: accepted
new client on /var/run/lirc/lircd
Dec 10 01:35:13 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Info: Cannot
configure the rc device for /dev/lirc0
Dec 10 01:35:13 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace: driver
supports both sending and receiving
Dec 10 01:35:13 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace: received
command: "SEND_ONCE AMP_VOL KEY_VOLUMEUP"
Dec 10 01:35:13 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Debug: Sending
once, msg: SEND_ONCE AMP_VOL KEY_VOLUMEUP
Dec 10 01:35:13 HomeZAP lircd[2309]: , args: AMP_VOL KEY_VOLUMEUP, once: 1
Dec 10 01:35:13 HomeZAP lircd-0.9.4c[2309]: Trace: alarm in 10 usecs
Dec 10 01:35:13 HomeZAP lircd[2309]: lircd-0.9.4c[2309]: Trace: alarm in 10
usecs
Dec 10 01:35:14 HomeZAP irsend: fill_string: timeout
Dec 10 01:35:15 HomeZAP irsend: fill_string: timeout
Dec 10 01:35:16 HomeZAP irsend: fill_string: timeout
Dec 10 01:35:17 HomeZAP irsend: fill_string: timeout
Dec 10 01:35:18 HomeZAP irsend: fill_string: timeout 

Using dmesg nothing new appears when using irsend.
But there are some older messages as follows: 

[581752.856821] lirc_rpi: AIEEEE: 0 0 584ad0a5 584acf5d 601a5 d893b
[590050.519853] lirc_rpi: AIEEEE: 1 1 584af10e 584af0fe bd795 39d4d
[590104.290566] lirc_rpi: AIEEEE: 0 0 584af144 584af116 850d9 f04a8

And after a reboot - dmesg have the following messages about lirc:
[    6.088590] lirc_dev: IR Remote Control driver registered, major 244
[    6.115650] lirc_rpi: module is from the staging directory, the quality
is unknown, you have been warned.

[    7.130456] lirc_rpi: auto-detected active low receiver on GPIO pin 18
[    7.130940] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at
minor = 0
[    7.130962] lirc_rpi: driver registered!

Is there anything more I can try to investigate this problem further?
Regards
Phiplex

> 
> Cheers!
> 
> --alec
> 
> 
>
----------------------------------------------------------------------------
--
> Developer Access Program for Intel Xeon Phi Processors Access to Intel
Xeon
> Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi

Re: irsend: fill_string: timeout

[Alec L. <lea...@gm...>]

On 08/12/16 17:01, Phiplex wrote:
> Hello, I have some strange LIRC behavior I need help to sort out.

[ta a glance, looks fine]

> First a working irsend:
>
>
>
> 1: irsend SEND_ONCE AMP_VOL KEY_VOLUMEUP

[all good]


> Next irsend (with two remote codes) not working:
>
>
> 2: irsend SEND_ONCE AMP_VOL KEY_VOLUMEUP KEY_VOLUMEUP
>
> irsend: lirc_command_run: Sending: SEND_ONCE AMP_VOL KEY_VOLUMEUP
>
> irsend: fill_string: timeout
>
> irsend: fill_string: timeout
 >
>
> ^C   (ctrl-C)
>
>
>
>
> Next irsend (after the not working one [2] with two remote codes) also
> not working:
>
>
> 2: irsend SEND_ONCE AMP_VOL KEY_VOLUMEUP
>
>
>
> busy: repeating
>
> Error running command: Input/output error


So we have a bad state. First try would be to restart lircd.service. If 
this helps,  the bad state is a lircd issue. If not (which I suspect) 
it's a kernel driver issue.

So, please check if restarting lircd makes it possible to use irsend 
again. Also, raise the loglevel in lircd.service to at least 'trace' so 
there is some more logging. Please also look into dmesg to see if there 
is some visible kernel driver errors when irsend fails.



Cheers!

--alec

irsend: fill_string: timeout

[Phiplex <Ph...@te...>]

Hello, I have some strange LIRC behavior I need help to sort out.

 

When using IRSEND  (or my own c LIRC client program) I often (but not
always) get an (error/warning ?) message every second saying: fill_string:
timeout

More info about the strange behavior below at the end of this mail, but
first some background info: 

 

I’m using  LIRC 0.9.4c with a Raspberry Pi 1 Model B and Jessie Light.

I have a c LIRC client program using the lirc_client API waiting for
IR-commands and or similar TCP/IP-commands. 

When acting upon these IR- or IP-commands I often send (blast) other
IR-commands to some devices.

I have now found some strange behavior when trying to send (blast) some
IR-commands.

 

To investigate this more and make a clean LIRC installation I have done the
following: 

 

downloading lirc

dget -x
<http://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.9.4c-5.dsc>
http://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.9.4c-5.dsc

 

installing lirc_0.9.4c

./autogen.sh  >log_autogen.log 2>&1 

./configure --prefix=/ >>log_configure.log 2>&1 

make >>log_make.log 2>&1 

make install >>log_make_install.log 2>&1

 

configured lircd.conf = part of
<http://lirc.sourceforge.net/remotes/sony/RM-U306A> http://lirc.sourceforge.
net/remotes/sony/RM-U306A as follows:

begin remote

 

  name  AMP_VOL

  bits            6

  flags SPACE_ENC|CONST_LENGTH

  eps            30

  aeps          100

 

  header       2461   524

  one          1265   516

  zero          665   516

  ptrail        666

  post_data_bits  8

  post_data      0x6

  gap          45043

  min_repeat      3

  toggle_bit      0

  

      begin codes

          KEY_MUTE                 0x000000000000000A

          KEY_VOLUMEUP             0x0000000000000012        #  Was: VOL+

          KEY_VOLUMEDOWN           0x0000000000000032        #  Was: VOL-

      end codes

 

end remote

 

configured lirc_options.conf as follows:

[lircd]

nodaemon        = False

driver          = default

device          = /dev/lirc0

output          = /var/run/lirc/lircd

pidfile         = /var/run/lirc/lircd.pid

plugindir       = /lib/lirc/plugins

permission      = 666

allow-simulate  = No

repeat-max      = 600

release         = _UP

 

setup lircd.service as follows:

[Unit]

Documentation=man:lircd(8)

Documentation=http://lirc.org/html/configure.html

Description=Flexible IR remote input/output application support

Wants=lircd-setup.service

After=network.target lircd-setup.service

 

[Service]

Type=simple

ExecStart=/sbin/lircd --nodaemon --release

; User=lirc

; Group=lirc

 

[Install]

WantedBy=multi-user.target

 

 

checked LIRC version using:  

lircd -v

lircd 0.9.4c

 

 

(re)started LIRC with:  systemctl restart lircd

 

syslog:

Info: lircd:  Opening log, level: Info

Info: Initial device: /dev/lirc0

Info: Initial device: /dev/lirc0

Info: lircd:  Opening log, level: Info

Warning: Running as root

Info: Using remote: AMP_VOL.

Notice: lircd(default) ready, using /var/run/lirc/lircd

 

 

checked systemctl status lircd

 

● lircd.service - Flexible IR remote input/output application support

   Loaded: loaded (/lib/systemd/system/lircd.service; enabled)

   Active: active (running) since Sun 2016-12-04 12:44:12 CET; 1min 3s ago

     Docs: man:lircd(8)

           http://lirc.org/html/configure.html

Main PID: 20013 (lircd)

   CGroup: /system.slice/lircd.service

           └─20013 /sbin/lircd --nodaemon --release

 

 

THE STRANGE BEHAVIOR  FOLLOWS:

 

First a working irsend:

 

1: irsend SEND_ONCE AMP_VOL KEY_VOLUMEUP

 

syslog:

Notice: accepted new client on /var/run/lirc/lircd

Info: Cannot configure the rc device for /dev/lirc0

 

irsend: lirc_command_run: Sending: SEND_ONCE AMP_VOL KEY_VOLUMEUP

irsend: lirc_command_run, state: 0, input: "BEGIN"

irsend: lirc_command_run, state: 1, input: "SEND_ONCE AMP_VOL KEY_VOLUMEUP"

irsend: lirc_command_run, state: 2, input: "SUCCESS"

irsend: lirc_command_run, state: 3, input: "END"

irsend: lirc_command_run: data:END, status:0

 

Info: removed client

Info: removed client

 

Next irsend (with two remote codes) not working:

 

2: irsend SEND_ONCE AMP_VOL KEY_VOLUMEUP KEY_VOLUMEUP

 

syslog:

Notice: accepted new client on /var/run/lirc/lircd

Info: Cannot configure the rc device for /dev/lirc0

Notice: accepted new client on /var/run/lirc/lircd

Info: Cannot configure the rc device for /dev/lirc0

irsend: lirc_command_run: Sending: SEND_ONCE AMP_VOL KEY_VOLUMEUP

irsend: lirc_command_run, state: 0, input: "BEGIN"

irsend: lirc_command_run, state: 1, input: "SEND_ONCE AMP_VOL KEY_VOLUMEUP"

irsend: lirc_command_run, state: 2, input: "SUCCESS"

irsend: lirc_command_run, state: 3, input: "END"

irsend: lirc_command_run: data:END, status:0

 

irsend: lirc_command_run: Sending: SEND_ONCE AMP_VOL KEY_VOLUMEUP

irsend: fill_string: timeout

irsend: fill_string: timeout

irsend: fill_string: timeout

irsend: fill_string: timeout

irsend: fill_string: timeout

irsend: fill_string: timeout

 

^C   (ctrl-C)

 

 

Next irsend (after the not working one [2] with two remote codes) also not
working:

 

2: irsend SEND_ONCE AMP_VOL KEY_VOLUMEUP

 

busy: repeating

Error running command: Input/output error

 

syslog:

Notice: accepted new client on /var/run/lirc/lircd

Notice: accepted new client on /var/run/lirc/lircd

irsend: lirc_command_run: Sending: SEND_ONCE AMP_VOL KEY_VOLUMEUP

Error: error processing command: SEND_ONCE AMP_VOL KEY_VOLUMEUP

Error: error processing command: SEND_ONCE AMP_VOL KEY_VOLUMEUP

Error: busy: repeating

irsend: lirc_command_run, state: 0, input: "BEGIN"

irsend: lirc_command_run, state: 1, input: "SEND_ONCE AMP_VOL KEY_VOLUMEUP"

irsend: lirc_command_run, state: 2, input: "ERROR"

irsend: irsend: command failed: SEND_ONCE AMP_VOL KEY_VOLUMEUP

irsend: lirc_command_run, state: 3, input: "DATA"

irsend: lirc_command_run, state: 4, input: "1"

irsend: lirc_command_run, state: 5, input: "busy: repeating"

irsend: lirc_command_run, state: 6, input: "END"

irsend: lirc_command_run: status:END, status:5

Error: busy: repeating

Info: removed client

Info: removed client

Info: removed client

Info: removed client

 

Re: Running lirc on Mac OS X - pointers needed

[Bengt M. <bu...@be...>]

On 12/07/16 01:33, jhendrix1217 wrote:
> My primary goal is to use a USB-based (ideally) IR transceiver to *send* IR
> signals to other devices... basically I'd like to replace my IR remotes
> around my place with my Mac... so that I could trigger via scripts etc. A
> "smart remote" if you will.

So, what you want is something you can send commands like

send TV power_on

or

send 0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0041 0016 
0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 
0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 
0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 
0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 
0041 0016 06A4 015B 0057 0016 0E6C

(using some, here not specified, method of communicating.) For this, 
Lirc is not the only solution... I would bluntly claim that Lirc is not 
even a good solution... (shit storm coming?)

First settle for the USB transmitter you want to use, I recommend the 
Arduino Nano project from earlier post (can't beat neither price nor 
flexibility). Alternative is the IrToy, or possibly something else. See 
if you can get that to work with IrScrutinizer (which is an interactive 
program, not am IR server).

Greetz,

Bengt

Re: Compile fails

[Bengt M. <bu...@be...>]

On 12/07/16 18:34, Alec Leamas wrote:
>
>
> On 04/12/16 12:20, Bengt Martensson wrote:
>> On 12/01/16 20:10, Dirk Vornheder wrote:
>>> Hi !
>>>
>>>
>>> Compile latest version of lirc fails:
>>>
>> ...
>>> Byte-compiling python modules...
>>> config.pymvc_control.pymvc_view.pyTraceback (most recent call last):
>>>    File "<string>", line 16, in <module>
>>>    File "/usr/lib64/python3.4/py_compile.py", line 115, in compile
>>>      raise FileExistsError(msg.format(cfile))
>
> To me, it more looks like installation fails, right?

Right!

> The proper way to "fix" this would be to rm -rf he installation
> directory before proceeding. However, I somewhat hesitate to do this, it
> just "feels" better to leave this to the user. After all, installing
> into a non-empty directory IMHO is some kind of mistake.

Respectfully disagree. First, if you want to prohibit the user to 
install in a non-empty directory, the way to do it is

if [ xxxx ] ; then
    echo "Refusing to install in a nonempty dir"
    exit 1
fi

which would provide an error message on the right level of abstraction 
(as opposed to the present (python is confused of finding a symlink 
where it does not expect it)). The latter is confusing for the user (as 
the OP proves :-)).

Secondly, overwriting is ("IMHO"?) the correct way here. The GNU 
makefile guidelines 
(https://www.gnu.org/prep/standards/html_node/Standard-Targets.html) 
(the only wide spread make guidelines, AAIK) says:

	‘install’

	Compile the program and copy the executables, libraries, and so on to 
the file names where they should reside for actual use. ...

It does not say "... provided it does not exist already"- This lead to 
me to believe that overwriting is intended. I also believe that this is 
what people expect, "the principle of least surprise".

Personally, I am of the opinion that Makefile targets should be 
idempotent 
(https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning)

Greetz,

Bengt

Re: Compile fails

[Alec L. <lea...@gm...>]

On 04/12/16 12:20, Bengt Martensson wrote:
> On 12/01/16 20:10, Dirk Vornheder wrote:
>> Hi !
>>
>>
>> Compile latest version of lirc fails:
>>
> ...
>> Byte-compiling python modules...
>> config.pymvc_control.pymvc_view.pyTraceback (most recent call last):
>>    File "<string>", line 16, in <module>
>>    File "/usr/lib64/python3.4/py_compile.py", line 115, in compile
>>      raise FileExistsError(msg.format(cfile))

To me, it more looks like installation fails, right?

The proper way to "fix" this would be to rm -rf he installation 
directory before proceeding. However, I somewhat hesitate to do this, it 
just "feels" better to leave this to the user. After all, installing 
into a non-empty directory IMHO is some kind of mistake.

Or, did I miss something here?

--alec

Re: Running lirc on Mac OS X - pointers needed

[jhendrix1217 <jhe...@gm...>]

My primary goal is to use a USB-based (ideally) IR transceiver to *send* IR
signals to other devices... basically I'd like to replace my IR remotes
around my place with my Mac... so that I could trigger via scripts etc. A
"smart remote" if you will.

I actually did try compiling LIRC on OSX, although I'm not on MacOS as
mentioned in another comment. No joy.

I'm very open to other ideas, but I was just trying to use the Mini I have
setup already, since it's really the hub for everything else.

Thanks for all the info!



--
View this message in context: http://lirc.10951.n7.nabble.com/Running-lirc-on-Mac-OS-X-pointers-needed-tp59p11110.html
Sent from the LIRC mailing list archive at Nabble.com.

Lirc_rpi multip transmitter updated

[Bengt M. <bu...@be...>]

FWIW, I have just updated "my" lirc_rpi driver for the Raspberry Pi.
Now supports current Raspian including devicetree. It is found in source 
form at Github: https://github.com/bengtmartensson/lirc_rpi

It does not require Lirc; but can be accessed directly from 
IrScrutinizer version 1.3, making a more user friendly method for 
sending and receiving IR signals on the RPi.

Greetz,

Bengt

Re: Is software demodulation of 455 kHz possible on a Raspberry Pi 3

[Bengt M. <bu...@be...>]

On 12/04/16 16:18, Sof...@qu... wrote:
> Thanks, Bengt.
>>>>> The ultimate goal is to blast (not to receive).
>>>>
>>>> This should be straightforward, or is there a problem?
>>> Well, it does not work. Either the codes are wrong or the RPi is not fast enough for software pwm at 455 kHz or I made some other error. Thus, I ike to first test the codes.
>>
>> IMHO, using a general-purpose Linux system for generating software PWM
>> is like using a microscope to hammer in nails: A microscope does not
>> make a very good hammer, and you might damage the delicate instrument;
>> BUT --- you may get the work done, if the task was not too challenging :-).
>>
>> One thing to try on the RPi is hardware PWM (cf.
>> https://github.com/bengtmartensson/lirc_rpi/issues/1). But it still does
>> not take all the timings load from the main CPU.
> Agreed that software PWM is not suited for 455 kHz although the kernel module lirc_rpi accepts to blast carrier frequencies up to 500 kHz (defined in "case LIRC_SET_SEND_CARRIER" in function lirc_ioctl in file lirc_rpi.c).

IMHO, there is no reason to believe that this means that someone has 
verified that it works up to a half MHz...

> ...  For this reason, and as you now also suggest, I started to modify lirc_rpi to support hardware PWM.

Kewl! Please keep us posted.

> As I cannot confirm the .conf file of my zehnder heating remote control, I will instead use a 38 kHz DVD player and its remote control (where the .conf file is confirmed to be correct and where software PWM works) to debug my modified hardware-PWM lirc_rpi kernel module.

It is always wise to check that the standard stuff is working as 
intended before starting any "reseach". Possibly you will likely find 
IrScrutinizer useful.

> I didn't dare to connect 5 V supply voltage as the TSOP7000 datasheet states an output voltage of Vs - 0.25 V which is above the 3.3 V tolerated by the GPIO pins.

Valid point, you may consider a voltage divider.

Greetz,

Bengt

Re: Running lirc on Mac OS X - pointers needed

[Craig T. <ctr...@co...>]

> On Dec 4, 2016, at 7:46 AM, Bengt Martensson <bu...@be...> wrote:
> 
> On 12/03/16 20:16, jhendrix1217 wrote:
>> I would also love to learn more about this setup... I'm desperate to try to
>> get an IR device compatible with OSX.
> 
> What exactly do you want to achieve? Can't you just use a USB device? 
> (The coolest one is of course <biased-opinion reason="author">
> Girs (http://lirc.org/html/girs.html) with this hardware: 
> http://www.harctoolbox.org/arduino_nano.html </biased-opinion>, but 
> there are also others, like Iguana.)
> 
> Recently, some changes were made to the Lirc code to have it compile on 
> MacOS.

As Bengt said, we need to know more about what you want to accomplish.

I’ve been using an old HDHomerun Dual for several years.  Aside from its primary purpose of receiving over-the-air broadcast TV, it also includes an infra-red receiver.  LIRC receives that IR data across the network using the UDP driver.  Sounds wonky but works well in practice.  I don’t do any IR sending (aka “blasting”).

I believe someone also got the Sony VIAO IR receiver working with LIRC under OS X.  I’m not sure exactly who that was and what their use case is.

The status of other hardware is a question.  LIRC has plug-in software drivers for various pieces of hardware.  Quite a few of those drivers will _compile_ on the Mac but I haven’t seen any reports that they _work_.  I also haven’t seen any reports that they don’t work!  

On my MacBook Pro all of the following plug-in drivers built OK:

$ lirc-lsplugins
# Driver            Flags Plugin
accent              ---   /opt/local/lib/lirc/plugins/accent.so
atilibusb           ---   /opt/local/lib/lirc/plugins/atilibusb.so
atwf83              ---   /opt/local/lib/lirc/plugins/atwf83.so
audio               -as   /opt/local/lib/lirc/plugins/audio.so
awlibusb            ---   /opt/local/lib/lirc/plugins/awlibusb.so
bte                 ---   /opt/local/lib/lirc/plugins/bte.so
creative            ---   /opt/local/lib/lirc/plugins/creative.so
dfclibusb           ---   /opt/local/lib/lirc/plugins/dfclibusb.so
ea65                ---   /opt/local/lib/lirc/plugins/ea65.so
file                -as   /opt/local/lib/lirc/plugins/file.so
ftdi                -as   /opt/local/lib/lirc/plugins/ftdi.so
ftdi-exp            -as   /opt/local/lib/lirc/plugins/ftdix.so
ftdix               --s   /opt/local/lib/lirc/plugins/ftdix.so
girs                -as   /opt/local/lib/lirc/plugins/girs.so
irlink              -a-   /opt/local/lib/lirc/plugins/irlink.so
irtoy               -as   /opt/local/lib/lirc/plugins/irtoy.so
livedrive_midi      ---   /opt/local/lib/lirc/plugins/livedrive_midi.so
livedrive_seq       ---   /opt/local/lib/lirc/plugins/livedrive_seq.so
logitech            ---   /opt/local/lib/lirc/plugins/logitech.so
mouseremote         ---   /opt/local/lib/lirc/plugins/mouseremote.so
mouseremote_ps2     ---   /opt/local/lib/lirc/plugins/mouseremote.so
mp3anywhere         ---   /opt/local/lib/lirc/plugins/mp3anywhere.so
sonyir              ---   /opt/local/lib/lirc/plugins/osx_usbraw.so
pcmak               ---   /opt/local/lib/lirc/plugins/pcmak.so
pinsys              ---   /opt/local/lib/lirc/plugins/pinsys.so
pixelview           ---   /opt/local/lib/lirc/plugins/pixelview.so
silitek             ---   /opt/local/lib/lirc/plugins/silitek.so
slinke              -a-   /opt/local/lib/lirc/plugins/slinke.so
srm7500libusb       ---   /opt/local/lib/lirc/plugins/srm7500libusb.so
tira                --s   /opt/local/lib/lirc/plugins/tira.so
tira_raw            -a-   /opt/local/lib/lirc/plugins/tira.so
udp                 -a-   /opt/local/lib/lirc/plugins/udp.so
uirt2               ---   /opt/local/lib/lirc/plugins/uirt2.so
uirt2_raw           -as   /opt/local/lib/lirc/plugins/uirt2_raw.so
usb_uirt_raw        -as   /opt/local/lib/lirc/plugins/uirt2_raw.so
usbx                ---   /opt/local/lib/lirc/plugins/usbx.so
#
#
# Flags:
# E:	Empty: Plugin loaded OK, but is empty (is this a plugin?).
# F:	Fail: Plugin failed to load (unresolved references?).
# a:	Any: Driver can be used with any remote or capture device.
# s:	Send: The driver can send data.

Note that the IguanaIR is NOT in the above list.  There was a working driver (under OS X) in LIRC 0.8 days but hasn’t been updated in several years.  It has not been adapted for LIRC 0.9’s plug-in driver architecture.

HTH,

Craig

Re: Is software demodulation of 455 kHz possible on a Raspberry Pi 3

[<Sof...@qu...>]

Thanks, Bengt. 
> >>> The ultimate goal is to blast (not to receive).
> >>
> >> This should be straightforward, or is there a problem?
> > Well, it does not work. Either the codes are wrong or the RPi is not fast enough for software pwm at 455 kHz or I made some other error. Thus, I ike to first test the codes.
> 
> IMHO, using a general-purpose Linux system for generating software PWM 
> is like using a microscope to hammer in nails: A microscope does not 
> make a very good hammer, and you might damage the delicate instrument; 
> BUT --- you may get the work done, if the task was not too challenging :-).
> 
> One thing to try on the RPi is hardware PWM (cf. 
> https://github.com/bengtmartensson/lirc_rpi/issues/1). But it still does 
> not take all the timings load from the main CPU.
Agreed that software PWM is not suited for 455 kHz although the kernel module lirc_rpi accepts to blast carrier frequencies up to 500 kHz (defined in "case LIRC_SET_SEND_CARRIER" in function lirc_ioctl in file lirc_rpi.c). Also my experience when recording non-demodulated signals with my own low level code hints that 455 kHz is too fast for software PWM on the RPi. For this reason, and as you now also suggest, I started to modify lirc_rpi to support hardware PWM.

As I cannot confirm the .conf file of my zehnder heating remote control, I will instead use a 38 kHz DVD player and its remote control (where the .conf file is confirmed to be correct and where software PWM works) to debug my modified hardware-PWM lirc_rpi kernel module. Due to other commitments it might take a couple of months until I have code ready to share.
 
> >>> Nevertheless, to test, I like to confirm the derived codes by receiving them with mode2. The only demodulating IR receiver I could purchase is a no name receiver shipped from China; claimed to be an original TSOP9000 which appears to be not correct.
> >>
> >> ??? Possibly you mean TSOP7000? There is a number of offers on EBay and
> >> Aliexpress.
> > It is(or should be) a TSOP7000, apologies. The outer shape/size is slightly different than published for a real, orig i na l TSOP7000 and it fires constantly even in the absence of an IR remote signal. I assume electrical noise or visible light.
> 
> For power supply disturbances, the standard method is to connect a small 
> capacitator between power and ground immediately at the sensor;  it is 
> even in the "Application circuit" on page 1 on the data sheet. (It also 
> contains a 1k pullup on the output; might be worth a try.) Try both 3.3V 
> and 5V as supply, may make a difference.
> 
> Ambient light can be turned off, at least for testing.
I tried to put the IR receiver (without the RPi3 to even eliminate the light from the status LEDs of the RPi) into a card board box. It helped somewhat; it took in the absence of a remote control signal longer (over a minute or so) until mode2 started to report pulses and spaces. If I gave a renote control signal during this 1 minute or so, then mode2 immediately started to record pulses and spaces. Strangly, these were in general very short microsecond events; even pulse 2, space 3, pulse 2; this is IMO a very short stretch of 455 kHz carrier signal that IMo should have been demodulated by the TSOP7000. I still think, even more so now, that the part I received is not a true TSOP7000. I might anyhow try a capacitator at some point; currently I have none available.
I didn't dare to connect 5 V supply voltage as the TSOP7000 datasheet states an output voltage of Vs - 0.25 V which is above the 3.3 V tolerated by the GPIO pins.