Help with lircd/ir decoder (20.1 remote)

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Help with lircd/ir decoder (20.1 remote)

VDR User
Hi, I've found a remote (Dish 20.1) which has a good layout and size
for me. I tried and failed to create a lircd.conf using irrecord
(lircd-0.9.4). After searching I found that it uses a non-standard
protocol but that someone did manage to make a somewhat working
lircd.conf. Unfortunately that config doesn't seem quite tuned in
enough to be considered stable (at least when using various mceusb ir
receivers). I also tried using the decoders that come packaged with
newer kernels but not surprisingly none of those worked either.

My question is, is there anyone who can help fix this so it's stable?
Preferably via a dedicated decoder but even if irrecord would work,
that would be a huge help. I can supply hardware no problem if needed.
Any help is more than greatly appreciated!

Thanks!

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Bengt Martensson-2
On 08/10/16 18:44, VDR User wrote:
>
 > Hi, I've found a remote (Dish 20.1) which has a good layout and size
 > for me. I tried and failed to create a lircd.conf using irrecord
 > (lircd-0.9.4). After searching I found that it uses a non-standard
 > protocol but that someone did manage to make a somewhat working
 > lircd.conf.

With the description you give, we can only guess what signals the remote
shoots. There is a protocol called Dish Network,
http://www.hifi-remote.com/wiki/index.php?title=DecodeIR#Dish_Network.
This has a modulation frequency of 57.6 kHz, which means that it is
pretty much (hardware-) incompatible with "standard" receivers, like the
MCEUSB you mention.

Lirc (and the "standard" receivers) is not very capable when it comes to
identifying an unknown IR signal.

What does the "somewhat working" configuration look like? Let us know
how we can help you.

Greetz,

Bengt

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

VDR User
Hi Bengt, thanks for your reply!

I can confirm that the remote does work with at least 3 different
mceusb devices (HP IR, generic Topseed  eHome, Topseed eHome that came
with AVS Gear GP-IR02BK), which I wouldn't think is possible if it was
hardware-incompatible. The behavior is a bit quirky. A couple
examples; it takes 2 keypresses to get a single working keypress.
repeating button presses stop after 2-3 repeats even though no max is
set.

How big of a task is it to write a decoder specific to this protocol
similar to the ones the come with the kernel (like the JVC one for
example)? Is it possible to make irrecord `smarter` so it will work or
work better with non-standard remotes such as this one? Ultimately if
I could get it to work correctly and stable whether by custom decoder,
altered lircd.conf, patched irrecord, etc. I'd be happy for sure!

====================
begin remote
  name  20.1_IR
  bits           16
  flags SPACE_ENC|NO_HEAD_REP
  eps            30
  aeps          100

  header        525  6045
  one           440  1645
  zero          440  2780
  ptrail        450
  gap          6115
  min_repeat      6
  toggle_bit_mask 0x0
  frequency    56000

      begin codes
          up                       0x6800
          down                     0x7800
          left                     0x7000
          right                    0x6000
          select                   0x4000
          menu                     0x2C00
          input                    0xBC00
          pageup                   0x3C10
          pagedown                 0x1C10
          guide                    0x5000
          recall                   0x6C00
          info                     0x0000
          search                   0xB400
          viewlivetv               0x5800
          cancel                   0x4800
          red                      0x4C00
          green                    0xD400
          yellow                   0x8800
          blue                     0x8C00
          skip-                    0xD810
          skip+                    0xDC10
          dvr                      0xE410
          rewind                   0xC410
          pause                    0x8000
          fastforward              0xC810
          stop                     0x8400
          record                   0x7C00
          play                     0x0C10
          1                        0x1000
          2                        0x1400
          3                        0x1800
          4                        0x2000
          5                        0x2400
          6                        0x2800
          7                        0x3000
          8                        0x3400
          9                        0x3800
          0                        0x4400
          asterix                  0x9400
          pound                    0x9800
          swap                     0xF410
          pip                      0xE810
          position                 0xEC10
          dish                     0xD010
      end codes
end remote
====================


On Wed, Aug 10, 2016 at 10:22 AM, Bengt Martensson
<[hidden email]> wrote:

> On 08/10/16 18:44, VDR User wrote:
>>
>  > Hi, I've found a remote (Dish 20.1) which has a good layout and size
>  > for me. I tried and failed to create a lircd.conf using irrecord
>  > (lircd-0.9.4). After searching I found that it uses a non-standard
>  > protocol but that someone did manage to make a somewhat working
>  > lircd.conf.
>
> With the description you give, we can only guess what signals the remote
> shoots. There is a protocol called Dish Network,
> http://www.hifi-remote.com/wiki/index.php?title=DecodeIR#Dish_Network.
> This has a modulation frequency of 57.6 kHz, which means that it is
> pretty much (hardware-) incompatible with "standard" receivers, like the
> MCEUSB you mention.
>
> Lirc (and the "standard" receivers) is not very capable when it comes to
> identifying an unknown IR signal.
>
> What does the "somewhat working" configuration look like? Let us know
> how we can help you.
>
> Greetz,
>
> Bengt
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Bengt Martensson-2
On 08/10/16 20:06, VDR User wrote:
> Hi Bengt, thanks for your reply!
>
> I can confirm that the remote does work with at least 3 different
> mceusb devices (HP IR, generic Topseed  eHome, Topseed eHome that came
> with AVS Gear GP-IR02BK), which I wouldn't think is possible if it was
> hardware-incompatible. The behavior is a bit quirky. A couple
> examples; it takes 2 keypresses to get a single working keypress.
> repeating button presses stop after 2-3 repeats even though no max is
> set.

The file looks quite reasonable; IrScrutinizer decodes it as
Dish_Network (surprise!), D=0 or 1 (different between different
signals), S=0, F=26 for the first signal, "up". Also note that it says
"frequency 56000" (I wounder how "they" came up with it though). So
likely your receivers is sort-of working; not very reliably. Recall: a
demodulating IR receiver consists of a band pass filter.

So you should probably get a receiver based on a 56kHz sensor, like
TSOP34856. Using a 56kHz receiver Lirc should work with your
configuration file. (For example, my little thing:
http://harctoolbox.org/arduino_nano.html with a 56kHz sensor instead of
the 38kHz one) The protocol is not that complicated.

Greetz,

Bengt


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

VDR User
> The file looks quite reasonable; IrScrutinizer decodes it as
> Dish_Network (surprise!), D=0 or 1 (different between different
> signals), S=0, F=26 for the first signal, "up". Also note that it says
> "frequency 56000" (I wounder how "they" came up with it though). So
> likely your receivers is sort-of working; not very reliably. Recall: a
> demodulating IR receiver consists of a band pass filter.
>
> So you should probably get a receiver based on a 56kHz sensor, like
> TSOP34856. Using a 56kHz receiver Lirc should work with your
> configuration file. (For example, my little thing:
> http://harctoolbox.org/arduino_nano.html with a 56kHz sensor instead of
> the 38kHz one) The protocol is not that complicated.

I had a look at your link and I'd like to try it. For the price, if it
doesn't work at least it will give me a reason to do some soldering!
:) A couple questions however.. Is the following correct?: I don't
need to transmit so the IR LEDs and resistor can be left out. I simply
exchange the TSOP34438 for the TSOP34856 as a drop-in replacement.
Lastly, will the firmware you've linked to work or would it need to be
modified in any way (possibly because 38kHz vs 56kHz?)?

Thanks!

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Bengt Martensson-2
On 08/10/16 22:26, VDR User wrote:

>> The file looks quite reasonable; IrScrutinizer decodes it as
>> Dish_Network (surprise!), D=0 or 1 (different between different
>> signals), S=0, F=26 for the first signal, "up". Also note that it says
>> "frequency 56000" (I wounder how "they" came up with it though). So
>> likely your receivers is sort-of working; not very reliably. Recall: a
>> demodulating IR receiver consists of a band pass filter.
>>
>> So you should probably get a receiver based on a 56kHz sensor, like
>> TSOP34856. Using a 56kHz receiver Lirc should work with your
>> configuration file. (For example, my little thing:
>> http://harctoolbox.org/arduino_nano.html with a 56kHz sensor instead of
>> the 38kHz one) The protocol is not that complicated.
>
> I had a look at your link and I'd like to try it. For the price, if it
> doesn't work at least it will give me a reason to do some soldering!
> :) A couple questions however.. Is the following correct?: I don't
> need to transmit so the IR LEDs and resistor can be left out.

In principle yes; however it is really useful to have around, for
example for direct testing codes, and does not cost much. A similar
statement goes for the non-demodulating sensor.

 > I simply
> exchange the TSOP34438 for the TSOP34856 as a drop-in replacement.

Almost, they happen  to have pin 2 and 3 flipped; that is power and GND.
There are really pin compatible ones, like TSOP34456, see
http://www.vishay.com/docs/82489/tsop322.pdf .

> Lastly, will the firmware you've linked to work or would it need to be
> modified in any way (possibly because 38kHz vs 56kHz?)?

If using pin compatible yes, otherwise you may have to modify some of
the hardware configuration files, like girs_pins_nano.h (IRSENSOR_1_GND
and IRSENSOR_1_VSS). The latest version is on Github:
https://github.com/bengtmartensson/AGirs For Lirc, use the girs driver
in the latest Lirc sources.

Good Luck!

Bengt

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

VDR User
Bengt, do you happen to have an example lirc_options.conf for this
project? The parts came in just now and I'd like to get it going. If I
understand, all I need to do is compile current lirc (I use lirc git
here), dump the "GirsLite" firmware onto the assembled Arduino, use a
correct lirc_options.conf, then load lircd as I have when using
mceusb. Are there any modules I have to modprobe in place of mceusb?

Thanks for your help!

On Thu, Aug 11, 2016 at 12:12 AM, Bengt Martensson
<[hidden email]> wrote:

> On 08/10/16 22:26, VDR User wrote:
>>>
>>> The file looks quite reasonable; IrScrutinizer decodes it as
>>> Dish_Network (surprise!), D=0 or 1 (different between different
>>> signals), S=0, F=26 for the first signal, "up". Also note that it says
>>> "frequency 56000" (I wounder how "they" came up with it though). So
>>> likely your receivers is sort-of working; not very reliably. Recall: a
>>> demodulating IR receiver consists of a band pass filter.
>>>
>>> So you should probably get a receiver based on a 56kHz sensor, like
>>> TSOP34856. Using a 56kHz receiver Lirc should work with your
>>> configuration file. (For example, my little thing:
>>> http://harctoolbox.org/arduino_nano.html with a 56kHz sensor instead of
>>> the 38kHz one) The protocol is not that complicated.
>>
>>
>> I had a look at your link and I'd like to try it. For the price, if it
>> doesn't work at least it will give me a reason to do some soldering!
>> :) A couple questions however.. Is the following correct?: I don't
>> need to transmit so the IR LEDs and resistor can be left out.
>
>
> In principle yes; however it is really useful to have around, for example
> for direct testing codes, and does not cost much. A similar statement goes
> for the non-demodulating sensor.
>
>> I simply
>>
>> exchange the TSOP34438 for the TSOP34856 as a drop-in replacement.
>
>
> Almost, they happen  to have pin 2 and 3 flipped; that is power and GND.
> There are really pin compatible ones, like TSOP34456, see
> http://www.vishay.com/docs/82489/tsop322.pdf .
>
>> Lastly, will the firmware you've linked to work or would it need to be
>> modified in any way (possibly because 38kHz vs 56kHz?)?
>
>
> If using pin compatible yes, otherwise you may have to modify some of the
> hardware configuration files, like girs_pins_nano.h (IRSENSOR_1_GND and
> IRSENSOR_1_VSS). The latest version is on Github:
> https://github.com/bengtmartensson/AGirs For Lirc, use the girs driver in
> the latest Lirc sources.
>
> Good Luck!
>
> Bengt

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Bengt Martensson-2
On 08/16/16 18:28, VDR User wrote:
> Bengt, do you happen to have an example lirc_options.conf for this
> project?

Use driver = girs and, if you do not have any competing devices, device
= /dev/ttyUSB0.


> The parts came in just now and I'd like to get it going. If I
> understand, all I need to do is compile current lirc (I use lirc git
> here), dump the "GirsLite" firmware onto the assembled Arduino, use a
> correct lirc_options.conf,

I strongly recommend you first try it with IrScrutinizer, it is much
"user friendlier" than Lirc. The upcoming version 1.3 (and the
development version on Github) have an option "use receive for capture"
with which you can try the demodulating sensor. And, IrScrutinizer is
much more powerful than Lirc/irrecord for identifying IR signals.

> then load lircd as I have when using
> mceusb. Are there any modules I have to modprobe in place of mceusb?

No modules, just the girs driver.


------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

VDR User
I managed to get the firmware (GirsLite-2015-12-01-nanoflasher)
loaded. Then managed to get IrScrutinizer working
(http://harctoolbox.org/downloads/IrScrutinizer-bin.zip), and when I
tried Capturing HW->Arduino->Test, it did see the protocol as Dish. I
went ahead and tried to use it with lirc but that didn't seem to work.
I adjusted my lirc_options.conf accordingly so it now looks like:
==========
[lircd]
nodaemon        = False
driver          = girs
device          = /dev/ttyUSB0
output          = /var/run/lirc/lircd
pidfile         = /var/run/lirc/lircd.pid
plugindir       = /etc/lirc
permission      = 666
allow-simulate  = No
repeat-max      = 600
#listen         = [address:]port
#connect        = host[:port]
#debug          = 6
#uinput         = ...
#release        = ...
logfile         = /logs/lircd.log

[lircmd]
uinput          = False
nodaemon        = False
==========

My lircd log was:
==========
Aug 16 13:30:36.806145 pc lircd: Info: lircd:  Opening log, level: Info
Aug 16 13:30:36.806479 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
Aug 16 13:30:36.806510 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
Aug 16 13:30:36.806533 pc lircd: Info: lircd:  Opening log, level: Info
Aug 16 13:30:36.807205 pc lircd: Info: Using remote: 20.1_IR.
Aug 16 13:30:36.808121 pc lircd: Notice: lircd(girs) ready, using
/var/run/lirc/lircd
Aug 16 13:30:39.156296 pc lircd: Notice: accepted new client on
/var/run/lirc/lircd
Aug 16 13:30:39.156348 pc lircd: Warning: Failed to initialize hardware
==========

The line with `accepted new client` I'm pretty sure is VDR connecting
to lircd. I have no clue why it says `Warning: Failed to initialize
hardware` after that.

I get the same behavior, or lack thereof with and without
ir_lirc_codec,lirc_dec,rc_core modules loaded. When I press buttons on
the remote, nothing happens with the leds. The red led stays on
constantly however.

Any ideas what went wrong?

Thanks for all the help!
Derek


On Tue, Aug 16, 2016 at 10:01 AM, Bengt Martensson
<[hidden email]> wrote:

> On 08/16/16 18:28, VDR User wrote:
>> Bengt, do you happen to have an example lirc_options.conf for this
>> project?
>
> Use driver = girs and, if you do not have any competing devices, device
> = /dev/ttyUSB0.
>
>
>> The parts came in just now and I'd like to get it going. If I
>> understand, all I need to do is compile current lirc (I use lirc git
>> here), dump the "GirsLite" firmware onto the assembled Arduino, use a
>> correct lirc_options.conf,
>
> I strongly recommend you first try it with IrScrutinizer, it is much
> "user friendlier" than Lirc. The upcoming version 1.3 (and the
> development version on Github) have an option "use receive for capture"
> with which you can try the demodulating sensor. And, IrScrutinizer is
> much more powerful than Lirc/irrecord for identifying IR signals.
>
>> then load lircd as I have when using
>> mceusb. Are there any modules I have to modprobe in place of mceusb?
>
> No modules, just the girs driver.
>
>
> ------------------------------------------------------------------------------

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Alec Leamas
On 16/08/16 22:38, VDR User wrote:

> My lircd log was:
> ==========
> Aug 16 13:30:36.806145 pc lircd: Info: lircd:  Opening log, level: Info
> Aug 16 13:30:36.806479 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
> Aug 16 13:30:36.806510 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
> Aug 16 13:30:36.806533 pc lircd: Info: lircd:  Opening log, level: Info
> Aug 16 13:30:36.807205 pc lircd: Info: Using remote: 20.1_IR.
> Aug 16 13:30:36.808121 pc lircd: Notice: lircd(girs) ready, using
> /var/run/lirc/lircd
> Aug 16 13:30:39.156296 pc lircd: Notice: accepted new client on
> /var/run/lirc/lircd
> Aug 16 13:30:39.156348 pc lircd: Warning: Failed to initialize hardware
> ==========
>
> The line with `accepted new client` I'm pretty sure is VDR connecting
> to lircd. I have no clue why it says `Warning: Failed to initialize
> hardware` after that.
>
What's happening here is that lircd-starts, but waits until the client
connects. Once connected it tries to make a "init" on the driver, but
this fails.

Three things:
     - You should set the loglevel value to at least 'debug' while
hunting bugs.
     - Have you checked the permissions of the /dev/ttyUSB0 device?
     - As Bengt said, irscrutinizer might make sense here if not these
simple steps fixes lirc.

And, please don't top-post. The thread becomes unreadable.


Cheers!

-.-alec

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Bengt Martensson-2
In reply to this post by VDR User
On 08/16/16 22:38, VDR User wrote:
> I managed to get the firmware (GirsLite-2015-12-01-nanoflasher)
> loaded.

If possible, can you get the current (on Github) working?


> Then managed to get IrScrutinizer working
> (http://harctoolbox.org/downloads/IrScrutinizer-bin.zip), and when I
> tried Capturing HW->Arduino->Test, it did see the protocol as Dish. I
> went ahead and tried to use it with lirc but that didn't seem to work.
> I adjusted my lirc_options.conf accordingly so it now looks like:
> ==========
> [lircd]
> nodaemon        = False
> driver          = girs
> device          = /dev/ttyUSB0
> output          = /var/run/lirc/lircd
> pidfile         = /var/run/lirc/lircd.pid
> plugindir       = /etc/lirc
^^^^
This is wrong, remove.

> permission      = 666
> allow-simulate  = No
> repeat-max      = 600
> #listen         = [address:]port
> #connect        = host[:port]
> #debug          = 6
> #uinput         = ...
> #release        = ...
> logfile         = /logs/lircd.log

Add loglevel = trace1 for now.
Also, define listen (without arguments); then IrScrutinizer will be able
to send commands to lircd (Sending HW -> Lirc; host localhost, port 8765).


------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

VDR User
In reply to this post by Alec Leamas
>> ==========
>> Aug 16 13:30:36.806145 pc lircd: Info: lircd:  Opening log, level: Info
>> Aug 16 13:30:36.806479 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
>> Aug 16 13:30:36.806510 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
>> Aug 16 13:30:36.806533 pc lircd: Info: lircd:  Opening log, level: Info
>> Aug 16 13:30:36.807205 pc lircd: Info: Using remote: 20.1_IR.
>> Aug 16 13:30:36.808121 pc lircd: Notice: lircd(girs) ready, using
>> /var/run/lirc/lircd
>> Aug 16 13:30:39.156296 pc lircd: Notice: accepted new client on
>> /var/run/lirc/lircd
>> Aug 16 13:30:39.156348 pc lircd: Warning: Failed to initialize hardware
>> ==========
>>
>> The line with `accepted new client` I'm pretty sure is VDR connecting
>> to lircd. I have no clue why it says `Warning: Failed to initialize
>> hardware` after that.
>>
> What's happening here is that lircd-starts, but waits until the client
> connects. Once connected it tries to make a "init" on the driver, but
> this fails.

Does the "Notice: lircd(girs) ready, using /var/run/lirc/lircd" just
mean that lircd see the driver is available but hasn't actually
init'ed it yet? Or, if the `Failed to initialize` occurs because the
driver is already initialized, shouldn't lircd take that into
consideration before throwing a warning?

> Three things:
>      - You should set the loglevel value to at least 'debug' while
> hunting bugs.
>      - Have you checked the permissions of the /dev/ttyUSB0 device?

I haven't but I do realize that my user isn't a member of the
`dialout` or `lock` groups. I did everything up to checking in
IrScrutinizer on a test box, then moved the device over to the box
where it will actually be used. I forgot to do a couple things though;
add the user to the `dialout` group, recompile the kernel with the
usbserial and ch341 drivers, ..  I got ahead of myself a little bit
but I'm also basically fumbling through this so cut me some slack. :)
After adding my user to the `dialout` group and recompiling my kernel
with usbserial/ch341 drivers, my lircd log now looks like this:

Aug 16 17:43:44.899513 pc lircd: Info: lircd:  Opening log, level: Info
Aug 16 17:43:44.899863 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
Aug 16 17:43:44.899891 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
Aug 16 17:43:44.899914 pc lircd: Info: lircd:  Opening log, level: Info
Aug 16 17:43:44.900419 pc lircd: Info: Using remote: 20.1_IR.
Aug 16 17:43:44.901222 pc lircd: Notice: lircd(girs) ready, using
/var/run/lirc/lircd
Aug 16 17:44:00.330656 pc lircd: Notice: accepted new client on
/var/run/lirc/lircd
Aug 16 17:44:03.992159 pc lircd: Info: girs: transmit module found
Aug 16 17:44:03.992214 pc lircd: Info: girs: receive module found
Aug 16 17:44:03.992237 pc lircd: Info: girs: LED module found
Aug 16 17:44:03.992249 pc lircd: Info: Version "GirsLite 2015-12-01"

Is it safe to assume I'm at least one step closer to this working?

>      - As Bengt said, irscrutinizer might make sense here if not these
> simple steps fixes lirc.
>
> And, please don't top-post. The thread becomes unreadable.

Will do, sorry about that!

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

VDR User
In reply to this post by Bengt Martensson-2
>> I managed to get the firmware (GirsLite-2015-12-01-nanoflasher)
>> loaded.
>
> If possible, can you get the current (on Github) working?

I gave this a try but it was unsuccessful. I couldn't find a howto and
the documentation is informative but not user-friendly. For example
one of the listed dependencies is something called "Infrared4Arduino".
I cloned the git and read the README.md but there were no clear
compile instructions. I performed a `make` which resulted in a
`libInfrared.a` being created. Don't know what I'm supposed to do with
that and there's no `make install` available, etc..  I ran into
similar problems with AGirs having a lack of clear compile
instructions. It seems like the documentation was written for people
who are familiar with Arduino and not those like me who are completely
new to all of this. I did manage to install arduino-core, which
resolved a missing "Arduino.h" but it didn't. Additionally I also
couldn't figure out how to resolve missing "IrSignal.h" and
"InfraredTypes.h" files. Unfortunately I have no clue how to proceed
so I'm not able to compile & install a newer firmware.

>> Then managed to get IrScrutinizer working
>> (http://harctoolbox.org/downloads/IrScrutinizer-bin.zip), and when I
>> tried Capturing HW->Arduino->Test, it did see the protocol as Dish. I
>> went ahead and tried to use it with lirc but that didn't seem to work.
>> I adjusted my lirc_options.conf accordingly so it now looks like:
>> ==========
>> [lircd]
>> nodaemon        = False
>> driver          = girs
>> device          = /dev/ttyUSB0
>> output          = /var/run/lirc/lircd
>> pidfile         = /var/run/lirc/lircd.pid
>> plugindir       = /etc/lirc
>
> ^^^^
> This is wrong, remove.

If you mean just the plugindir= line, I manually copy them there. my
default.la/default.so and girs.la/girs.so are stored there.
check-install fails to build a debian package so I just copy those
plugins manually, and lircd to /usr/local/bin. This hasn't been a
problem with mceusb so I'd think it's no problem with girs either..?

>> permission      = 666
>> allow-simulate  = No
>> repeat-max      = 600
>> #listen         = [address:]port
>> #connect        = host[:port]
>> #debug          = 6
>> #uinput         = ...
>> #release        = ...
>> logfile         = /logs/lircd.log
>
> Add loglevel = trace1 for now.
> Also, define listen (without arguments); then IrScrutinizer will be able to
> send commands to lircd (Sending HW -> Lirc; host localhost, port 8765).

There's no desktop on the box this is actually going to be used on.I
did overlook a couple things though. When I moved the device to my
main box, I forgot to add my user to the `dialout` group, and also
forgot to compile usbserial and ch341 drivers from the kernel source.
I've since fixed those problems and now at least lircd seems to get
farther, or at least correctly detect the device. The remote still
doesn't work unfortunately. Given the new info, do you still recommend
changing loglevel= and listen= in my lirc_options.conf?

Also, am I supposed to load the ir_lirc_codec, lirc_dev, and rc_core
modules when using girs? They were necessary with mceusb but neither
usbserial nor ch341 loads them and I'm not sure if they should be.

Thanks for all your help!
Derek

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Bengt Martensson-2
On 08/17/16 03:13, VDR User wrote:
>>> I managed to get the firmware (GirsLite-2015-12-01-nanoflasher)
>>> loaded.
>>
>> If possible, can you get the current (on Github) working?
>
> I gave this a try but it was unsuccessful. I couldn't find a howto and
> the documentation is informative but not user-friendly.

Ok, we can leave that out, at least for the moment. Just a few comments:

* Infrared4Arduino can (as opposed to AGirs) be installed by the Arduino
Library manager.

* You compile for the Arduino using the Arduio IDE, "make" is for a
testing version on the PC.

>>> plugindir       = /etc/lirc
>>
>> ^^^^
>> This is wrong, remove.
>
> If you mean just the plugindir= line, I manually copy them there. my
> default.la/default.so and girs.la/girs.so are stored there.

...

> check-install fails to build a debian package so I just copy those
> plugins manually, and lircd to /usr/local/bin. This hasn't been a
> problem with mceusb so I'd think it's no problem with girs either..?

Please use "make install".

>> Also, define listen (without arguments); then IrScrutinizer will be able to
>> send commands to lircd (Sending HW -> Lirc; host localhost, port 8765).
>
> There's no desktop on the box this is actually going to be used on.

Ok, then you can run IrScrutinizer on your test machine and replace
"localhost" above with the IP-address/name of the Lirc host. Replaces
irsend.

> Also, am I supposed to load the ir_lirc_codec, lirc_dev, and rc_core
> modules when using girs?

No, they are not needed.

> ug 16 17:43:44.899513 pc lircd: Info: lircd:  Opening log, level: Info
> Aug 16 17:43:44.899863 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
> Aug 16 17:43:44.899891 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
> Aug 16 17:43:44.899914 pc lircd: Info: lircd:  Opening log, level: Info
> Aug 16 17:43:44.900419 pc lircd: Info: Using remote: 20.1_IR.
> Aug 16 17:43:44.901222 pc lircd: Notice: lircd(girs) ready, using
> /var/run/lirc/lircd
> Aug 16 17:44:00.330656 pc lircd: Notice: accepted new client on
> /var/run/lirc/lircd
> Aug 16 17:44:03.992159 pc lircd: Info: girs: transmit module found
> Aug 16 17:44:03.992214 pc lircd: Info: girs: receive module found
> Aug 16 17:44:03.992237 pc lircd: Info: girs: LED module found
> Aug 16 17:44:03.992249 pc lircd: Info: Version "GirsLite 2015-12-01"

That is getting real close.

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Alec Leamas


On 17/08/16 08:27, Bengt Martensson wrote:
> On 08/17/16 03:13, VDR User wrote:
> plugindir       = /etc/lirc
>>> ^^^^
>>> This is wrong, remove.
>> If you mean just the plugindir= line, I manually copy them there. my
>> default.la/default.so and girs.la/girs.so are stored there.
>
Although this will work, it violates basic principles and is probably a
bad habit. /etc is for architecture-neutral config files, not compiled
code which belongs under /lib (or, in this case really /usr/local/lib
since the code isn't packaged).

BTW, the .la files are not required and could be dropped, only the .so
files are needed.

Cheers!

--alec

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Bengt Martensson-2
In reply to this post by VDR User
On 08/17/16 03:13, VDR User wrote:
>>> I managed to get the firmware (GirsLite-2015-12-01-nanoflasher)
>>> loaded.
>>
>> If possible, can you get the current (on Github) working?
>
> I gave this a try but it was unsuccessful. I couldn't find a howto and
> the documentation is informative but not user-friendly. For example
> one of the listed dependencies is something called "Infrared4Arduino".

I have put a new hex file and "nanoflasher.sh" at Github,
https://github.com/bengtmartensson/AGirs/releases/tag/Version-0.2.0

I also (marginally) improved the README.md.

Contributed HOWTOs etc are welcome.

On the side: I have a problem with the Arduino community's attitude: In
order to implement their homemade concept of "beginner friedly", they
create at least as many new problem as they solve. Library treatment,
the Arduino preprocessor, copying everything to /tmp, etc., etc.


------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Bengt Martensson-2
In reply to this post by Alec Leamas
On 08/17/16 09:13, Alec Leamas wrote:

>
>
> On 17/08/16 08:27, Bengt Martensson wrote:
>> On 08/17/16 03:13, VDR User wrote:
>> plugindir       = /etc/lirc
>>>> ^^^^
>>>> This is wrong, remove.
>>> If you mean just the plugindir= line, I manually copy them there. my
>>> default.la/default.so and girs.la/girs.so are stored there.
>>
> Although this will work, it violates basic principles and is probably a
> bad habit. /etc is for architecture-neutral config files, not compiled
> code which belongs under /lib (or, in this case really /usr/local/lib
> since the code isn't packaged).

Slightly OT: I think we should push "Use 'make install', or we will not
offer you any support".  There is a number of (in general completely
unnecessary) problems creating by just shoving files around.


------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

VDR User
In reply to this post by Bengt Martensson-2
> I have put a new hex file and "nanoflasher.sh" at Github,
> https://github.com/bengtmartensson/AGirs/releases/tag/Version-0.2.0

I successfully updated the firmware using your new files, thank you!

> Contributed HOWTOs etc are welcome.

I've been taking notes. Once I have this working, I intend to wipe
everything and redo it all using my notes and creating a howto which
I'll gladly share.

> On the side: I have a problem with the Arduino community's attitude: In
> order to implement their homemade concept of "beginner friedly", they
> create at least as many new problem as they solve. Library treatment,
> the Arduino preprocessor, copying everything to /tmp, etc., etc.

Generally, a lot of times people write documentation under the
assumption the user has some pre-existing knowledge of the processed,
software used, etc. Unfortunately for new users this can quickly turn
into a mess/egg hunt. You start (trying to) follow instructions ->
oops! I need this first so you start hunting that down and -> oops!
this has to be done before that. I've known many people who just give
up because it becomes too much of a hassle. Instructions/howtos
written for a total beginner are always best serve their purpose. I
think of it as having to hold someones hand in the beginning, or after
they've already made a mess. ;)

Ok, so now that I have the firmware updated, this is where I'm at... I
adjusted my lirc_options.conf accordingly:
[lircd]
nodaemon        = False
driver          = girs
device          = /dev/ttyUSB0
output          = /var/run/lirc/lircd
pidfile         = /var/run/lirc/lircd.pid
plugindir       = /etc/lirc
permission      = 666
allow-simulate  = No
repeat-max      = 600
listen          =
logfile         = /logs/lircd.log
loglevel        = trace1

[lircmd]
uinput          = False
nodaemon        = False

Then I load the arduino driver and start lircd. (/ldvb/* is a
networked dir where I keep all commonly used dvb-related files. That
way I only need to maintain 1 file/location and it's easy for backup
purposes. Much more preferable to having everything unnecessarily
stored on every box.):
$ sudo modprobe ch341
$ lircd -O /ldvb/lirc.config/lirc_options_girs.conf
/ldvb/lirc.config/lircd.20.1_IR.mceusb.conf

My lircd log shows:
Aug 17 09:08:28.386489 pc lircd: Info: lircd:  Opening log, level: Info
Aug 17 09:08:28.386890 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
Aug 17 09:08:28.386920 pc lircd: Info: girs_open: Initial device: /dev/ttyUSB0
Aug 17 09:08:28.386944 pc lircd: Info: lircd:  Opening log, level: Info
Aug 17 09:08:28.387790 pc lircd: Info: Using remote: 20.1_IR.
Aug 17 09:08:28.390544 pc lircd: Notice: lircd(girs) ready, using
/var/run/lirc/lircd

So far so good right? Next, I load IrScrutinizer on the test box and
go to SendingHW->lirc. I put the lircd box ip in, the "version" box
seems to be properly populated with "0.9.5-devel", which is what lirc
git version I'm using. The remote populates as "20.1_IR", which is
correct. Then I check my lircd log again:

Aug 17 09:09:01.707744 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:05.369826 pc lircd: Info: girs: transmit module found
Aug 17 09:09:05.369867 pc lircd: Info: girs: receive module found
Aug 17 09:09:05.369878 pc lircd: Info: girs: LED module found
Aug 17 09:09:05.369888 pc lircd: Info: Version "GirsLite 2016-06-01"
Aug 17 09:09:05.570998 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:05.571039 pc lircd: Info: removed client
Aug 17 09:09:05.572584 pc lircd: Info: removed client
Aug 17 09:09:05.675925 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:05.877269 pc lircd: Info: removed client
Aug 17 09:09:05.979904 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:06.181200 pc lircd: Info: removed client
Aug 17 09:09:06.283882 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:06.497502 pc lircd: Info: removed client
Aug 17 09:09:06.600857 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:06.802247 pc lircd: Info: removed client
Aug 17 09:09:06.904838 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:07.112388 pc lircd: Info: removed client
Aug 17 09:09:07.214814 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:07.416223 pc lircd: Info: removed client
Aug 17 09:09:07.518792 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:07.723371 pc lircd: Info: removed client
Aug 17 09:09:07.825770 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:08.027086 pc lircd: Info: removed client
Aug 17 09:09:08.129747 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:08.331058 pc lircd: Info: removed client
Aug 17 09:09:08.433725 pc lircd: Notice: accepted new client from 192.168.0.12
Aug 17 09:09:08.637210 pc lircd: Info: removed client

At this point I don't know what I'm supposed to do. Is it typical for
IrScrutinizer to connect/disconnect so many times without me having
done anything? Hopefully so far so good to this point...?

Thanks,
Derek

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Alec Leamas
In reply to this post by Bengt Martensson-2


On 17/08/16 12:00, Bengt Martensson wrote:
> Slightly OT: I think we should push "Use 'make install', or we will not
> offer you any support".  There is a number of (in general completely
> unnecessary) problems creating by just shoving files around.
>
>

Yep, or the workflow described when building the debian package (which
is built on top of that),

--alec

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Help with lircd/ir decoder (20.1 remote)

Bengt Martensson-2
In reply to this post by VDR User
On 08/17/16 18:14, VDR User wrote:

>
> Aug 17 09:09:01.707744 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:05.369826 pc lircd: Info: girs: transmit module found
> Aug 17 09:09:05.369867 pc lircd: Info: girs: receive module found
> Aug 17 09:09:05.369878 pc lircd: Info: girs: LED module found
> Aug 17 09:09:05.369888 pc lircd: Info: Version "GirsLite 2016-06-01"
> Aug 17 09:09:05.570998 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:05.571039 pc lircd: Info: removed client
> Aug 17 09:09:05.572584 pc lircd: Info: removed client
> Aug 17 09:09:05.675925 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:05.877269 pc lircd: Info: removed client
> Aug 17 09:09:05.979904 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:06.181200 pc lircd: Info: removed client
> Aug 17 09:09:06.283882 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:06.497502 pc lircd: Info: removed client
> Aug 17 09:09:06.600857 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:06.802247 pc lircd: Info: removed client
> Aug 17 09:09:06.904838 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:07.112388 pc lircd: Info: removed client
> Aug 17 09:09:07.214814 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:07.416223 pc lircd: Info: removed client
> Aug 17 09:09:07.518792 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:07.723371 pc lircd: Info: removed client
> Aug 17 09:09:07.825770 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:08.027086 pc lircd: Info: removed client
> Aug 17 09:09:08.129747 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:08.331058 pc lircd: Info: removed client
> Aug 17 09:09:08.433725 pc lircd: Notice: accepted new client from 192.168.0.12
> Aug 17 09:09:08.637210 pc lircd: Info: removed client
>
> At this point I don't know what I'm supposed to do.

Sending a command? For example with "Send" in IrScrutinizer (or with
irsend). Things should be working now, just try your client.


 > Is it typical for
> IrScrutinizer to connect/disconnect so many times without me having
> done anything?

Quoting U2: "She moves in mysterious ways"... Probably a Lircd quirk,
don't worry. (Which is not to say that it is perfect...)

You may possibly find the --immediate-init option to Lircd useful
(implemented by me just recently).

Now I am returning to writing that HOWTO on heart transplantation ;-).

------------------------------------------------------------------------------
12