Re: girs driver issues

Joe Dugandzic <[email protected]> Mon, 16 Mar 2020 10:45:46 -0700
Newsgroups gmane.comp.hardware.lirc
Message-ID <CAK9FZYwYv2k8hvThePka3Bxv4haqbaunFyoSw79fEyiyKqe6Pw@mail.gmail.com>
I appreciate the previous help. But how do I do an unsubscribe from the
group?

On Mon, Mar 16, 2020 at 9:51 AM Bengt Martensson <[email protected]>
wrote:

> On 2020-03-16 01:06, Tim Pletcher wrote:
>
>  >     Which one was incorrectly received? More importantly, did in
> solve the
>  >     problem with the Samsung signals?
>  >
>  > I had to bump up DEFAULT_RECEIVE_ENDINGTIMEOUT in the GirsLite firmware
>  > to 40 in order to not receive a truncated signal from my Samsung
>  > remote.  In testing, I found that it was important to ensure the receive
>  > window was big enough to receive a signal without being big enough to
>  > receive two valid signal worth of a remote keypress within the same
>  > receive sequence (ie within one iteration of readline in the girs.c
>  > driver).  When I get two valid receives in the same single receive
>  > window, the issue with a key repeat showing up 10 seconds later occurs.
>  >
>  > With this value at 40, everything seems to work acceptably well for
>  > routine use.
>
> I see that you are using Lirc 0.10.1 containing version 2017-03-11 of
> the Girs driver. That version lets Lircd set the ending timeout
> drvctrl(LIRC_SET_REC_TIMEOUT,...). That was removed in the version
> 2017-08-30
>
> https://sourceforge.net/p/lirc/git/ci/7f7edd7db7a0aa767e29012320eb041e1e8b8f8b/
> (which is contained in Lirc release 0.11.0-devel), and replaced by a
> driver parameter, probably since it cased more problem than it solved
> (as your experience also indicates). So I hope that you can find a value
> that makes thing to work.
>
>  > Hopefully I don't have to tune this value individually for
>  > the remotes in use with the system.  We'll see after I move this down to
>  > my home theater PC.
>
> You use IR reception on your computer (using Lirc or something else) to
> send commands to the computer. So there is really no need to decode all
> the remotes you have in use, just one really... (Sending is different of
> course, if desired).
>
>
>
>