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