IR receiver: decode untested with a real remote #16

New issue

Closed

opened 2026-08-27 23:22:26 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-08-27 23:22:26 +00:00

Owner

Resolved 2026-08-28 — see the new section at the end of
39-ir-and-leds.md.

It did not decode, and the cause was not the receiver. The remote was confirmed transmitting on
a phone camera; nine minutes of key presses produced 25 bytes of capture, pulses of 16-32 us
where a NEC leader is 9000 us.

The hardware was ruled in step by step:

question	answer
PL6 muxed to the CIR function?	`pin 358 (PL6): 8002000.ir … function s_cir_rx` ✓
Bank L powered?	`vcc-pl-supply = <&reg_cldo1>`, consumer present ✓
Anything driving the pin?	high 200/200 with the pull off, up AND down ✓
Does it see the remote?	5188 edges while pressing ✓

The cause was the sample clock:

r_ir_clk 0x08001454 = 0x8000000f   mux=0 (osc32k) M=15  ->  32768/16 = 2048 Hz

sunxi-cir wants 8 MHz and converts hardware sample counts to microseconds assuming its
clk_set_rate() succeeded. A mod0 factors clock only divides from whatever parent it already
has and never reparents, so the request lands ~3900x off and nothing decodes.

Writing 0x81000002 (mux=1 osc24M, M=2, so 24 MHz / 3 = 8 MHz) fixes it outright:

+9088 -4432 +544 -592 +576 -568 ... +552 -1704 +576 -1672
lirc protocol(nec): scancode = 0x1013

59 NEC frames, eleven distinct scancodes, all NEC address 0x10:
0x1000 0x1001 0x1005 0x1007 0x1013 0x101b 0x1041 0x1045 0x1046 0x1055 0x105d

⚠️ It currently needs probe/irclk.ko loaded — the device-tree fix does not take effect. Split
out as its own issue.

⚠️ Nothing has been submitted upstream. See 42-upstreaming.md.

**Resolved 2026-08-28** — see the new section at the end of [39-ir-and-leds.md](39-ir-and-leds.md). It did not decode, and the cause was not the receiver. The remote was confirmed transmitting on a phone camera; nine minutes of key presses produced 25 bytes of capture, pulses of 16-32 us where a NEC leader is **9000 us**. The hardware was ruled in step by step: | question | answer | |---|---| | PL6 muxed to the CIR function? | `pin 358 (PL6): 8002000.ir … function s_cir_rx` ✓ | | Bank L powered? | `vcc-pl-supply = <&reg_cldo1>`, consumer present ✓ | | **Anything driving the pin?** | **high 200/200 with the pull off, up AND down** ✓ | | **Does it see the remote?** | **5188 edges** while pressing ✓ | The cause was the sample clock: ``` r_ir_clk 0x08001454 = 0x8000000f mux=0 (osc32k) M=15 -> 32768/16 = 2048 Hz ``` `sunxi-cir` wants 8 MHz and converts hardware sample counts to microseconds assuming its `clk_set_rate()` succeeded. A mod0 factors clock only divides from whatever parent it already has and never reparents, so the request lands ~3900x off and nothing decodes. Writing `0x81000002` (mux=1 osc24M, M=2, so 24 MHz / 3 = 8 MHz) fixes it outright: ``` +9088 -4432 +544 -592 +576 -568 ... +552 -1704 +576 -1672 lirc protocol(nec): scancode = 0x1013 ``` **59 NEC frames, eleven distinct scancodes**, all NEC address `0x10`: `0x1000 0x1001 0x1005 0x1007 0x1013 0x101b 0x1041 0x1045 0x1046 0x1055 0x105d` ⚠️ It currently needs `probe/irclk.ko` loaded — the device-tree fix does not take effect. Split out as its own issue. --- ⚠️ **Nothing has been submitted upstream.** See [42-upstreaming.md](42-upstreaming.md).

tiagoagueda

2026-08-27 23:22:26 +00:00