Quantcast

irsend: fill_string: timeout

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

irsend: fill_string: timeout

Phiplex

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

 

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 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

 


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: irsend: fill_string: timeout

Alec Leamas


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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: irsend: fill_string: timeout

Phiplex
Hello Alec,

> -----Original Message-----
> From: Alec Leamas [mailto:[hidden email]]
> Sent: Friday, December 9, 2016 2:25 PM
> To: [hidden email]
> 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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: irsend: fill_string: timeout

Bengt Martensson-2
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

------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: irsend: fill_string: timeout

Phiplex
Hi Bengt, thanks for helping

> -----Original Message-----
> From: Bengt Martensson [mailto:[hidden email]]
> Sent: Saturday, December 10, 2016 9:20 AM
> To: [hidden email]
> 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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: irsend: fill_string: timeout

Bengt Martensson-2
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

------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: irsend: fill_string: timeout

Phiplex
Partly Success !!

|-----Original Message-----
|From: Bengt Martensson [mailto:[hidden email]]
|Sent: Saturday, December 10, 2016 1:20 PM
|To: [hidden email]
|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



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: irsend: fill_string: timeout

Bengt Martensson-2
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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: irsend: fill_string: timeout

Phiplex
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
|



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: irsend: fill_string: timeout

Bengt Martensson-2
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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Loading...