Hi,
Here’s another beta build:
- hopefully fix the LED now, also on the Pi 5
- fix regression on maximum sample rate on HAT’s
- improve wireless network scanning
- ongoing improvements to USB DAC ‘locked by’ status
- introduce wifi watchdog
Thanks
4 Likes
HI Harry,
I just installed the new RoPieee (3 * RPI3B with display to Build 6340 and 2 * RPI4B with USB-DACs connected to Build 3642).
On all those RPIs, the Red LED is still on, even after I toggled the settings “LEDs Function” away and back to “Both LEDs Off”. So this detail isn’t fixed yet on RPI3B and RPI4B.
For the rest, all seems to work as before.
Kind regards, Frank.
Are you sure? I’ve got a Pi 3B here where this works.
You need to reboot before it works…
@spockfish
Hi Harry,
Yesterday, before I posted, I did several reboots as I changed the settings of "LEDs Function:”, which results automatically in a reboot. That didn’t help.
This moning I disconnected the power of a RPI3B, after which I reconnected the power. But also that didn’t turn off the Red LED, althought the setting is ”Both LEDs Off”.
This happens on all my RPI3Bs and RPI4Bs. I do not have a RPI5 with RoPieee in service, so that I haven’t tested.
Feedback: 7b734c842ca6c053
Kind regards, Frank.
On RPI5+Display2, installation went well.
Green light blinking happily again.
Log 561b3ad2b43e4268
Thanks for your support.
@spockfish
Hi Harry,
As a test, I went to the “Stable channel” (2026.04.1 Build 3547), and then the red LED was off. I then returned to the “Beta channel” (2026.05 Build 3640), and the red LED is again permanently on. So for me the issue persists.
Do you have any idea what I can test furthermore?
Kind regards, Frank.
No, I already found what the issue was. Thanks.
1 Like
Jussi has just released a new version of NAA with version 6.12.
1 Like
Hey Harry, I think I’ve found a fairly major bug in the beta (from the inherited kernel rather than ropieee itself). I’ve already mentioned it in the other chat but since it’s beta specific I thought I’d better mention it here. I’ve tried turning off EEE and am monitoring to see if it solves my crashing.
-
Kernel Panic in `bcmgenet` Driver — Regression in `linux-rpi 6.18.20-1` · Issue #7304 · raspberrypi/linux (and the related Arch Linux ARM • View topic - Kernel 6.18.20-1 breaks networking)
-
Kernel 6.15+ may have network connectivity issues on the Pi4/CM4 · Issue #7024 · raspberrypi/linux
(and yes, I’m aware of the irony that in trying to investigate my other issue you pushed a kernel update, and now that has broken more things 
)
I would formulize it differently: I’m not convinced this is actually happening. First of all, I’m using this kernel on Pi’s for more then a month, without any issue. And furthermore, the Pi foundation is about to upgrade their distro with this kernel as well (I just ‘follow’ here). I’m pretty sure they are not going to do that if they think that there’s a big issue. The ticket also shows how difficult it is to reproduce…
Again, it could be that you run into this issue, but first we need to see if we can actually gather evidence. The scheduled reboot might help, assuming that the kernel isn’t completely gone (which I think, otherwise the screen app would crash also)
I’m following this ticket: Kernel Panic in `bcmgenet` Driver — Regression in `linux-rpi 6.18.20-1` · Issue #7304 · raspberrypi/linux · GitHub
In the mean time I will build a beta build with EEE disabled, because it’s mentioned a few times. So let’s rule it out on our side…
Oh! Another idea: enable wireless as well. RoPieee will setup 2 connections, and that would mean if your wired connection stops functioning, you would still be able to reach the unit.
Thanks
Great idea, I’ll try that. I’m not sure if it will be reachable (since the screen crashes at the same time) but important to test (if my unit crashes again with EEE disabled)
*edit. Just seen your other message that the screen freezing doesn’t imply a kernel crash so I may be wrong in that assumption.