lirc-list

Re: Send IR without writing them to the config file - How to?

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

On 9/16/24 10:41, Sean Young wrote:
> On Sun, Sep 15, 2024 at 01:48:19PM +0200, Mariusz Ferdyn wrote:
>> The captured codes are:
>>
>>
>> mf@pi1:~ $ mode2 -H default -d /dev/lirc0
>> Using driver default on device /dev/lirc0
>> Trying device: /dev/lirc0
>> Using device: /dev/lirc0
>> pulse 8985
>> space 4468
>> pulse 617
>> space 1651
>> pulse 601
>> space 1652
>> pulse 604
>> space 499
> -snip-
>
> This looks good, this is probably the nec protocol.

Actually, the timing is that of the NEC protocol, but the payload is 104
bytes, instead of 32 for NEC. (Air conditioning?) The second signal can
be described in the IRP notation as

{568,msb}<1,-1|1,-3>(16,-8,A:104,1,-299m){A=0xc3fe070006000400000000a2e7}

Returning to your first question:


 > I would like to send these ad-hock mode without writing them to
the config file etc. How to do it?


Lirc is not intended for this use case. I once submitted a patch to the
then-maintainer Christoph Bartelmus, who was vehemently against it,
meaning that it is cleaner if data bases reside on the server. See
http://www.harctoolbox.org/lirc_ccf.html, but note that article is not
up-to-data any longer.


Have a look at IrScrutinizer (http://www.harctoolbox.org/lirc_ccf.html);
possibly you can use it for your purpose?


Bengt

Re: Send IR without writing them to the config file - How to?

[Sean Y. <se...@me...>]

On Sun, Sep 15, 2024 at 01:48:19PM +0200, Mariusz Ferdyn wrote:
> On 9/15/2024 10:12 AM, Sean Young wrote:
> > Hi,
> > 
> > On Sat, Sep 14, 2024 at 10:43:35PM +0200, Mariusz Ferdyn wrote:
> > > Using command mode2 -d /dev/lirc0 I received:
> > > 
> > > 
> > > Using driver devinput on device /dev/lirc0
> > > Trying device: /dev/lirc0
> > > Using device: /dev/lirc0
> > > code: 0xfd695000a94d50001f23000182110000
> > > code: 0x54020001740600005b02000182060000
> > > code: 0x4f0200010302000063020001ff010000
> > > code: 0x64020001030200005c0200010a020000
> > > code: 0x5d020001740600005902000171060000
> > > Partial read 4 bytes on /dev/lirc0
> > I think you need to run `mode2 -H default -d /dev/lirc0`, driver devinput
> > is not the right one.
> > 
> > > and now I would like to send these ad-hock mode without writing them to the
> > > config file etc. How to do it?
> > Please get the right codes first.
> > 
> > 
> > Sean
> > 
> The captured codes are:
> 
> 
> mf@pi1:~ $ mode2 -H default -d /dev/lirc0
> Using driver default on device /dev/lirc0
> Trying device: /dev/lirc0
> Using device: /dev/lirc0
> pulse 8985
> space 4468
> pulse 617
> space 1651
> pulse 601
> space 1652
> pulse 604
> space 499

-snip-

This looks good, this is probably the nec protocol.

Put all the pulse/space lines into a file. Then you can send it with

ir-ctl -s file

I don't know that this can be done easily with the lirc tooling. Maybe it
can be put into lircd.conf raw_codes remote definition, but this might be
too heavyweight for what you're looking for.


Sean

Re: Send IR without writing them to the config file - How to?

[Mariusz F. <mf...@fa...>]

On 9/15/2024 10:12 AM, Sean Young wrote:
> Hi,
>
> On Sat, Sep 14, 2024 at 10:43:35PM +0200, Mariusz Ferdyn wrote:
>> Using command mode2 -d /dev/lirc0 I received:
>>
>>
>> Using driver devinput on device /dev/lirc0
>> Trying device: /dev/lirc0
>> Using device: /dev/lirc0
>> code: 0xfd695000a94d50001f23000182110000
>> code: 0x54020001740600005b02000182060000
>> code: 0x4f0200010302000063020001ff010000
>> code: 0x64020001030200005c0200010a020000
>> code: 0x5d020001740600005902000171060000
>> Partial read 4 bytes on /dev/lirc0
> I think you need to run `mode2 -H default -d /dev/lirc0`, driver devinput
> is not the right one.
>
>> and now I would like to send these ad-hock mode without writing them to the
>> config file etc. How to do it?
> Please get the right codes first.
>
>
> Sean
>
The captured codes are:


mf@pi1:~ $ mode2 -H default -d /dev/lirc0
Using driver default on device /dev/lirc0
Trying device: /dev/lirc0
Using device: /dev/lirc0
pulse 8985
space 4468
pulse 617
space 1651
pulse 601
space 1652
pulse 604
space 499
pulse 622
space 505
pulse 618
space 501
pulse 625
space 500
pulse 623
space 1652
pulse 580
space 1676
pulse 599
space 1652
pulse 601
space 1663
pulse 601
space 1649
pulse 567
space 1672
pulse 602
space 1651
pulse 601
space 1667
pulse 587
space 1653
pulse 600
space 500
pulse 626
space 498
pulse 601
space 523
pulse 599
space 525
pulse 600
space 524
pulse 624
space 500
pulse 620
space 1658
pulse 599
space 1652
pulse 576
space 1676
pulse 578
space 525
pulse 624
space 503
pulse 597
space 525
pulse 610
space 525
pulse 597
space 521
pulse 623
space 503
pulse 602
space 515
pulse 608
space 522
pulse 598
space 517
pulse 619
space 501
pulse 601
space 522
pulse 599
space 525
pulse 607
space 519
pulse 623
space 1661
pulse 568
space 1677
pulse 598
space 500
pulse 599
space 525
pulse 599
space 547
pulse 585
space 530
pulse 625
space 490
pulse 596
space 527
pulse 598
space 523
pulse 600
space 524
pulse 600
space 524
pulse 600
space 524
pulse 600
space 524
pulse 601
space 525
pulse 606
space 527
pulse 599
space 523
pulse 597
space 1683
pulse 576
space 518
pulse 594
space 578
pulse 553
space 517
pulse 599
space 524
pulse 603
space 523
pulse 599
space 529
pulse 595
space 525
pulse 598
space 525
pulse 600
space 525
pulse 598
space 525
pulse 600
space 524
pulse 600
space 524
pulse 597
space 526
pulse 577
space 549
pulse 576
space 555
pulse 570
space 548
pulse 599
space 526
pulse 599
space 526
pulse 603
space 523
pulse 598
space 524
pulse 600
space 523
pulse 602
space 522
pulse 602
space 524
pulse 609
space 1681
pulse 570
space 523
pulse 629
space 499
pulse 609
space 508
pulse 601
space 521
pulse 678
space 450
pulse 604
space 516
pulse 596
space 526
pulse 599
space 523
pulse 601
space 528
pulse 600
space 512
pulse 598
space 1675
pulse 584
space 526
pulse 591
space 1681
pulse 573
space 527
pulse 611
space 534
pulse 574
space 528
pulse 595
space 1678
pulse 575
space 550
pulse 575
space 1682
pulse 572
space 1678
pulse 587
space 1679
pulse 573
space 542
pulse 581
space 545
pulse 577
space 544
pulse 572
space 554
pulse 569
space 558
pulse 571
timeout 21604
^C
mf@pi1:~ $ mode2 -H default -d /dev/lirc0
Using driver default on device /dev/lirc0
Trying device: /dev/lirc0
Using device: /dev/lirc0
pulse 9000
space 4463
pulse 601
space 1670
pulse 601
space 1653
pulse 588
space 515
pulse 626
space 499
pulse 622
space 502
pulse 624
space 502
pulse 623
space 1664
pulse 601
space 1653
pulse 588
space 1659
pulse 592
space 1652
pulse 600
space 1669
pulse 582
space 1661
pulse 598
space 1654
pulse 599
space 1653
pulse 600
space 1653
pulse 579
space 531
pulse 616
space 500
pulse 623
space 501
pulse 623
space 501
pulse 624
space 501
pulse 602
space 522
pulse 623
space 1636
pulse 619
space 1642
pulse 615
space 1641
pulse 617
space 495
pulse 618
space 499
pulse 625
space 503
pulse 625
space 504
pulse 616
space 499
pulse 624
space 501
pulse 623
space 517
pulse 608
space 501
pulse 623
space 501
pulse 601
space 525
pulse 602
space 519
pulse 624
space 500
pulse 624
space 500
pulse 602
space 1653
pulse 624
space 1635
pulse 617
space 500
pulse 623
space 501
pulse 623
space 501
pulse 624
space 502
pulse 601
space 524
pulse 611
space 514
pulse 601
space 527
pulse 624
space 518
pulse 600
space 526
pulse 584
space 523
pulse 601
space 528
pulse 602
space 515
pulse 598
space 524
pulse 604
space 548
pulse 577
space 1653
pulse 609
space 512
pulse 590
space 523
pulse 600
space 525
pulse 601
space 523
pulse 601
space 531
pulse 604
space 515
pulse 599
space 527
pulse 599
space 523
pulse 599
space 526
pulse 600
space 525
pulse 599
space 525
pulse 599
space 526
pulse 579
space 546
pulse 598
space 526
pulse 600
space 523
pulse 600
space 526
pulse 600
space 524
pulse 601
space 531
pulse 607
space 526
pulse 605
space 511
pulse 598
space 523
pulse 606
space 519
pulse 603
space 523
pulse 594
space 522
pulse 599
space 525
pulse 634
space 509
pulse 585
space 531
pulse 583
space 523
pulse 600
space 523
pulse 600
space 524
pulse 600
space 525
pulse 600
space 526
pulse 599
space 536
pulse 619
space 497
pulse 597
space 1666
pulse 587
space 526
pulse 598
space 1658
pulse 596
space 526
pulse 598
space 529
pulse 596
space 528
pulse 597
space 1659
pulse 593
space 539
pulse 591
space 1682
pulse 579
space 1678
pulse 561
space 1679
pulse 572
space 536
pulse 595
space 524
pulse 609
space 1668
pulse 569
space 1683
pulse 569
space 1683
pulse 571
timeout 13141
^C
mf@pi1:~ $

Re: Send IR without writing them to the config file - How to?

[Sean Y. <se...@me...>]

Hi,

On Sat, Sep 14, 2024 at 10:43:35PM +0200, Mariusz Ferdyn wrote:
> Using command mode2 -d /dev/lirc0 I received:
> 
> 
> Using driver devinput on device /dev/lirc0
> Trying device: /dev/lirc0
> Using device: /dev/lirc0
> code: 0xfd695000a94d50001f23000182110000
> code: 0x54020001740600005b02000182060000
> code: 0x4f0200010302000063020001ff010000
> code: 0x64020001030200005c0200010a020000
> code: 0x5d020001740600005902000171060000
> Partial read 4 bytes on /dev/lirc0

I think you need to run `mode2 -H default -d /dev/lirc0`, driver devinput
is not the right one.

> and now I would like to send these ad-hock mode without writing them to the
> config file etc. How to do it?

Please get the right codes first.


Sean

Send IR without writing them to the config file - How to?

[Mariusz F. <mf...@fa...>]

Using command mode2 -d /dev/lirc0 I received:


Using driver devinput on device /dev/lirc0
Trying device: /dev/lirc0
Using device: /dev/lirc0
code: 0xfd695000a94d50001f23000182110000
code: 0x54020001740600005b02000182060000
code: 0x4f0200010302000063020001ff010000
code: 0x64020001030200005c0200010a020000
code: 0x5d020001740600005902000171060000
Partial read 4 bytes on /dev/lirc0


and now I would like to send these ad-hock mode without writing them to 
the config file etc. How to do it?

Mariusz Ferdyn

Trying to generate working config for air conditioner remote

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

I'm trying to use irrecord (with -f option) to generate a config file, 
which has always worked fine but seems to have some troubles with this 
particular remote. The exact model of the AC is Eurom PAC 29R. Unlike 
many other AC remotes this one does not seem to include its own state 
(e.g. current temperature setting). It has no little display on it to 
show any current settings, so if people can't even see any state then 
it's probably safe to assume there is no state. I'm guessing because the 
unit has physical controls as well, so communicating changes from that 
end to the remote would be overly complex (and unreliable, if the remote 
is out of "sight").

Anyway, I'm using the "default" driver and I think the problem is 
related to errors I get during recording:

 > Something went wrong: Signal length is 0
 > That's weird because the signal length must be odd!

The signal length varies a lot too:
 > Something went wrong: Signal length is 192
 > Something went wrong: Signal length is 180
 > Something went wrong: Signal length is 172
 > Something went wrong: Signal length is 176
 > Something went wrong: Signal length is 138
 > Something went wrong: Signal length is 86

If I keep holding down the button long enough it will eventually 
succeed, but I think it's pretty much guaranteed to be garbage at this 
point anyway? Note that releasing the button once the error pops up and 
holding it down "fresh" will cause it to keep throwing errors, unless of 
course the next attempt proceeds too fast for me to even register the 
error. It doesn't seem to matter if I hold the remote right in front of 
the receiver or about 30-50 cm away, sending codes from the resulting 
config will always be ignored by the unit (but the IR LED does light 
up). I've verified that sending other IR codes at least works correctly; 
I have other configs and sending any code makes the relevant device 
respond immediately. I even tried the devinput driver (and without -f) 
but that just generates the code 0x0 for any and all buttons.

I'm running all this off a Raspberry Pi by the way.

~Sahbi

Re: Transfer lirc setup on CentOS-7

[Christopher S. H. <ch...@vi...>]

On Tue, Jul 16, 2024 at 02:55:05PM -0400, Chris Hilton wrote:
> Let me start by saying thanks again to Bengt Martensson! With his help I was able to get
> things going with lirc, installed from packages on my Rocky-9 test box so I have a setup
> that works.
> 
> My problem:
> 
> I'm trying to get lirc running to change channels on my set-top box for MythTV. I've run
> mythtv for a while and my current setup is Myth-0.29 on CentOS-7. My Cable TV company has
> dropped support the the Scientific Atlanta settop box that I currently use with this
> installation. That's a problem because I use firewire to change channels. The box that
> replaces it doesn't respond to my firewire channel changing program. But I can change
> channels using Lirc. I know it works and that it works very well, from testing my setup on a
> new Rocky-9 box.
> 

Update:

I can send codes using the binary packages that shipped with Rocky-8. I still can't get IR
receiving to work in either rocky-8 or rocky-9. That's not a must have right now but It
would be nice for debugging later. I would still very much like to get this hardware working
with CentOS-7 at least for the next month but now I have a workaround...


-- Chris

-- 
Chris

      __o          "All I was trying to do was get home from work."
    _`\<,_           -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton                    [chris/at/vindaloo/dot/com]

Transfer lirc setup on CentOS-7

[Christopher S. H. <ch...@vi...>]

Let me start by saying thanks again to Bengt Martensson! With his help I was able to get
things going with lirc, installed from packages on my Rocky-9 test box so I have a setup
that works.

My problem:

I'm trying to get lirc running to change channels on my set-top box for MythTV. I've run
mythtv for a while and my current setup is Myth-0.29 on CentOS-7. My Cable TV company has
dropped support the the Scientific Atlanta settop box that I currently use with this
installation. That's a problem because I use firewire to change channels. The box that
replaces it doesn't respond to my firewire channel changing program. But I can change
channels using Lirc. I know it works and that it works very well, from testing my setup on a
new Rocky-9 box.

**My current problem is transfering the setup from my Rocky-9 test environment to my
CentOS-7 production environment.**

Making things work on Rocky was as easy as:

    # lircd --driver=ftdix --device "serial=D*******,output=2" --nodaemon

in one terminal window, then:

    # irsend SEND_ONCE new_samsung_set_top_box "KEY_POWER"

et voila, my cablebox turned on. Channel changes was as simple.

Unfortunately, this doesn't work on CentOS-7


My question:

**Is there something simple that I'm missing, or is the software installed from EPEL rpms
for lirc too old to easily support what I want to do?**


Details

I'm thinking that I'm the last person in the world using MythTV with a Hauppauge HD-PVR and
one of the only people in the world who's MythTV is in a rack in my basement rather than in
my entertainment center next to my television. That's making my testing very difficult.

My IR blaster is a "FTDI USB IR Blaster" purchased from here:

    https://www.irblaster.info/usb_blaster.html

My hardware is old enough to have an actual working serial port and I also have an old style
serial IR blaster. Getting either of them working would be enough to keep me going here.


Thank you

-- Chris



-- 
Chris

      __o          "All I was trying to do was get home from work."
    _`\<,_           -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton                    [chris/at/vindaloo/dot/com]

Re: LIRC / MythTV setup questions

[Christopher S. H. <ch...@vi...>]

On Sun, Jun 30, 2024 at 02:39:36PM -0400, Chris Hilton wrote:
> [ ...snip... ]
>  

Thanks again Bengt,


I moved the IR rig downstairs in front of my IR repeater in my main stereo. From there I
figured out that none of the commands I was sending were actually doing anything because I
was using the wrong output on my ftdi dongle. In the end the file you sent me did the
trick. It's working now.

-- Chris

-- 
Chris

      __o          "All I was trying to do was get home from work."
    _`\<,_           -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton                    [chris/at/vindaloo/dot/com]

Re: LIRC / MythTV setup questions

[Christopher S. H. <ch...@vi...>]

On Sun, Jun 30, 2024 at 06:58:43PM +0200, Bengt Martensson wrote:
> On 6/30/24 04:16, Christopher Sean Hilton wrote:
> > Hello,
> > 
> > It's become time to update my mythtv. This change is being driven by the fact that the
> > Scientific Atlanta 4250 set top box which my cable provider, Altice / Optimum, choose so
> > many years ago will no longer be supported sometime in August. My current setup doesn't
> > require lirc, I use firewire tochange channels but the new cable box, an Optimum branded
> > Samsung SMT-C5320 doesn't respond to the firewire like the SA4250.
> 
> I found the IR codes for Samsung SMT-C5320 on the Internet, and loaded it
> into IrScrutinizer. The protocol was identified as Panasonic_Old. With said
> program, I also generated a lirc.conf file, enclosed. (The frequency looks a
> bit uncommon, if it does not work, try with 38000) Hope this helps.
> 
> 
> [ ...snip... ]
 
Thanks Bengt,

I tried that file and I got no joy. I'm starting to believe that I have a problem somewhere
in my setup and that I'm actually not emitting any IR signals at all. But I don't have a way
to test that. As a result, I'm getting discouraged and I'm running out of ideas.

I've ordered an IR Receiver on the hope that I my original thesis is correct and that the
only issue is that I'm sending the wrong codes so my catv box isn't able to respond to
them. I'm hoping that getting the receiver will let me use `irrecord` to create a local
`SMT-C5320.lircd.conf` file which would hopefully allow me to change channels on this
(these) cable boxes so I can use it with mythtv.

One of my big concerns is that I saw a note on a TV forum list that very specifically called
out this box as it was issued from CableVision back in the day. It seems that they custom
ordered them from Samsung to respond to the same remote that they shipped. This single
remote could control either an SA42xx or this Samsung set top box. You could switch between
the two set top boxes with making any configuration change to the remote. That has me
thinking that these SMT-C5320s have been hacked to respond to a special set of codes.

-- Chris



> # IrScrutinizer parametric export
> #
> # Creating tool: IrScrutinizer version 2.4.2-SNAPSHOT
> # Creating user: bengt
> # Creating date: Sun Jun 30 18:44:44 CEST 2024
> # Encoding: WINDOWS-1252
> #
> # Manufacturer: Samsung
> # Model: SMT-C5320
> # Displayname: Samsung SMT-C5320
> # Device Class: cable
> # Remotename: 
> #
> 
> # Protocol name: Panasonic_Old
> begin remote
> 	name		Samsung_SMT-C5320-Panasonic_Old
> 	bits		22
> 	flags		SPACE_ENC
> 	eps		30
> 	aeps		100
> 	zero		833	833
> 	one		833	2499
> 	header		3332	3332
> 	ptrail		833
> 	gap		44000
> 	frequency	57600
> 	begin codes
> 		ASTERISK	0x000000000037E103
> 		CHANNEL_DOWN	0x000000000036F121
> 		CHANNEL_UP	0x0000000000377111
> 		CURSOR_DOWN	0x000000000037A10B
> 		CURSOR_ENTER	0x0000000000366133
> 		CURSOR_LEFT	0x000000000037810F
> 		CURSOR_RIGHT	0x0000000000364137
> 		CURSOR_UP	0x000000000036812F
> 		DIGIT_0	0x0000000000373119
> 		DIGIT_1	0x000000000036113D
> 		DIGIT_2	0x000000000037111D
> 		DIGIT_3	0x000000000036912D
> 		DIGIT_4	0x000000000037910D
> 		DIGIT_5	0x0000000000365135
> 		DIGIT_6	0x0000000000375115
> 		DIGIT_7	0x000000000036D125
> 		DIGIT_8	0x000000000037D105
> 		DIGIT_9	0x0000000000363139
> 		ENTER	0x000000000036B928
> 		EXIT	0x0000000000366932
> 		FAVORITE	0x000000000037F101
> 		FORMAT_SCROLL	0x000000000036B928
> 		FORWARD	0x000000000036293A
> 		FUNCTION_BLUE	0x000000000036193C
> 		FUNCTION_GREEN	0x00000000000F7E10
> 		FUNCTION_RED	0x000000000037191C
> 		FUNCTION_YELLOW	0x000000000037E902
> 		GUIDE	0x000000000036C127
> 		INFO	0x000000000036213B
> 		LIVE	0x000000000036B129
> 		MENU_DVR	0x000000000036C926
> 		MENU_MAIN	0x000000000036F920
> 		MENU_SETUP	0x0000000000373918
> 		PAUSE	0x0000000000374117
> 		PIP	0x000000000037B908
> 		PIP_CHANNEL_DOWN	0x000000000037F900
> 		PIP_CHANNEL_UP	0x000000000036E922
> 		PIP_POSITION	0x0000000000377910
> 		PIP_SWAP	0x0000000000367930
> 		PLAY	0x000000000037990C
> 		POWER_TOGGLE	0x000000000037C107
> 		PREVIOUS_CHANNEL	0x000000000036E123
> 		RECORD	0x0000000000375914
> 		REPLAY	0x000000000037C906
> 		REVERSE	0x000000000037291A
> 		STOP	0x0000000000365934
> 		VIDEO_SOURCE	0x0000000000376113
> 	end codes
> end remote



-- 
Chris

      __o          "All I was trying to do was get home from work."
    _`\<,_           -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton                    [chris/at/vindaloo/dot/com]

Re: LIRC / MythTV setup questions

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

On 6/30/24 04:16, Christopher Sean Hilton wrote:
> Hello,
>
> It's become time to update my mythtv. This change is being driven by the fact that the
> Scientific Atlanta 4250 set top box which my cable provider, Altice / Optimum, choose so
> many years ago will no longer be supported sometime in August. My current setup doesn't
> require lirc, I use firewire tochange channels but the new cable box, an Optimum branded
> Samsung SMT-C5320 doesn't respond to the firewire like the SA4250.

I found the IR codes for Samsung SMT-C5320 on the Internet, and loaded 
it into IrScrutinizer. The protocol was identified as Panasonic_Old. 
With said program, I also generated a lirc.conf file, enclosed. (The 
frequency looks a bit uncommon, if it does not work, try with 38000) 
Hope this helps.


Greets,

Bengt

# IrScrutinizer parametric export
#
# Creating tool: IrScrutinizer version 2.4.2-SNAPSHOT
# Creating user: bengt
# Creating date: Sun Jun 30 18:44:44 CEST 2024
# Encoding: WINDOWS-1252
#
# Manufacturer: Samsung
# Model: SMT-C5320
# Displayname: Samsung SMT-C5320
# Device Class: cable
# Remotename:
#

# Protocol name: Panasonic_Old
begin remote
     name        Samsung_SMT-C5320-Panasonic_Old
     bits        22
     flags        SPACE_ENC
     eps        30
     aeps        100
     zero        833    833
     one        833    2499
     header        3332    3332
     ptrail        833
     gap        44000
     frequency    57600
     begin codes
         ASTERISK    0x000000000037E103
         CHANNEL_DOWN    0x000000000036F121
         CHANNEL_UP    0x0000000000377111
         CURSOR_DOWN    0x000000000037A10B
         CURSOR_ENTER    0x0000000000366133
         CURSOR_LEFT    0x000000000037810F
         CURSOR_RIGHT    0x0000000000364137
         CURSOR_UP    0x000000000036812F
         DIGIT_0    0x0000000000373119
         DIGIT_1    0x000000000036113D
         DIGIT_2    0x000000000037111D
         DIGIT_3    0x000000000036912D
         DIGIT_4    0x000000000037910D
         DIGIT_5    0x0000000000365135
         DIGIT_6    0x0000000000375115
         DIGIT_7    0x000000000036D125
         DIGIT_8    0x000000000037D105
         DIGIT_9    0x0000000000363139
         ENTER    0x000000000036B928
         EXIT    0x0000000000366932
         FAVORITE    0x000000000037F101
         FORMAT_SCROLL    0x000000000036B928
         FORWARD    0x000000000036293A
         FUNCTION_BLUE    0x000000000036193C
         FUNCTION_GREEN    0x00000000000F7E10
         FUNCTION_RED    0x000000000037191C
         FUNCTION_YELLOW    0x000000000037E902
         GUIDE    0x000000000036C127
         INFO    0x000000000036213B
         LIVE    0x000000000036B129
         MENU_DVR    0x000000000036C926
         MENU_MAIN    0x000000000036F920
         MENU_SETUP    0x0000000000373918
         PAUSE    0x0000000000374117
         PIP    0x000000000037B908
         PIP_CHANNEL_DOWN    0x000000000037F900
         PIP_CHANNEL_UP    0x000000000036E922
         PIP_POSITION    0x0000000000377910
         PIP_SWAP    0x0000000000367930
         PLAY    0x000000000037990C
         POWER_TOGGLE    0x000000000037C107
         PREVIOUS_CHANNEL    0x000000000036E123
         RECORD    0x0000000000375914
         REPLAY    0x000000000037C906
         REVERSE    0x000000000037291A
         STOP    0x0000000000365934
         VIDEO_SOURCE    0x0000000000376113
     end codes
end remote

LIRC / MythTV setup questions

[Christopher S. H. <ch...@vi...>]

Hello,

It's become time to update my mythtv. This change is being driven by the fact that the
Scientific Atlanta 4250 set top box which my cable provider, Altice / Optimum, choose so
many years ago will no longer be supported sometime in August. My current setup doesn't
require lirc, I use firewire tochange channels but the new cable box, an Optimum branded
Samsung SMT-C5320 doesn't respond to the firewire like the SA4250.

My equipment is an FTDI FT230X transmitter setup in lirc under Rocky Linux 9.

I've installed the following modules:

    libftdi-1.5-2.el9.aarch64

    lirc-libs-0.10.0-36.el9.aarch64
    lirc-core-0.10.0-36.el9.aarch64
    lirc-tools-gui-0.10.0-36.el9.aarch64
    lirc-drv-ftdi-0.10.0-36.el9.aarch64
    lirc-doc-0.10.0-36.el9.noarch
    lirc-config-0.10.0-36.el9.noarch

I'm running:

    # lircd --driver=ftdix --device "serial=D<serialno>,output=3"

to start lircd. I think everything is running okay. 

I'm at the stage of trying various remote modules to control the power and the channel on
the current cable box. I'm only getting one warning and I don't know if it's significant:

    ... lircd-0.10.0[18356]: Warning: Failed to set scheduling policy to SCHED_FIFO:
                             Operation not permitted Sending will not run with real-time
			     priority and you may suffer USB buffer underruns causing
			     corrupt IR signals


I'm hoping that I'm on the right track and that the problem that I have is that I'm just
using the wrong driver for the Samsung set top box. I do know that Optimum set these cable
boxes up to respond to the same remote control that they issued for their SA boxes like my
SA4250 so I suspect that my box needs custom code but I don't have a way to test that.

I think that my next steps are to:

1. Setup some sort of IR receiving capability so I can use `irrecord` to capture the codes
   that my remote is sending and create a new remote file?


------------------------------------------------------------

Does a proper remote file `xxx.lircd.conf` exist for this cable box and am I just missing
it?

Is the approach I outlined a good way to get to what I need?

Am I overlooking something else?

P.S. I do have a hauppauge HD-PVR, my capture device for MythTV. Would setting that up as a
capture device be a good plan or should I just find some simple, $20 or less IR receiver
that's support to save myself some trouble?


-- 
Chris

      __o          "All I was trying to do was get home from work."
    _`\<,_           -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton                    [chris/at/vindaloo/dot/com]

Re: Missing something basic no doubt

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

Sorry for taking so long to answer.

On 5/1/24 16:37, James B Huber wrote:
> ok, see below....
>
> On Wed, 2024-05-01 at 14:26 +0200, Bengt Martensson wrote:
>> On 4/30/24 21:48, James B Huber wrote:
>>> Hardware is just fine...it's a USB device, move it to a rpi-4b, works
>>> fine....move it to my Linux Mint box, it works fine.


One thing to try: On all your machines, install IrScrutinizer
https://github.com/bengtmartensson/IrScrutinizer/releases/tag/Version-2.4.1,
then with the thing plugged in, open it as hardware -> /dev/lirc ->
Device /dev/lirc0, and compare the "detected properites" between the
working and non-working hosts. You can of course  also try to capture
from IrScrutinizer, but it will probably not work. You said that
transmitting works?


And, to repeat myself,

>>
>> Then it must be a problem with drivers/modules.... mode2
>> should, when a RC6 or MCE signal is fired, output mostly duration of
>> length 444 and 888 (+- 30%, say). For now, leave Lirc out of the equaton.


If still no clue, you have to go to driver/modules/Linux gurus. The
Linux media list may be an address. Please post a link here if you do
so.  Sean, are you here?


Greetings on the Star Wars day,

Bengt

Re: Missing something basic no doubt

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

On 4/30/24 21:48, James B Huber wrote:
> Hardware is just fine...it's a USB device, move it to a rpi-4b, works
> fine....move it to my Linux Mint box, it works fine.


Then it must be a problem with drivers/modules. First verify that there
is no /dev/lirc* if your dongle is not connected, and there is exactly
one (/dev/lirc0) when you connect it. Then do lsusb with the device
connected, also modinfo mceusb, as well as dmsg| tail (just after you
have connected the device), and look for anything interesting. mode2
should, when a RC6 or MCE signal is fired, output mostly duration of
length 444 and 888 (+- 30%, say). For now, leave Lirc out of the equaton.


> This was working on this hardware and O/S...but the SD card died, I
> had to rebuild...


Offtopic: There appears to be a consensus that using a (micro-) SD card
for the OS in a productive machine is not a good idea; sooner or later
they go belly-up. Like yours ;-)-  I am using a Bananapi M5 with 16GB
eMMC memory for home assistant myself.

Greetz,

Bengt

Re: Missing something basic no doubt

[James B H. <jb...@ju...>]

Hardware is just fine...it's a USB device, move it to a rpi-4b, works
fine....move it to my Linux Mint box, it works fine.
This was working on this hardware and O/S...but the SD card died, I had
to rebuild...

Haven't been able to get this working right since.

The config file is the same on all boxes...
[SNIP]
   begin remote
   
   name mceusb
   bits 16
   flags RC6|CONST_LENGTH
   rc6_mask 0x100000000
   eps 30
   aeps 100
   header 2667 889
   one 444 444
   zero 444 444
   gap 105000
   toggle_bit 22
   pre_data_bits 21
   pre_data 0x37FF0
   
And if I could make the stupid CEC junk go away I would, putting the
"recommended" adds to config.txt does'nt help:
   hdmi_ignore_cec=1
   hdmi_ignore_cec_init=1
and blacklisting the cec kernel module doesn't keep it from loading
either.

But...I don't think that where the issue is...this has to be something
really dumb, but it's been 4 days of trying and getting nowhere.

Jim

On Tue, 2024-04-30 at 20:51 +0200, Bengt Martensson wrote:
> On 4/30/24 17:09, James B Huber wrote:
>  
> > 
> > Folks,
> >   Have been using lirc for like forever, anyway I got new
> > Raspberrypi-5, it is replacing a RPI-4B, unplug one, plug in
> > the other. The MCEUSB receiver and remote I was using (and it
> > works) is the same one I am still using.
> > 
> > Issue, I have ZIPPO output showing up in IRW.
> > 
> > I see the data coming in via mode2:
> >    pi@rpi-5:/usr/lib/systemd/system $ mode2
> >    Using driver default on device /dev/lirc0
> >    Trying device: /dev/lirc0
> >    Using device: /dev/lirc0
> >    pulse 650
> >    space 52200
> >    pulse 650
> >    space 52250
> >    pulse 650
> >    timeout 127000
> 
> This is not a sensible IR signal, so it is no wonder that it does not
> decode. Smells like a lowlevel/hardware error.
> 
> I recommend using a well known signal (e.g. RC5 or NEC) in the
> install/debug phase. And make sure cec and devinput is diabled.
> PS. What is "ZIPPO output"? https://www.zippo.de/ ??
> Greetz,
> Bengt
> 
>  

Re: Missing something basic no doubt

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

On 4/30/24 17:09, James B Huber wrote:
> Folks,
>   Have been using lirc for like forever, anyway I got new
> Raspberrypi-5, it is replacing a RPI-4B, unplug one, plug in
> the other. The MCEUSB receiver and remote I was using (and it works)
> is the same one I am still using.
>
> Issue, I have ZIPPO output showing up in IRW.
>
> *I see the data coming in via mode2:*
> pi@rpi-5:/usr/lib/systemd/system $ mode2
> Using driver default on device /dev/lirc0
> Trying device: /dev/lirc0
> Using device: /dev/lirc0
> pulse 650
> space 52200
> pulse 650
> space 52250
> pulse 650
> timeout 127000


This is not a sensible IR signal, so it is no wonder that it does not
decode. Smells like a lowlevel/hardware error.


I recommend using a well known signal (e.g. RC5 or NEC) in the
install/debug phase. And make sure cec and devinput is diabled.

PS. What is "ZIPPO output"? https://www.zippo.de/ ??

Greetz,

Bengt

Missing something basic no doubt

[James B H. <jb...@ju...>]

Folks,
  Have been using lirc for like forever, anyway I got new Raspberrypi-
5, it is replacing a RPI-4B, unplug one, plug in
the other. The MCEUSB receiver and remote I was using (and it works) is
the same one I am still using.

Issue, I have ZIPPO output showing up in IRW.

I see the data coming in via mode2:
   pi@rpi-5:/usr/lib/systemd/system $ mode2
   Using driver default on device /dev/lirc0
   Trying device: /dev/lirc0
   Using device: /dev/lirc0
   pulse 650
   space 52200
   pulse 650
   space 52250
   pulse 650
   timeout 127000
   
ir-keytable sees the device:
   pi@rpi-5:~ $ ir-keytable
   Found /sys/class/rc/rc1/ with:
   Name: vc4-hdmi-1
   Driver: cec
   Default keymap: rc-cec
   Input device: /dev/input/event3
   Supported kernel protocols: cec 
   Enabled kernel protocols: cec 
   bus: 30, vendor/product: 0000:0000, version: 0x0001
   Repeat delay = 0 ms, repeat period = 125 ms
   Found /sys/class/rc/rc2/ with:
   Name: Media Center Ed. eHome Infrared Remote Transceiver (0471:060c)
   Driver: mceusb
   Default keymap: rc-rc6-mce
   Input device: /dev/input/event9
   LIRC device: /dev/lirc0
   Attached BPF protocols: Operation not permitted
   Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo
   mce_kbd rc-6 sharp xmp imon 
   Enabled kernel protocols: lirc 
   bus: 3, vendor/product: 0471:060c, version: 0x0101
   Repeat delay = 500 ms, repeat period = 125 ms
   Found /sys/class/rc/rc0/ with:
   Name: vc4-hdmi-0
   Driver: cec
   Default keymap: rc-cec
   Input device: /dev/input/event1
   Supported kernel protocols: cec 
   Enabled kernel protocols: cec 
   bus: 30, vendor/product: 0000:0000, version: 0x0001
   Repeat delay = 0 ms, repeat period = 125 ms

however irw sees nothing:

lircd loads, read config fine, and knows the remotes:
Apr 30 09:52:03.439525 rpi-5.judahnet.net lircd: Notice: Current
driver: default
Apr 30 09:52:03.439530 rpi-5.judahnet.net lircd: Notice: Driver API
version: 3
Apr 30 09:52:03.439536 rpi-5.judahnet.net lircd: Notice: Driver
version: 0.10.0
Apr 30 09:52:03.439541 rpi-5.judahnet.net lircd: Notice: Driver info:
See file:///usr/share/doc/lirc/plugindocs/default.html
Apr 30 09:52:03.439562 rpi-5.judahnet.net lircd: Warning: -------------
----------- Log re-opened ----------------------------
Apr 30 09:52:03.439572 rpi-5.judahnet.net lircd: Info: lircd: Opening
log, level: Info
Apr 30 09:52:03.439653 rpi-5.judahnet.net lircd: Notice: Using systemd
fd
Apr 30 09:52:03.439667 rpi-5.judahnet.net lircd: Warning: Running as
root
Apr 30 09:52:03.442705 rpi-5.judahnet.net lircd: Info: Using remote:
mceusb.
Apr 30 09:52:03.442810 rpi-5.judahnet.net lircd: Info: Using remote:
BHN.
Apr 30 09:52:03.442837 rpi-5.judahnet.net lircd: Notice:
/etc/lirc/lircd.conf: BHN: Multiple values for same code: OK
Apr 30 09:52:03.442864 rpi-5.judahnet.net lircd: Notice:
/etc/lirc/lircd.conf: BHN: Multiple values for same code: ENTER
Apr 30 09:52:03.443295 rpi-5.judahnet.net lircd: Notice: lircd(default)
ready, using /var/run/lirc/lircd
Apr 30 09:52:51.408223 rpi-5.judahnet.net lircd: Notice: accepted new
client on /var/run/lirc/lircd
Apr 30 09:52:51.408353 rpi-5.judahnet.net lircd: Info: [lirc] protocol
is enabled
Apr 30 09:53:17.868489 rpi-5.judahnet.net lircd: Info: removed client

Relevent portion of lirc_options.conf:
   [lircd]
   nodaemon = False
   driver = default
   device = /dev/lirc0
   output = /var/run/lirc/lircd
   pidfile = /var/run/lirc/lircd.pid
   plugindir = /usr/lib/aarch64-linux-gnu/lirc/plugins
   permission = 666
   allow-simulate = No
   repeat-max = 600
   logfile = /var/log/lirc.log
   
I have moved the devinput config out of the way
(/etc/lirc/lircd.conf.d/devinput.lircd.conf to
devinput.lircd.conf.DIST)

Oh, and IR Blasting out of the things works correctly...Last but not
least, the mceusb module is loaded, and so is the cec module (even
thouogh I blacklisted it in /etc/modeprobe.d/raspi-blacklist.conf).....
   pi@rpi-5:/var/log $ lsmod|grep cec
   cec 65536 1 vc4
   pi@rpi-5:/var/log $ lsmod|grep mceusb
   mceusb 49152 0
   


Anyone have a clue either what I've done wrong, or how to troubleshoot
this ?

pi@rpi-5:/var/log $ uname -r
6.6.28+rpt-rpi-2712
pi@rpi-5:/var/log $ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian


Regards,
Jim Huber

Re: decode of advanced RC5 packets from Marantz remotes

[Sean Y. <se...@me...>]

On Tue, Mar 19, 2024 at 11:08:01AM +0100, Bengt Martensson wrote:
> Hi Petre,
> > ... this time I'd like to successfully decode the advanced RC5 codes generated by modern Marantz remote controls, which might require some slight additions to the lirc decoder sourcecode.
> 
> The "advanced rc5 codes" are often called the protocol "rc5x". This
> protocol has an IRP form as
> 
> 
> {36k,msb,889}<1,-1|-1,1>((1,~S:1:6,T:1,D:5,-4,S:6,F:6,^114m)*,T=1-T)
> [D:0..31,S:0..127,F:0..63,T@:0..1=0].
> 
> 
>  It is fully supported by IrpTransmogrifier and IrScrutinizer. As an
> example, here  (
> https://raw.githubusercontent.com/bengtmartensson/GirrLib/master/Girr/Marantz/marantz_is201.girr
> ) is an RX5x device, the Maranz IS201 iPod dock.
> 
> 
> I would personally recommend against investing time in patching Lirc
> (for a number of reasons), and instead find another solution. Raw Lirc
> codes might be the most easily suggested one (depending on want it to
> do).  But feel free to ignore my suggestion ;-).

If you are on linux, maybe the kernel IR decoders work for you. They support
the rc5x protocol. You can test this with `ir-keytable -p rc5 -t`.

Linux kernel decoders are very limited but may just work in your case.


Sean

Re: decode of advanced RC5 packets from Marantz remotes

[Petre R. <pet...@su...>]

hello Bengt,

On Tue, Mar 19, 2024 at 11:08:01AM +0100, Bengt Martensson wrote:
> Hi Petre,
> > ... this time I'd like to successfully decode the advanced RC5 codes generated by modern Marantz remote controls, which might require some slight additions to the lirc decoder sourcecode.
> 
> The "advanced rc5 codes" are often called the protocol "rc5x". This
> protocol has an IRP form as
> 
> 
> {36k,msb,889}<1,-1|-1,1>((1,~S:1:6,T:1,D:5,-4,S:6,F:6,^114m)*,T=1-T)
> [D:0..31,S:0..127,F:0..63,T@:0..1=0].
> 
> 
>   It is fully supported by IrpTransmogrifier and IrScrutinizer. As an
> example, here  (
> https://raw.githubusercontent.com/bengtmartensson/GirrLib/master/Girr/Marantz/marantz_is201.girr
> ) is an RX5x device, the Maranz IS201 iPod dock.
> 
> I would personally recommend against investing time in patching Lirc
> (for a number of reasons), and instead find another solution. Raw Lirc
> codes might be the most easily suggested one (depending on want it to
> do).  But feel free to ignore my suggestion ;-).

thank you for the pointer. your project's scope does looks really interesting, I love signal analysers in particular.

but here I'm looking for a lightweight solution for decoding 19bits of data.

if patching the lirc project itself is not recommended, is there any way of telling lircd to use an external decoder for the raw data it gets from the driver? or should I simply write a mode2 wrapper (a C application that spawns mode2 and gets it's stdout)?

cheers,
peter

Re: decode of advanced RC5 packets from Marantz remotes

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

Hi Petre,
> ... this time I'd like to successfully decode the advanced RC5 codes generated by modern Marantz remote controls, which might require some slight additions to the lirc decoder sourcecode.

The "advanced rc5 codes" are often called the protocol "rc5x". This
protocol has an IRP form as


{36k,msb,889}<1,-1|-1,1>((1,~S:1:6,T:1,D:5,-4,S:6,F:6,^114m)*,T=1-T)
[D:0..31,S:0..127,F:0..63,T@:0..1=0].


  It is fully supported by IrpTransmogrifier and IrScrutinizer. As an
example, here  (
https://raw.githubusercontent.com/bengtmartensson/GirrLib/master/Girr/Marantz/marantz_is201.girr
) is an RX5x device, the Maranz IS201 iPod dock.


I would personally recommend against investing time in patching Lirc
(for a number of reasons), and instead find another solution. Raw Lirc
codes might be the most easily suggested one (depending on want it to
do).  But feel free to ignore my suggestion ;-).


Greetz,

Bengt

decode of advanced RC5 packets from Marantz remotes

[Petre R. <pet...@su...>]

Hello!

I'm back to tinkering with this project after about 25 years.
this time I'd like to successfully decode the advanced RC5 codes generated by modern Marantz remote controls, which might require some slight additions to the lirc decoder sourcecode.

these remotes generate, based partly on the PM8006 Service Manual a packet that contains

  a sync pulse
  2 bit pre (a start bit and a toggle bit)
  5 bit system address
  3.5ms space
  6 bit command
  6 bit extension

  in order to support commands above 0x3f (there are 11 of these), if the start bit is 0 then command needs to be OR-ed with 1 << 6.

you can see the captured signal trace that lirc gets when pressing the '5' key here: https://pasteboard.co/BzF1kHFQwVqi.png
highlighted is the 3.5ms gap between the system addr and the command.

# KEY_5 decode
sync
start   1
toggle  0 or 1
system   11001 = 25
3.5ms mid-packet gap
cmd     000101 = 5
ext     000000 = 0

for the time being I have tweaked the get_pre() function to accept a configuration like
    name          RC001PMND
    bits          12
    flags         RC5|CONST_LENGTH
    pre_data_bits 7
    pre_data      0x59
    pre           0   3500
    toggle_bit_mask 0x20000
    [..]

so that the system address is part of pre and the mid-packet gap is defined by the 'pre' option, but I'm not sure this is the way.

maybe a better idea would be to add an extra configuration option, something like

gap_at_bit  8 3500

which would expect a 3.5ms space at bit 8. is this a better solution or do you see a more elegant alternative?
I do intend to contribute this code back into the project, so your feedback is more than welcome.

my very best regards,
peter

Philips (or NXP) eHome Infrared Receiver -- OVU4003/00

[Nahshon W. <sp...@gm...>]

 Hello there,

No other package gives me as much joy and frustration as this one.
I hope to master it some day soon, and I need your help getting there.

Can irsend use this device which also comes with a blaster?
What is the absolute checklist to get a working installation with
standardised off the shelf popular devices?

Problem:
irw is not detecting a thing but mode2 works.

Objective.
To reliably use irexec and irsend

Hardware
A zotac remote. Small one that fits in the palm, designed for MCE.
Philips (or NXP) eHome Infrared Receiver (Microsoft MCE)
Running  on Archlinux on the raspberry Pi 3b Plus


UDEV rules added for consistent recognition of the receiver.

```
$  ls -l /dev/ir-receiver
lrwxrwxrwx 1 root root 12 Dec  7 20:38 /dev/ir-receiver -> input/event3

$ ls -l /dev/lirc0
crw-rw---- 1 root uucp 251, 0 Dec  7 20:38 /dev/lirc0

```

contents of /etc/lirc/lircd.conf

```
#include "lircd.conf.d/*.conf"
include "*/etc/lirc/lircd.conf.d/**.conf"
```

zotac.lircd.conf

```
irdb-get download zotac/zotac.lircd.conf

copied to
/etc/lirc/lircd.conf.d/zotac.conf
```


contents of /etc/lirc/lirc_opotions.conf

```
[lircd]
nodaemon        = False
driver          = devinput
#device          = auto
output          = /var/run/lirc/lircd
pidfile         = /var/run/lirc/lircd.pid
plugindir       = /usr/lib/lirc/plugins
permission      = 666
allow-simulate  = No
repeat-max      = 600
#effective-user =
#listen         = [address:]port
#connect        = host[:port]
#loglevel       = 6
#release        = true
#release_suffix = _EVUP
#logfile        = ...
#driver-options = ...
#driver = default
#device = /dev/lirc0
device = /dev/ir-receiver



[lircmd]
uinput          = False
nodaemon        = False

# [modinit]
# code = /usr/sbin/modprobe lirc_serial
# code1 = /usr/bin/setfacl -m g:lirc:rw /dev/uinput
# code2 = ...


# [lircd-uinput]
# add-release-events = False
# release-timeout    = 200
# release-suffix     = _EVUP

````

pioneer car remotes

[sergio <se...@ou...>]

Hello!

I'm trying to capture a new pioneer remote, but irrecord doesn't 
distinguish some buttons. As I see on xmode2 there are two types of 
buttons: the second ones are twice longer with same first half. And no 
one of the have a fixed prefix. Something like UTF-8.

xmode2 screenshot:
https://sergio.outerface.net/misc/xmode2-pioneer.png
first tree buttons (named A, B, C on the screenshot) gives one line
last tree buttons (named D, E, F on the screenshot) gives two lines

Buttons of the first type are recorded and work fine.
Buttons of the second type are recorded the same button.
Trying to record only second type buttons fails with:

```
Now start pressing buttons on your remote control.

It is very important that you press many different buttons randomly
and hold them down for approximately one second. Each button should
generate at least one dot but never more than ten dots of output.
Don't stop pressing buttons until two lines of dots (2x80) have
been generated.

Press RETURN now to start recording.
................................................................................
Got gap (6463 us)}

Please keep on pressing buttons like described above.
...............................................................................
Checking for toggle bit mask.
Please press an arbitrary button repeatedly as fast as possible.
Make sure you keep pressing the SAME button and that you DON'T HOLD
the button down!.
If you can't see any dots appear, wait a bit between button presses.

Press RETURN to continue.
Cannot find any toggle mask.
But I know for sure that RC6 has a toggle bit!
zsh: exit 1     irrecord
```


Remotes are Pioneer CD-R320 (possible CXC3173 CXC5719 CXC9605 CXE9606 in 
other countries) and CD-R510 (possible CXC2665 in other countries)


version 0.10.1, debian sid, TSOP31238 connected to FT232RL

-- 
sergio.

Re: Sharp send timing

[Sean Y. <se...@me...>]

On Mon, Sep 25, 2023 at 10:08:59PM -0400, Joe Ferner wrote:
> The Sharp remote send timing appears to be off from what I can track down.
> I started investigating this because my Denon receiver I'm trying to send
> commands to appears to be more sensitive to IR command timing and doesn't
> always response where as my other devices appear to work just fine using
> LIRC.
> 
> According to this page https://www.sbprojects.net/knowledge/ir/sharp.php a
> logical "1" should be 2ms in total length and "0" should be 1ms in total
> length. If I use ir-ctl to measure the raw values from my remote I can
> confirm this timing (also confirmed using my ocilloscope). If I try to
> transmit using this command "ir-ctl -d /dev/lirc0 -S sharp:0x2e1" and view
> the results on my oscilloscope I'm seeing 2.3ms and 1.3ms instead of the
> expected 2ms and 1ms. Not 100% sure where this code is hiding but I found a
> couple places on github that relate to this timing issue...
> 
> This is the code I found in the Linux kernel
> https://github.com/torvalds/linux/blob/master/drivers/media/rc/ir-sharp-decoder.c#L17-L18
> sharp_unit = 40
> 40 * 8 = 320 for the pulse is correct. But then the space is either 40 * 50
> = 2,000 or 40 * 25 = 1,000  which I believe should be 40 * (50-8) = 1,680
> and 40 * (25-8) = 680 to account for the initial bit pulse.

You're right, there is a problem here. 

I've submitted a patch:

https://patchwork.linuxtv.org/project/linux-media/patch/202...@me.../

> This is the code I could find for ir-ctl...
> https://github.com/cz172638/v4l-utils/blob/master/utils/ir-ctl/ir-encode.c#L149-L151
> It has a similar problem, it doesn't appear to be taking into account the
> initial bit pulse into the timing.

Looks like it has exactly the same problem, am I mistaken?

I'll write a patch for ir-ctl too.

Thanks for reporting.

Sean

Sharp send timing

[Joe F. <joe...@gm...>]

The Sharp remote send timing appears to be off from what I can track down.
I started investigating this because my Denon receiver I'm trying to send
commands to appears to be more sensitive to IR command timing and doesn't
always response where as my other devices appear to work just fine using
LIRC.

According to this page https://www.sbprojects.net/knowledge/ir/sharp.php a
logical "1" should be 2ms in total length and "0" should be 1ms in total
length. If I use ir-ctl to measure the raw values from my remote I can
confirm this timing (also confirmed using my ocilloscope). If I try to
transmit using this command "ir-ctl -d /dev/lirc0 -S sharp:0x2e1" and view
the results on my oscilloscope I'm seeing 2.3ms and 1.3ms instead of the
expected 2ms and 1ms. Not 100% sure where this code is hiding but I found a
couple places on github that relate to this timing issue...

This is the code I found in the Linux kernel
https://github.com/torvalds/linux/blob/master/drivers/media/rc/ir-sharp-decoder.c#L17-L18
sharp_unit = 40
40 * 8 = 320 for the pulse is correct. But then the space is either 40 * 50
= 2,000 or 40 * 25 = 1,000  which I believe should be 40 * (50-8) = 1,680
and 40 * (25-8) = 680 to account for the initial bit pulse.

This is the code I could find for ir-ctl...
https://github.com/cz172638/v4l-utils/blob/master/utils/ir-ctl/ir-encode.c#L149-L151
It has a similar problem, it doesn't appear to be taking into account the
initial bit pulse into the timing.

What am I missing?