IR reception degrades after a few minutes then fully stops working on irRemoteESP build (BK7238), ok on generic build

[Krazubu]

Describe the bug
IR reception works correctly at first, then progressively degrades over a few minutes (really approx 5) : correct decodes turn into "Unknown IR", and eventually IR reception stops being logged entirely. This only happens on the irRemoteESP build variant — confirmed stable across three different generic build versions with identical hardware/config

Firmware

Version: 1.18.298_irRemoteESP (degrades) — for comparison, 1.18.98, 1.18.150, and 1.18.298 generic (non-irRemoteESP) are all stable
Device: Tuya S18 WiFi IR blaster
Chip/model: BK7238 (T1-3S)
Device config: Pin 26 = IRRecv, Pin 6 = IRSend, Pin 9 = Button, Pin 24 = LED

To Reproduce

Flash OpenBK7238_1.18.298_irRemoteESP.rbl
Configure pin 26 as IRRecv, pin 6 as IRSend
Point a remote (tested with a Denon remote) at the receiver and press buttons repeatedly over a few minutes
Observe the log:
First few presses decode correctly, e.g. Info:IR:IR DENON,15,0x1B14
After a few minutes, decodes become Info:IR:Received Unknown IR
Continuing further, no IR reception is logged at all anymore, or rarely some "Unknown IR"
Reflashing with OpenBK7238_1.18.98.rbl, OpenBK7238_1.18.150.rbl, or OpenBK7238_1.18.298.rbl with the same pin config and remote: no degradation observed in any of them, decoding stays stable

Additional context
Device does not show significant heat buildup during the test, so thermal drift seems unlikely

[divadiow]

I had Codex review my attempt at updating the irremotESP version originally ported into OBK. The update to 2.9.0 was done a few months ago, but probably needed going over again. One of the things it picked up on was:

---

pre-existing OpenBeken IR defects uncovered during the review

These are present in canonical main, so they are not regressions caused by your 2.9.0 branch. They do, however, materially affect whether this port is reliable.

High, inherited — the RX ISR uses a floating-point absolute microsecond clock

The custom receive ISR maintains:

static float ir_now = 0;
static float ir_start = 0;

void IR_ISR(float period_us) {
    ir_now += period_us;
    ...
}

The hardware timer period is nominally 50 µs. The same float implementation is present in canonical main.

By binary32 arithmetic, this deteriorates rapidly as the absolute value grows:

after roughly five minutes, adding 50 µs can quantise to 64 µs steps;
that is approximately 28% timing error, already outside the normal 25% matching tolerance for many protocols;
after roughly fifteen minutes, the spacing between adjacent float values becomes large enough that adding 50 may no longer change ir_now at all.

At that point edge durations and receive timeout handling can stop working correctly.

Replace this with an integer tick counter and wrap-safe subtraction:

static uint32_t ir_now_ticks;
static uint32_t ir_edge_ticks;

const uint32_t elapsed_ticks = ir_now_ticks - ir_edge_ticks;

Since the receiver buffer already expresses durations in kRawTick units, keeping the ISR clock in ticks is simpler and faster than maintaining absolute microseconds.

---

and that fix and a host of others (see attached) are included in the latest run here: https://github.com/divadiow/OpenBK7231T_App/actions/runs/29897401798

I have not tested/proved any of these things though.

OpenBeken_IRremoteESP8266_2.9.0_fix_summary.txt

[btastic]

I am working on a hobby project which is way out of my usual coding realm, thus I used a lot of Claude, and it helped me write this comment too. So if anything reads very AI'ish, thats because AI helped me, because - like I said - this is somewhat out of what I am usually coding, and for me it is just a hobby project, but Claude said it would be worth sharing it here.

// Claude comment starts

---

I hit this independently on the same variant and chip (BK7238, irRemoteESP) and arrived at the same conclusion as @divadiow . Since the diagnosis here is stated as untested, here are exact numbers and a way to prove it on a device.

The clock steps

ir_now is a float, monotonically accumulating, so precision is lost in bands. Every time it crosses a power of two the ULP doubles and += 50.0f rounds to a different multiple. The effective tick size jumps:

ir_now band	ULP	a 50 µs tick becomes	error	reached at
[2^24, 2^25)	2	50 µs	0%	0.26 min
[2^25, 2^28)	4–16	48 µs	−4%	0.54 min
[2^28, 2^29)	32	64 µs	+28%	4.64 min
[2^29, 2^30)	64	64 µs	+28%	8.13 min
[2^30, …)	128	0 µs	clock stops	15.12 min

The line that matters is 4.64 min. The effective tick does not wander — it jumps straight from −4% to +28%, which is immediately outside the library's ±25% _tolerance, so matchMark/matchSpace start failing there. That is almost certainly the "degrades over approximately 5 minutes" in the original report, and it explains why it presents as a sudden onset rather than a slow decay.

At 15.12 min ir_now freezes at exactly 1073741824.0 and never advances again: v + 50 is nearer to v than to v + 128, so the addition rounds to nothing. From then on time_since_last_change is always 0, every rawbuf entry is 0, and nothing can decode until a reboot.

Reproducible in six lines — no hardware:

#include <stdio.h>
int main(void) {
    float ir_now = 0.0f, prev;
    for (unsigned long long t = 1;; t++) {
        prev = ir_now; ir_now += 50.0f;            // as in IR_ISR()
        if (ir_now == prev) {
            printf("stalled at %.2f min, ir_now=%.1f\n", t*50.0/6e7, (double)ir_now);
            return 0;                              // stalled at 15.12 min, ir_now=1073741824.0
        }
    }
}

How to confirm it on a device

The stall value is fixed and recognisable, which makes this directly observable rather than inferred. 1073741824 µs is 1073741 ms, so exposing the ISR clock and watching it freeze at that number is proof:

extern "C" uint32_t IR_GetNowUs(void) { return ir_now; }

Print it alongside a decode. If it climbs normally, stops at 1073741 ms, and reception dies at the same moment, that is the mechanism confirmed. If reception dies while the counter keeps climbing, it is something else. I have this wired into a local build behind a debug command but have not yet been able to run the long-uptime test on hardware, so I am offering it as a method, not a result.

Note the thresholds are relative to when the IR driver starts, not device uptime — which is also why a reboot appears to fix it.

On the fix

@divadiow's tick-counter approach looks right to me, and better than what I did locally (integer microseconds with a 1/256 µs fractional carry): counting ticks converts once per edge instead of doing arithmetic on every one of ~20,000 ticks per second.

One thing worth a comment in the code if you take that route: nothing resets ir_edge_ticks between transmissions, so after a few minutes of no IR the ir_now_ticks - ir_edge_ticks difference gets large, and if it is later multiplied by a period to get microseconds that product can overflow a uint32_t. It happens to be harmless today — the kIdleState branch writes a literal 1 into rawbuf and the timeout check short-circuits on params.rawlen — but it is the kind of thing a later "simplification" of those guards would silently turn into a bug.

Unrelated, but adjacent

Separate from the clock, decode() is called with the default max_skip = 0, so the loop in IRrecv::decode only ever attempts offset kStartOffset. Coolix and friends transmit the message twice; if a single pulse in the first copy is out of tolerance the whole capture is discarded even though an intact second copy is sitting in rawbuf. I have a raw-timing capture where copy 1 has one mark at 350 µs (vs 552 + kMarkExcess, i.e. −42%) and copy 2 is clean at −18% worst case, decoding as UNKNOWN. Happy to open that as its own issue if useful — it causes failures even well inside the healthy window, so it may be muddying reports like this one.

// Claude comment ends

---

Like I said, I hope it is fine that I report what claude found. After it fixed it, in a very similar way to what @divadiow did, the clock kept advancing properly, and I never hit an issue with IR reception degradation. So I hope this helps somehow, but like I said, this is a bit out of my realm to what I usually code, and just a hobby project.

Best regards
Ben

[divadiow]

interesting, thank you. admittedly, I don't fully understand it all but the gist is obvious. I've continued development with Codex and will feed it your Claude feedback.

Ensuring nothing else breaks unrelated to irremoteesp tweaks is key for the project though, otherwise it may never see a merge into upstream main. :)

[JoseStud]

Hit what might be a related issue on the same exact hardware/build combo — wanted to share in case it's useful diagnostic data, even though the specific symptom differs a bit from the original report.

Hardware: Tuya S18 WiFi IR blaster, chip BK7238 (T1-3S), pins configured per this thread's earlier post (P6=IRSend, P26=IRRecv, P9=dInput, P24=WifiLED).
Firmware: 1.18.299_irRemoteESP

Symptom: IR transmit never works, from the very first attempt — not a degradation over time like the RX issue described above. IRSend NEC <addr> <cmd> always logs a clean success (enableIROut 38000 freq 33 duty, IR send NEC protocol 3 addr ... cmd ... repeats N, OK), and the IR LED visibly flashes (confirmed via phone camera), but the target device never receives it.

What we verified/ruled out:

• Code correctness: cross-validated the test code (NEC 0x20DF 0x10EF, a standard LG TV toggle) against ~15 independent sources (Tasmota reference, community gists, Flipper-IRDB entries spanning a dozen+ LG TV models old to new) — all mathematically identical once you account for notation differences (8-bit address+complement vs 16-bit extended address). Also tried the discrete Power On/Off/Standby variants.
• Positioning/range: this is the part that might be useful methodologically — the target TV has webOS homebrew root access, so we could SSH in and read the raw kernel input event device (/dev/input/event1, "LGE RCU") directly while firing sends from the blaster. Zero events reached the kernel input layer at any distance, including point-blank (a few cm). This is a much more definitive test than "did anything visibly happen" and might be worth using for anyone debugging TX reliability against a target that has similar debug access (webOS homebrew, Android TV ADB, etc.).
• Polarity: tried IREnable invert 1 — no change.
• PWM clock assumption: traced HAL_PIN_PWM_Start/HAL_PIN_PWM_Update in hal_pins_bk7231.c down through BkDriverPwm.c into pwm_bk7231n.c's pwm_init_param() — the 26MHz clock reference appears consistent at every layer for the BK7238 code path, so this doesn't look like an obvious clock-mismatch bug on inspection (though we didn't verify with a scope on the actual pin).
• Repeats: tried explicit repeat counts (3, 5) — no change.

Also tried: reflashing OTA with the generic (non-irRemoteESP) build to see if that resolves TX, per this issue's finding that generic builds are stable. The OTA write itself completes cleanly (close OTA, addr 0x1ad400, no errors, ota counter increments), but the running firmware version never actually changes after reboot — we suspect the stock Tuya bootloader (never replaced, since we only ever wrote the app partition via UART) uses its own validation against the diff2ya dynamic-OTA metadata partition documented for this board, which OpenBeken's OTA writer doesn't seem to interact with, so it silently keeps booting the old image. Haven't yet confirmed whether the generic build actually fixes TX, since we'd need to go back to UART flashing to force it — will report back if we do.

Happy to provide more logs/detail if useful, or test anything specific given we have full UART + OTA + TV-side kernel-capture verification set up on this exact unit right now.

[JoseStud]

Hit what might be a related issue on the same exact hardware/build combo — wanted to share in case it's useful diagnostic data, even though the specific symptom differs a bit from the original report.

Hardware: Tuya S18 WiFi IR blaster, chip BK7238 (T1-3S), pins configured per this thread's earlier post (P6=IRSend, P26=IRRecv, P9=dInput, P24=WifiLED).
Firmware: 1.18.299_irRemoteESP

Symptom: IR transmit never works, from the very first attempt — not a degradation over time like the RX issue described above. IRSend NEC <addr> <cmd> always logs a clean success (enableIROut 38000 freq 33 duty, IR send NEC protocol 3 addr ... cmd ... repeats N, OK), and the IR LED visibly flashes (confirmed via phone camera), but the target device never receives it.

What we verified/ruled out:

• Code correctness: cross-validated the test code (NEC 0x20DF 0x10EF, a standard LG TV toggle) against ~15 independent sources (Tasmota reference, community gists, Flipper-IRDB entries spanning a dozen+ LG TV models old to new) — all mathematically identical once you account for notation differences (8-bit address+complement vs 16-bit extended address). Also tried the discrete Power On/Off/Standby variants.
• Positioning/range: this is the part that might be useful methodologically — the target TV has webOS homebrew root access, so we could SSH in and read the raw kernel input event device (/dev/input/event1, "LGE RCU") directly while firing sends from the blaster. Zero events reached the kernel input layer at any distance, including point-blank (a few cm). This is a much more definitive test than "did anything visibly happen" and might be worth using for anyone debugging TX reliability against a target that has similar debug access (webOS homebrew, Android TV ADB, etc.).
• Polarity: tried IREnable invert 1 — no change.
• PWM clock assumption: traced HAL_PIN_PWM_Start/HAL_PIN_PWM_Update in hal_pins_bk7231.c down through BkDriverPwm.c into pwm_bk7231n.c's pwm_init_param() — the 26MHz clock reference appears consistent at every layer for the BK7238 code path, so this doesn't look like an obvious clock-mismatch bug on inspection (though we didn't verify with a scope on the actual pin).
• Repeats: tried explicit repeat counts (3, 5) — no change.

Also tried: reflashing OTA with the generic (non-irRemoteESP) build to see if that resolves TX, per this issue's finding that generic builds are stable. The OTA write itself completes cleanly (close OTA, addr 0x1ad400, no errors, ota counter increments), but the running firmware version never actually changes after reboot — we suspect the stock Tuya bootloader (never replaced, since we only ever wrote the app partition via UART) uses its own validation against the diff2ya dynamic-OTA metadata partition documented for this board, which OpenBeken's OTA writer doesn't seem to interact with, so it silently keeps booting the old image. Haven't yet confirmed whether the generic build actually fixes TX, since we'd need to go back to UART flashing to force it — will report back if we do.

Happy to provide more logs/detail if useful, or test anything specific given we have full UART + OTA + TV-side kernel-capture verification set up on this exact unit right now.

[divadiow]

we suspect the stock Tuya bootloader (never replaced, since we only ever wrote the app partition via UART) uses its own validation against the diff2ya dynamic-OTA metadata partition documented for this board, which OpenBeken's OTA writer doesn't seem to interact with, so it silently keeps booting the old image

indeed, OpenBK7238 ota requires the bootloader be replaced by the one in the OBK QIO.

tagging @DeDaMrAzR as he's working on some ir timings stuff at the moment

[DeDaMrAzR]

BK7238 IR inspection is next on the list, BK7231N is being done as IR revisit required more time than I thought at first. Initial tests are rather promising so I don't expect much difference for 7238 integration. Stay tuned I guess.

[divadiow]

Give the latest build from this PR a go #2194

Please post feedback in that pr