Lower display brightness to probe peak-current freeze

Piotr observed the freeze correlates with digit '8' on the last
(units) tube position, regardless of which sensor is shown
(25.08 C, 48 %, 1018 hPa). '8' lights the most 14-seg segments of
any digit, and the units digit changes most often, so the last
position is both peak-current and the most-written-to. At brightness
15 (max) that peak current likely dips the supply / glitches the I2C
bus, which the in-ISR delay()/endTransmission() then turns into a
permanent hang.

This commit drops brightness 15 -> 4 as a cheap, reversible probe.
If freezes stop or get much rarer, the root cause is current/brownout
(fix: decoupling cap on display VCC, or separate supply, plus an I2C
bus-recovery/timeout) rather than purely the ISR timing.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Mateusz Kowalczyk
2026-06-10 02:13:55 +00:00
parent 0332b728e6
commit 6abd900a8f

View File

@@ -6,7 +6,11 @@ char tubeText[5] = "";
void initTube() { void initTube() {
// Wire initialized by BME280 sensor // Wire initialized by BME280 sensor
tube.setTubeType(TYPE_4, TYPE_4_DEFAULT_I2C_ADDR); tube.setTubeType(TYPE_4, TYPE_4_DEFAULT_I2C_ADDR);
tube.setBrightness(15); // Brightness drives LED current. The freeze correlates with '8' on the last
// multiplexed digit (most segments lit -> peak current) at full brightness 15,
// which points at a supply/I2C-bus glitch. Lowered to probe that hypothesis;
// raise back toward 15 if the display is too dim and freezes don't return.
tube.setBrightness(4);
tube.setBlinkRate(BLINK_OFF); tube.setBlinkRate(BLINK_OFF);
} }