Led brightness

[jlayec]

Hello
Again thanks for this nice work.
I observe that the Ethernet led and serial led don't have the same brightness
Can we imagine changing the code to get the same brightness ?
Jerome

[jnilo1]

Hi Jerome,

The two LEDs are driven by completely different hardware, which explains the brightness difference:

• LAN LED: wired directly to the Ethernet PHY chip. It blinks on every RX/TX packet with a low drive current. There is no software control over it — the PHY handles it autonomously.

• Status LED: driven by GPIO 11 on the SoC, controlled via the Linux LED framework (/sys/class/leds/status/brightness). It is a simple digital on/off output — there is no PWM capability on this GPIO, so brightness cannot be adjusted in software.

The brightness difference is a hardware characteristic of the board design (different LEDs, different drive currents). Unfortunately there is nothing we can change in software to make them match.

[jlayec]

Hello,

Thanks for your detailed answer.
But before any upgrade of the GW with your nice hack, the 2 LED had exactly the same brightness (maximum on LAN and maximum on STATUS)
After the upgarde, the LAN is low brightness whereas the STATUS is high brightness.
I was wondering why?

Thanks in advance

Jerome

[jnilo1]

Jerome, you are right — I apologize for my initial answer. I just restored the original Lidl/Tuya firmware and confirmed that both LEDs have the same high brightness. So this is indeed a regression introduced by our custom firmware.

Here is what I know so far:

Confirmed facts:

• The LAN LED is driven by the internal Ethernet PHY, not by a GPIO. Setting GPIO 10 (LED_PORT0) to GPIO mode and writing to it has no effect on this LED.
• The switch core LED controller (LEDCR register) also has no visible effect — the PHY drives the LED independently.
• PHY register 24 affects the LED behavior (writing certain values turns it off), so the PHY LED configuration is the right area to investigate.

Working hypothesis:
The original Tuya kernel (based on the Realtek SDK) writes specific values to PHY registers during initialization that configure the LED driver for full brightness. Our custom kernel does not reproduce this PHY initialization sequence, leaving the registers at their power-on defaults — which results in a lower drive current for the LED.

I'll try to investigate the PHY register differences between the two firmwares. I'll update this thread when I have found a fix. One issue is that the "official Tuya/Lidl" source code is not available. Only a 2.6.10 Realtek version possibly close to it. There might be differences between those.

[jlayec]

Hello
Thanks for your tests. I was about to do the same :) and retest.
I will not qualify your firmware as a regression as I consider it could be a good idea to get low brightness for status LED (avoiding light a cupboard)
The good option could be to put the same brightness on the status LED managed by serialgateway.
The ultimate option could be to have a parameter for both LED

• no led at all
• limited brightness
• full brighntess

Thanks again
Jerome

[jnilo1]

Jerome, you were right — I restored the original firmware and confirmed both LEDs have the same high brightness. This was a regression in our custom firmware.

Fixed in v2.1.3 (just released). The LAN LED is now restored to full brightness, and both LEDs support a dim mode for nighttime use:

# Switch to dim
echo MODE=dim > /userdata/etc/leds.conf
/userdata/etc/init.d/S11leds start

# Switch to bright
echo MODE=bright > /userdata/etc/leds.conf
/userdata/etc/init.d/S11leds start

Upgrade with:

./flash_install_rtl8196e.sh gateway_ip

Thanks for reporting — this led to a deep investigation into the hardware LED architecture and a much better solution. See Release v2.1.3 for details.

[jnilo1]

For the technical details on how the LEDs work at the hardware level, see LED-DESIGN-NOTES.md.

[jlayec]

Hello
I m really impressed by the work you did : complete analysis of the situation with detailed explanations + the solution proposed.
Probably one of the best repo I'v seen.
Thanks again for this huge work.
Jerome

[jlayec]

Hello

I did additional tests

What I observed

• LAN Led is never off (but is correctly dim mode or bright mode)
• STATUS Led works correctly off / dim / bright
• but STATUS Led at startup is ON (in dim / bright mode) even if S60serialgateway not started or serial connectivity not established, ... (not tested with otbr)

Hope it can helps

Jerome

[jnilo1]

Hi Jerome,

Thanks a lot for the detailed follow-up tests — both observations are spot on. After reviewing the code, I've confirmed what's happening:

1. STATUS LED on at boot (even before serialgateway starts)

This is a bug in the S11leds init script. It currently writes the brightness value (255 or 60) directly to /sys/class/leds/status/brightness at boot, which turns the LED on immediately — regardless of whether serialgateway is running or a client is connected.

The STATUS LED is actually meant to reflect the service state, not the boot state:

• serialgateway already turns it on only when a TCP client connects (typically Z2M), and off on disconnect.
• S70otbr does the same via REST polling, lighting it up only when Thread reaches child/router/leader state.

The fix is simply to stop writing to brightness in S11leds and leave it at 0. The script only needs to set /sys/class/net/eth0/led_mode — the two services read that and apply the correct brightness themselves when they decide to turn the LED on.

2. LAN LED never fully off

This one is in the kernel driver. In rtl8196e_main.c, the led_mode=off handler only writes DIRECTLCR = 0 but leaves LEDCREG at LEDMODE_DIRECT. Depending on the controller state, this can leave a residual scan-mode glow. The fix is to also clear LEDCREG in the "off" path so the ASIC LED controller is fully disabled.

Both will be fixed in the next release — which is shaping up to be a fairly major one. I won't spoil too much, but expect a significantly newer kernel, a proper in-kernel UART driver replacing the serialgateway userspace bridge, and — if all goes well — we'll finally break past the 230400 baud ceiling that's been limiting the host-to-gateway connection. Stay tuned.

Thanks again for the careful testing — these are exactly the kind of reports that make the firmware better.

Jacques