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

The config file looks good. It uses the NECx2 protocol, and it is 
compatible with for example the file at ControlTower, Samsung TV,
"Most models". And since you can use it with the RPi B, it must be that 
the used Lirc version (Alec would add "or kernel") on RPi A that is the 
culprit. Based on my previous experience, I would consider the gap 
between the signals as most likely. For this, you can try to change 
"gap", say from 30000 to 150000 in steps of 10000.

You can also capture the output of RPi A using RPi B using either 
IrScrutinizer (use /dev/lirc as hardware) or mode2 (NOT lircd), and post 
the results here.

I am pretty sure that Lirc 0.9.0 also has almost the same 
debugging/tracing as the current, just that the options are named 
differently. Use e.g. git on Sourceforge to browse the code, or try man 
lircd on RPi A.



On 2019-11-04 18:15, Sahbi via LIRC-list wrote:
> 1. I'll post a condensed config at the end of this mail. I actually 
> mapped all buttons but I'm just testing with volume up/down. Of course I 
> tried sending codes for all buttons and there was no response for any of 
> them.
> 2. I'm actually using -# 2 on Pi B, because with just 1 copy the TV 
> doesn't respond. But even doing a SEND_START from Pi A doesn't make it 
> respond.
> 3. It seems lircd 0.9 doesn't yet support --loglevel/-D: unrecognized 
> option '--loglevel=trace1'. Any other way to grab more information from 
> lircd?
> 
> Config:
> 
> begin remote
> 
>    name samsung_lt22c300_tv
>    bits 32
>    flags SPACE_ENC|CONST_LENGTH
>    eps 30
>    aeps 100
>    header 4585 4499
>    one 598 1657
>    zero 598 528
>    ptrail 598
>    gap 108723
>    frequency 38000
> 
>        begin codes
>            KEY_VOLUMEUP             0xE0E0E01F
>            KEY_VOLUMEDOWN           0xE0E0D02F
>        end codes
> 
> end remote
>> Some first ideas:
>>
>> 1. Post your lircd.conf of the Samsung TV.
>> 2. Try sending several copies, say 3 (--count parameter to irsend),
>> 3. Increase logging level on Pi A (trace1 recommended) and look in the 
>> log for anything suspect.
>>
>> Greetz,
>>
>> Bengt
>>
> 
>