lirc-list

Re: girs driver issues

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

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

Re: girs driver issues

[Tim P. <ple...@gm...>]

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

Thanks,
Tim

Re: Raspberry PI: Bypassing IR TX/RX

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

On 2020-03-15 14:25, Rajendra Panchal via LIRC-list wrote:
> Hello LIRC Group Members:
> 
> I am revisiting this group after a long time(2015 or so). So please 
> pardon me if this is not the right address for the request.
> 
> I am successfully using RPI3B+ to transmit IR code to a connected device 
> IR receiver, both inside an enclosure; so directly wire-able to bypass 
> the IR TX/RX HW with a simple wires from GPIO.

You want to send "IR signals" without modulation. In principle simple; 
you just put

frequency 0

in your lircd.conf. However, not all components can handle non-modulated 
signals though. (lircd only since 2015: 
https://sourceforge.net/p/lirc/tickets/132) Make sure that you are using 
a driver that can handle unmodulated signals; I do not know the status 
of the current RPi stuff. ("My" driver 
https://github.com/bengtmartensson/lirc_rpi definitely does, but is not 
compatible with current kernels.)

Greetz,

Bengt

Re: girs driver issues

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

[The answer was sent to me, not the list. I shall assume that this was 
unintended and I answer to the list.]

On 2020-03-15 14:01, Tim Pletcher wrote:
> Bengt,
> 
> Thank you for looking into this.

>     This is weird. On line 84, a sensible line is received, consisting of
>     two copies of the expected signaö. The first half is decoded (line
>     199ff), then for some reason, lircd goes in siesta for 10 seconds (why
>     is line 203 empty??) and (line 208ff) it decodes the rest -- without
>     recognizing it as repeat.
> 
> Unknown why line 203 is empty.  I went back to the original file to 
> ensure i didn't accidentially insert a new line and found was generated 
> this way by lircd.  Empty lines seem to occur periodically (e.g. line 
> 319, 474....)
> 
>     Try changing (in GirsLiteConfig.h) DEFAULT_RECEIVE_ENDINGTIMEOUT t0 30
>     and undefine PARAMETERS and report back.
> 
> I disabled parameters & led modules and set receive_endingtimeout to 
> 30.  With this setting, irw / lircd no longer correctly interpret 
> incoming remote keys.

Which one was incorrectly received? More importantly, did in solve the 
problem with the Samsung signals?

I may have to take a close look, but not today...

>  I noticed in my testing before that lircd was 
> setting receive_endingtimeout to 61 at startup.  On my other machine, it 
> gets set to something like 100 ms.  Is this value derived from analyzing 
> the expected length of signals associated with the configured lircd.conf 
> remote files?

Lircd scans all the remotes in lircd.conf, and somehow computes that 
number as the smalles or largest number of ... something. (Must look it 
up...)

Does it work for you with a standard, say NEC1 setup?

Raspberry PI: Bypassing IR TX/RX

[Rajendra P. <raj...@ya...>]

Hello LIRC Group Members:
I am revisiting this group after a long time(2015 or so). So please pardon me if this is not the right address for the request.
I am successfully using RPI3B+ to transmit IR code to a connected device IR receiver, both inside an enclosure; so directly wire-able to bypass the IR TX/RX HW with a simple wires from GPIO.
Previously, I tried solution of rebuilding the Raspbian kernel etc and modifying the IR config file. But I could not succeed.
I am wondering if there is any more robust solution to the problem. I am using Raspbian Stretch:
    uname -a
    Linux SS-P1 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux
I greatly appreciate your help.
Thanks,Raj

Re: girs driver issues

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

Hi Tim,

On 2020-03-15 00:16, Tim Pletcher wrote:
> Hi all,
> 
> I am using GirsLite 1.0.2 via a self-compiled firmware on an Arduino 
> nano clone configured with a Vishay TSOP38438 for receiving only.  I 
> have customized the girs firmware to include only:
>      Base Receive Led Parameters
> On Xubuntu 20.04, this configuration works great with IrScrutinizer 
> using the girs client for capturing via receive.  I have generated some 
> lirc files that are working just fine with a custom built Iguana-IR 
> design RS-232 serial receiver i built a long time ago.
> 
> Unfortunately, I am encountering a few issues with the girs lirc driver 
> producing some odd behavior when testing with irw.  For testing, I am 
> using the following remote lircd.conf file from the lirc remote 
> database: https://pastebin.com/JZVFzBE9
> 
> First:
> I tested with GirsLite compiled using the default BEGINTIMEOUT value of 
> 10000 ms as found in the Agirs configuration from github (consequently, 
> i couldn't figure out how to pass PARAMETERS values to the girs lirc 
> driver to change this on the fly.....).

beginTimeout is not really interesting, in particular since you are not 
sending. You can leave it by default. Using the Girs driver, there is 
currently no possibility to change in at runtime.

> This configuration produced the following behavior:
> Upon pressing a remote key, irw indicates the signal was received and 
> then after a delay with no further remote keypresses, irw repeats 
> another of the same keypress.
> Example irw output sequence:
> 00000000e0e020df 00 KEY_1 SamsungBN59-01054A    <- pressed at time=0
> 00000000e0e020df 00 KEY_1 SamsungBN59-01054A    <- appears 10 seconds 
> later  (as an example, see line 316 in first log linked below).
> 
This is weird. On line 84, a sensible line is received, consisting of 
two copies of the expected signaö. The first half is decoded (line 
199ff), then for some reason, lircd goes in siesta for 10 seconds (why 
is line 203 empty??) and (line 208ff) it decodes the rest -- without 
recognizing it as repeat.

Try changing (in GirsLiteConfig.h) DEFAULT_RECEIVE_ENDINGTIMEOUT t0 30 
and undefine PARAMETERS and report back.

> If I press a remote key, followed by another different one shortly 
> thereafter, it first emits another repeat of the first key and then show 
> the second keypress 10 seconds later.

Let's concentrate on the first problem for now.

Greetz,

Bengt

girs driver issues

[Tim P. <ple...@gm...>]

Hi all,

I am using GirsLite 1.0.2 via a self-compiled firmware on an Arduino nano
clone configured with a Vishay TSOP38438 for receiving only.  I have
customized the girs firmware to include only:
    Base Receive Led Parameters
On Xubuntu 20.04, this configuration works great with IrScrutinizer using
the girs client for capturing via receive.  I have generated some lirc
files that are working just fine with a custom built Iguana-IR design
RS-232 serial receiver i built a long time ago.

Unfortunately, I am encountering a few issues with the girs lirc driver
producing some odd behavior when testing with irw.  For testing, I am using
the following remote lircd.conf file from the lirc remote database:
https://pastebin.com/JZVFzBE9

First:
I tested with GirsLite compiled using the default BEGINTIMEOUT value of
10000 ms as found in the Agirs configuration from github (consequently, i
couldn't figure out how to pass PARAMETERS values to the girs lirc driver
to change this on the fly.....).

This configuration produced the following behavior:
Upon pressing a remote key, irw indicates the signal was received and then
after a delay with no further remote keypresses, irw repeats another of the
same keypress.
Example irw output sequence:
00000000e0e020df 00 KEY_1 SamsungBN59-01054A    <- pressed at time=0
00000000e0e020df 00 KEY_1 SamsungBN59-01054A    <- appears 10 seconds
later  (as an example, see line 316 in first log linked below).

If I press a remote key, followed by another different one shortly
thereafter, it first emits another repeat of the first key and then show
the second keypress 10 seconds later.
sequence:
00000000e0e0a05f 00 KEY_2 SamsungBN59-01054A   <- initially pressed '2'
00000000e0e0a05f 00 KEY_2 SamsungBN59-01054A   <- appears at press of '3'
just after initial keypress
00000000e0e0609f 00 KEY_3 SamsungBN59-01054A   <- appears 10 seconds later

Trace1 log of an example session with this configuration found here:
https://pastebin.com/3y1Fng9U. See line 316 to see the repeat appearing 10
seconds later. I also frequently see errors of "Warning: girs: readline
buffer full:" spamming in syslog as seen in line 269 if try to put in many
keypresses quickly.

Second attempt:
I then experimented by changing the BEGINTIMEOUT value in the compiled
GirsLite firmware to 100 ms.  With this configuration, I still always
receive a keypress repeat in irw but the responsiveness to remote input is
much.  Unfortunately, a nasty hang always occurs with this configuration
where irw stops responding to input and lircd seems to block with no
further log output until i kill the process.
     A log showing this issue is linked here: https://pastebin.com/MYuYrR6e

The middle of the log is cropped and the lines associated with the hang are
at 2867 - 2871.  This is repeatable and always occurs after some period of
time with this BEGINTIMEOUT value.

I am seeing similar results/behavior on bare metal Xubuntu 18.04 (lircd
0.10.0) & VM Xubuntu 20.04 (lircd 0.10.1). I can manage the repeat
keypresses by using suppress_repeat in the lircd.conf for the remote. But,
I do want the remote receiver to be responsive and the hang in irw is
disconcerting

Can anyone using similar kit tell me if I need to do further configuration
or if there is a better way to tune for routine use of an arduino as a USB
IR receiver with girs?

Thanks,
Tim

Re: mode2 shows output, irrecord fails (using the remote out port of an amplifier)

[Robert J. <jae...@l3...>]

Am 06.03.20 um 20:04 schrieb Bengt Martensson:
>> Using IrScrutinizer to record buttons now also works, which is great.
> 
> would you mind telling me what hardware driver you are using? I have no
> idea....

First: I am not sure, if it really worked. E.g., for the "MODE" button
IrScrutinizer returned 0x39DDE (see the lircd.conf in my last message)
but ir-keytable returned 0x14760d. (I have tried both values in
lircd.conf and neither of them worked.)

Second: I have set the capture hardware to /dev/lirc0. Then in the
"Scrutinize remote" tab the RC5x buttons were automatically identified
as RC5x (D=20, S=118, F=13, T=1 for the abovementioned button). From
there I have exported the captured buttons as a lircd.conf.


Best,
Robert

Re: mode2 shows output, irrecord fails (using the remote out port of an amplifier)

[Matthias R. <hi...@ho...>]

On Fri, Mar 06, 2020 at 09:29:40AM +0100, Bengt Martensson wrote:
> Nice that it works now (I have not tried it myself). My gutfeeling is that
> is would probably be best to turn that driver into a /dev/lirc device, but I
> am not the expert here. Please keep us posted.

Not quite sure what you mean, gpio-ir-recv provides a /dev/lircX interface
that'll work just fine with lirc.

> @Hias:
> nice work. But for the record: I checked the Marantz "remote out" some 15
> years ago, long before the RPi was invented. It *is* active low -- there is
> no "likely" in the equation.

I can't really comment on the Marantz as I don't have one heere, but
something doesn't seem to quite add up:

TSOP etc receivers have open-collector / active-low outputs and that's what
gpio-ir is set up for by default. Since we saw inverted signals with the
setup the signal on the gpio pin must have been active-high.

so long,

Hias

Re: mode2 shows output, irrecord fails (using the remote out port of an amplifier)

[Matthias R. <hi...@ho...>]

On Fri, Mar 06, 2020 at 01:40:09PM +0100, Robert Jäschke wrote:
> The remote seems to be more complex than I thought, though. First, some
> buttons use the RC5x protocol. Second, there are two buttons
> ("CD"/"NET") which change the codes of the keys. E.g., while the number
> keys send out RC5 codes when in CD mode, they send out RC5x codes when
> in NET mode.

Instead of using lirc you could use in-kernel decoding, IIRC the rc5
decoder supports both rc5 and rc5x.

Just run "ir-keytable -p rc5 -t" then press buttons and see if you get
scancodes. If that works you could create a keymap file with the
scancode <-> key mapping and then - depending on your application -
just read the keys from stdin or the input event device or let
lirc in devinput mode or inputlirc translate the linux input events
to lirc events.

so long,

Hias

Re: mode2 shows output, irrecord fails (using the remote out port of an amplifier)

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

On 2020-03-06 13:40, Robert Jäschke wrote:
> Dear Bengt,
> 
> Am 06.03.20 um 09:29 schrieb Bengt Martensson:
>>>> https://www.raspberrypi.org/forums/viewtopic.php?p=1622026#p1622026
>>>
>>> Thank's a lot! It works like a charm. Problem solved. :-)
>>
>> Nice that it works now (I have not tried it myself). My gutfeeling is
>> that is would probably be best to turn that driver into a /dev/lirc
>> device, but I am not the expert here. Please keep us posted.
> 
> Using IrScrutinizer to record buttons now also works, which is great.

would you mind telling me what hardware driver you are using? I have no 
idea....

> The remote seems to be more complex than I thought, though. First, some
> buttons use the RC5x protocol.

Uhhh... "Every time" I look at Lirc I find "new" "interesting facts". 
As far as I am aware, Lircd.conf cannot cannot express a rc5x signal (it 
consists of seven bits Manchester-encoded, a middle gap, and then 12 
more Manchester-encoded bits. The lircd.conf language cannot express the 
middle gap. (If I am wrong, please correct me!)  IrScrutinizer's 
Lirc-generator also misses the goal, in that it ignores the middle gap. 
Sigh...

Thanx for bringing this to my attention. 
https://github.com/bengtmartensson/IrScrutinizer/issues/363

The workaround/fix is of course to generate use the "Lirc raw" export.

Greetz,

Bengt

Re: mode2 shows output, irrecord fails (using the remote out port of an amplifier)

[Robert J. <jae...@l3...>]

Dear Bengt,

Am 06.03.20 um 09:29 schrieb Bengt Martensson:
>>> https://www.raspberrypi.org/forums/viewtopic.php?p=1622026#p1622026
>>
>> Thank's a lot! It works like a charm. Problem solved. :-)
> 
> Nice that it works now (I have not tried it myself). My gutfeeling is
> that is would probably be best to turn that driver into a /dev/lirc
> device, but I am not the expert here. Please keep us posted.

Using IrScrutinizer to record buttons now also works, which is great.

The remote seems to be more complex than I thought, though. First, some
buttons use the RC5x protocol. Second, there are two buttons
("CD"/"NET") which change the codes of the keys. E.g., while the number
keys send out RC5 codes when in CD mode, they send out RC5x codes when
in NET mode. Thus, I have recorded some of the keys with IrScrutinizer
and have appended them as second remote in my lircd.conf:

> # Protocol name: RC5x
> begin remote
> 	name		marantz_amp-rc5x
> 	bits		19
> 	flags		RC5|CONST_LENGTH
> 	eps		10
> 	aeps		100
> 	zero		889	889
> 	one		889	889
> 	plead		889
> 	gap		114000
> 	toggle_bit	2
> 	frequency	36000
> 	begin codes
> 		POWER	0x0000000000059300
> 		TUNER	0x0000000000071FCA
> 		NETWORK	0x0000000000059FCA
> 		INPUT	0x0000000000079FC0
> 		INFO	0x00000000000592C0
> 		MODE	0x0000000000039DDE
> 		LEFT	0x0000000000019540
> 		RIGHT	0x0000000000039580
> 		UP	0x0000000000019400
> 		DOWN	0x0000000000039440
> 		ENTER	0x00000000000195C0
> 		+10	0x0000000000079280
> 	end codes
> end remote

Strangely, irw shows pushed buttons only for the RC5 codes, not for that
new remote with the RC5x codes. Any idea why that could happen? (lircd
logs that it's using both configured remotes.)


For my purposes using just the RC5 keys is fine. As I plan to upload a
complete lircd.conf somewhere it would be nice to include all buttons.


Best,
Robert

Re: mode2 shows output, irrecord fails (using the remote out port of an amplifier)

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

On 2020-03-06 08:54, Robert Jäschke wrote:
> Dear Matthias,
> 
> Am 05.03.20 um 23:00 schrieb Matthias Reichl:
>>> Is there any way to invert the signal on the software side? The gpio-ir
>>> kernel module in 4.19.66-v7+ apparently does not have a parameter for
>>> that
>> I've pushed a PR to make the signal polarity configurable in the
>> gpio-ir device tree overlay:
>>
>> https://github.com/raspberrypi/linux/pull/3490
>>
>> I also posted an answer in the thread on the RPi forum and attached
>> the enhanced gpio-ir.dtbo file there (just copy it to /boot/overlays)
>>
>> https://www.raspberrypi.org/forums/viewtopic.php?p=1622026#p1622026
> 
> Thank's a lot! It works like a charm. Problem solved. :-)

Nice that it works now (I have not tried it myself). My gutfeeling is 
that is would probably be best to turn that driver into a /dev/lirc 
device, but I am not the expert here. Please keep us posted.

@Hias:
nice work. But for the record: I checked the Marantz "remote out" some 
15 years ago, long before the RPi was invented. It *is* active low -- 
there is no "likely" in the equation.

 >> BTW, irrecord is a really not state-of-the art. Please use
 >> IrScrutinizer, which runs natively on the RPi. Although in this case it
 >> would not have helped you, because the driver for reading GPIO inverted
 >> is still not written...

 > Good to know. I have tried irscrutinizer before but I have always
 > received an OddSequenceLengthException.

IrScrutinizer wants signals to start with a pulse and end with a space, 
i.e. be of even number of duration. Lirc tends  to leave out an ending 
space. Anyhow, IrScrutinizer should be more forgiving in the current 
version (2.2.4). If problems occur with the current version, please 
report as bug on GitHub: 
https://github.com/bengtmartensson/IrScrutinizer/issues .

Greetz,

Bengt

Re: mode2 shows output, irrecord fails (using the remote out port of an amplifier)

[Robert J. <jae...@l3...>]

Dear Matthias,

Am 05.03.20 um 23:00 schrieb Matthias Reichl:
>> Is there any way to invert the signal on the software side? The gpio-ir
>> kernel module in 4.19.66-v7+ apparently does not have a parameter for
>> that
> I've pushed a PR to make the signal polarity configurable in the
> gpio-ir device tree overlay:
> 
> https://github.com/raspberrypi/linux/pull/3490
> 
> I also posted an answer in the thread on the RPi forum and attached
> the enhanced gpio-ir.dtbo file there (just copy it to /boot/overlays)
> 
> https://www.raspberrypi.org/forums/viewtopic.php?p=1622026#p1622026

Thank's a lot! It works like a charm. Problem solved. :-)


Best regards,
Robert

Re: mode2 shows output, irrecord fails (using the remote out port of an amplifier)

[Matthias R. <hi...@ho...>]

Hi Robert,

On Thu, Mar 05, 2020 at 09:42:51PM +0100, Robert Jäschke wrote:
> Is there any way to invert the signal on the software side? The gpio-ir
> kernel module in 4.19.66-v7+ apparently does not have a parameter for
> that

I've pushed a PR to make the signal polarity configurable in the
gpio-ir device tree overlay:

https://github.com/raspberrypi/linux/pull/3490

I also posted an answer in the thread on the RPi forum and attached
the enhanced gpio-ir.dtbo file there (just copy it to /boot/overlays)

https://www.raspberrypi.org/forums/viewtopic.php?p=1622026#p1622026

so long,

Hias

Re: mode2 shows output, irrecord fails (using the remote out port of an amplifier)

[Robert J. <jae...@l3...>]

Hi Bengt,

Am 05.03.20 um 10:29 schrieb Bengt Martensson:
>> I have connected the REMOTE OUT port of my amplifier (Marantz PM5005)
>> with the GPIO pin of my Raspberry Pi¹
> 
> The magic word here is that the remote out plug on Maranz outputs the
> signal *inverted* (signal present = low, no signal = high), so that your
> spaces show up as pulses, and vice versa. This explains the very long
> initial "pulse" you see. Taking this into account, your first signal

Thank you, that makes sense. I saw with Piscope that the signal was
exactly inverted to that of a TSOP I had connected to the Pi for testing
in parallel.


> decodes as  RC5: {D=16,F=16,T=1} in IrScrutinizer.
> 
> Ok, so we know that it is a Marantz amplifier, using RC5 with D=16. So I
> use IrScrutinizer to suck the corresponding device from irdb.tk, and use
> the Lirc-export. Produces the file enclosed.

Thank you. Unfortunately, it does not seem to work. I copied your file
to /etc/lirc/lircd.conf.d/pm5005.lirc.conf, restarted lircd and then run
irw but I get no output. (According to the systemd log lircd uses the
marantz_amp-rc5 remote and irw also connected as a client.)

Is there any way to invert the signal on the software side? The gpio-ir
kernel module in 4.19.66-v7+ apparently does not have a parameter for
that and I could also not find an option in the lirc (0.9.4c) docs. I
know that I could do it in hardware but it would be so much easier in
software (in theory ;-).¹


> BTW, irrecord is a really not state-of-the art. Please use
> IrScrutinizer, which runs natively on the RPi. Although in this case it
> would not have helped you, because the driver for reading GPIO inverted
> is still not written...

Good to know. I have tried irscrutinizer before but I have always
received an OddSequenceLengthException.



Best,
Robert


¹ I would rather patch the driver or lirc than solder.

Re: mode2 shows output, irrecord fails (using the remote out port of an amplifier)

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

Hi Robert,

On 2020-03-02 11:14, Robert Jäschke wrote:
> Dear all,
> 
> I have trouble getting irrecord to recognize my remote. With mode2 I can
> see pulse and space data but I can't push irrecord over a couple of dots
> when it tries to recognize my remote. Here's the full story:
> 
> I have connected the REMOTE OUT port of my amplifier (Marantz PM5005)
> with the GPIO pin of my Raspberry Pi¹

The magic word here is that the remote out plug on Maranz outputs the 
signal *inverted* (signal present = low, no signal = high), so that your 
spaces show up as pulses, and vice versa. This explains the very long 
initial "pulse" you see. Taking this into account, your first signal 
decodes as  RC5: {D=16,F=16,T=1} in IrScrutinizer.

Ok, so we know that it is a Marantz amplifier, using RC5 with D=16. So I 
use IrScrutinizer to suck the corresponding device from irdb.tk, and use 
the Lirc-export. Produces the file enclosed.

BTW, irrecord is a really not state-of-the art. Please use 
IrScrutinizer, which runs natively on the RPi. Although in this case it 
would not have helped you, because the driver for reading GPIO inverted 
is still not written...

Greetz,

Bengt

mode2 shows output, irrecord fails (using the remote out port of an amplifier)

[Robert J. <jae...@l3...>]

Dear all,

I have trouble getting irrecord to recognize my remote. With mode2 I can
see pulse and space data but I can't push irrecord over a couple of dots
when it tries to recognize my remote. Here's the full story:

I have connected the REMOTE OUT port of my amplifier (Marantz PM5005)
with the GPIO pin of my Raspberry Pi¹ and have installed LIRC 0.9.4c on
Raspbian Stretch with kernel 4.19.66 using the patch to support the
gpio-ir device.² With mode2 I can get outputs like this when pressing
buttons (this one is for VOLUME UP):

> Using driver default on device /dev/lirc0
> pulse 1948022
> space 895
> pulse 884
> space 901
> pulse 883
> space 901
> pulse 883
> space 1788
> pulse 890
> space 900
> pulse 883
> space 899
> pulse 883
> space 901
> pulse 882
> space 899
> pulse 1773
> space 1788
> pulse 890
> space 899
> pulse 884
> space 899
> pulse 883
> space 901
> timeout 129209

I repeated this four times with mode2 and four times with ir-ctl, each
time pressing the same button (VOLUME UP) and got slightly different
results (see plot.pdf and mode2_volup.tsv). Apart from the initial long
pulse with varying length (could that be a problem?) which I omitted in
the plot to get a better alignment, there's an inconsistent pattern
between roughly 1500μs and 5500μs. After that the pattern is identical
(as expected) except for the first run of ir-ctl (which might be an
outlier).

When I run "irrecord -n -H default -d /dev/lirc0" (also with "-f") I
don't manage to get more than a couple (three to four) dots when it
tries to detect the remote, although I am pressing many buttons randomly
(and long enough). I also started irrecord with an existing lirc.conf
for RC-5, RC-6, RECS80 and some Marantz device without any success
("Something went wrong: Cannot decode data").


Has someone an idea what's wrong or how I can solve this problem? Do the
patterns look like any valid code? Any advice on how to further debug
the problem would also be appreciated!



Best regards,
Robert




¹ https://www.raspberrypi.org/forums/viewtopic.php?p=1619963
² https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=235256

Re: config file for Spectrum DVR 210-H

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

On 2020-02-22 16:11, Matthew Ward wrote:
> after a lot of procrastination, i finally worked out the config file to 
> command via IR the Spectrum DVR supplied with my latest cable installation.
> 
> 
> 
> i don't recall how (if?) to upload configs to <some repository>, so here 
> is a copy.

You can make a Git pull request to 
https://sourceforge.net/projects/lirc-remotes/ , but, frankly, I doubt 
that it is a good idea, there are already unprocessed ones more than a 
year old ;-/

> the system thinks it's a "Spectrum210H" although all of the manufacturer 
> tags say Humax ... so not sure how to list this. Spectrum?  Humax?


http://irdb.globalcache.com/ knows a settop box from manufacturer 
"Spectrum" called "201-H Cable Receiver" so I guess that your name is 
not completely off.

I run your file through IrScrutinizer, and it did not decode. I 
downloaded the data from GlobalCache as above, (which did decode as 
Panasonic_Old, with modulation frequency of 58kHz). Turned out that your 
codes are identical (up to measurement errors) to theirs! So it is quite 
possible that it should be 58kHz instead of the 38kHz implied by no 
FREQUENCY in the Lirc file.

> all i know is:  it works.

Possibly less reliably than with correct frequency.

config file for Spectrum DVR 210-H

[Matthew W. <mw...@wt...>]

after a lot of procrastination, i finally worked out the config file
to command via IR the Spectrum DVR supplied with my latest cable
installation.






i don't recall how (if?) to upload configs to <some
repository>, so here is a copy.






the system thinks it's a "Spectrum210H" although all of the
manufacturer tags say Humax ... so not sure how to list this.
Spectrum?  Humax?






all i know is:  it works.

Re: lircd.conf for B.A.T. preamplifier

[Mark P. <pe...@ya...>]

On 07/02/2020 09.18, Bengt Martensson wrote:
> On 2020-02-06 23:58, Mark Persky via LIRC-list wrote:
>> Hello everyone!
>>
>> Please help me to find lircd.conf file for B.A.T. preamplifier. There 
>> are codes at irdb.tk,
>> however I don't realize how to convert these into lirc.conf format.
>
> Hi Mark,
>
> you can use IrScrutinizer to generate a lircd.conf with just a few 
> mouse clicks. Import from Import -> IMDB, select desired device, 
> "Import all", Select "Lirc" as export format, "Export parametric remote".
>
> Greetz,
>
> Bengt
>
>
Hi Bengt,

Thanks a lot for the IrScrutinizer - it' just amazing!

Regards,
Mark

Re: lircd.conf for B.A.T. preamplifier

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

On 2020-02-06 23:58, Mark Persky via LIRC-list wrote:
> Hello everyone!
> 
> Please help me to find lircd.conf file for B.A.T. preamplifier. There 
> are codes at irdb.tk,
> however I don't realize how to convert these into lirc.conf format.

Hi Mark,

you can use IrScrutinizer to generate a lircd.conf with just a few mouse 
clicks. Import from Import -> IMDB, select desired device, "Import all", 
Select "Lirc" as export format, "Export parametric remote".

Greetz,

Bengt

lircd.conf for B.A.T. preamplifier

[Mark P. <pe...@ya...>]

Hello everyone!

Please help me to find lircd.conf file for B.A.T. preamplifier. There 
are codes at irdb.tk,
however I don't realize how to convert these into lirc.conf format.

Regards,
Mark Persky

Re: Weirdness when trying to send commands to a Samsung TV

[Sahbi <sa...@ze...>]

Finally found a somewhat correct kernel source (4.14.34-_*3*_-osmc 
instead of 4.14.34-_*4*_-osmc) and managed to successfully compile the 
module, I could also load it without any errors and lirc still works for 
the other 3 remotes. However, it's still no good for the TV.

I verified that the pin is actually put in PWM mode. With the original 
module `gpio readall` shows the pin as simply "OUT", but with the 
patched version it shows ALT0 so it looks like it properly puts it in 
PWM mode. I even made sure the pin is for PWWM0 because apparently PWWM1 
is shared with audio, and I do have an HDMI cable attached. I also 
noticed that IrScrutinizer detected the frequency as 38029 before 
switching drivers, while now it reports a proper 38000. Furthermore, 
/sys/module/lirc_rpi/parameters/hardpwm exists and contains Y. So it 
looks like the driver works.

I even tried compiling lircd from git again but there was no change 
either. Might you have any other funky ideas about how to further 
troubleshoot this (or who else to possibly bug about it)? :D

On 07/11/19 21:19, Sahbi wrote:
>
>> Ouch!! Have you had a look at it (for example graphically in 
>> IrScrutinizer)? It is not even remotely close to what it is supposed 
>> to be. So we conclude that your /dev/lirc (lirc_rpi) is not even 
>> close to working correctly. Case closed!
> I did look at it, but I'm not all that familiar with raw IR stuff yet 
> so I had no idea what to look for exactly.
>> It gets the timing all messed up. (Recall that generating a 38kHz 
>> carrier in software requires an interrupt every 1/(2 * 38000) = 
>> 0.000013 s = 13 microseconds.)
> I see. Oddly enough though, the stereo remote also uses a frequency of 
> 38KHz and that works fine. But its signals are half the length of the 
> TV so that might be why I guess.
>> How to do it better is another topic. Let me just remark that I know 
>> of an unofficial driver using the hardware PWM of the RPi: 
>> https://github.com/Al-/lirc_rpi_hardpwm . See also 
>> http://lirc.10951.n7.nabble.com/hardware-pulse-wave-modulation-modified-kernel-module-tc11134.html
> Sounds interesting, I changed my IR sender's pin to one that supports 
> PWM according to a few docs. I'll try compiling the module and mess 
> with that.
>> To my knowledge, the lirc_rpi is deprecated by the Linux/RPi 
>> communities, but I am not sure it is for the "right" reason... ;-\
> Yeah it is, but the replacement gpio-ir doesn't even work half as well 
> as lirc_rpi. :D
>
> Thanks so far. =]

Re: Weirdness when trying to send commands to a Samsung TV

[Sahbi <sa...@ze...>]

> Ouch!! Have you had a look at it (for example graphically in 
> IrScrutinizer)? It is not even remotely close to what it is supposed 
> to be. So we conclude that your /dev/lirc (lirc_rpi) is not even close 
> to working correctly. Case closed!
I did look at it, but I'm not all that familiar with raw IR stuff yet so 
I had no idea what to look for exactly.
> It gets the timing all messed up. (Recall that generating a 38kHz 
> carrier in software requires an interrupt every 1/(2 * 38000) = 
> 0.000013 s = 13 microseconds.)
I see. Oddly enough though, the stereo remote also uses a frequency of 
38KHz and that works fine. But its signals are half the length of the TV 
so that might be why I guess.
> How to do it better is another topic. Let me just remark that I know 
> of an unofficial driver using the hardware PWM of the RPi: 
> https://github.com/Al-/lirc_rpi_hardpwm . See also 
> http://lirc.10951.n7.nabble.com/hardware-pulse-wave-modulation-modified-kernel-module-tc11134.html
Sounds interesting, I changed my IR sender's pin to one that supports 
PWM according to a few docs. I'll try compiling the module and mess with 
that.
> To my knowledge, the lirc_rpi is deprecated by the Linux/RPi 
> communities, but I am not sure it is for the "right" reason... ;-\
Yeah it is, but the replacement gpio-ir doesn't even work half as well 
as lirc_rpi. :D

Thanks so far. =]