I haven’t had any xruns with overclocking off, so in my case I may not need it. However, I am using zynthian as a sound module and effects processor - I don’t do any sequencing. I do push pianoteq pretty hard though.
I did go through a bunch of the pre loaded snapshots and played them with zynpad and everything was fine.
If there’s any testing I can help with since we know mine is “one of those” just let me know. I was planning on replacing the pi5 in it but I probably won’t as its been so solid now, and I don’t want to risk breaking the cables or my exquisite thermal pad work.
Unfortunately, I didn’t take any. It was sort of like when people see a bigfoot, and when asked why they didn’t take a picture, they say they were too overwhelmed and forgot all about their camera.
Would you please send the output of the command cat /proc/cpuinfo which may provide some info on different RPi5 versions? Anyone else can also provide this info and tell us whether they experience this issue or not.
I setup a recent Oram version with WIFI, used it in studio for a week, went on a gig → ERROR! Why? It insisted on connecting to my home WIFI… on the gig! Stopped me dead there. Luckily I had a backup keyboard, but all my presets for the show were unavailable.
Since it is a full Z5.1 kit with onboard screen, I surmise you don’t need headless functionality with VNC external control, therefore I don’t recommend bringing your Zynth to a gig with the WiFi activated, which also entails a bit of CPU usage.
It should be ideally switched-off, whenever you carry it around for performance purposes, unless you want to control it from a smartphone or tablet through VNC, but in this case you’d need to connect to a local net of WiFi service, which is not entirely handy to figure out beforehand.
The issue was pretty clear, if it expects WIFI, it won’t let you get past the splash screen and presents an arbitrary IP address on the screen. And a giant ERROR text. Its very reproducible, just set your WIFI so that it connects to your WIFI. Then turn off your router or WIFI, and reboot.
I can’t reproduce your issue. My several zynthians don’t get blocked when WIFI is not available. They simply boot without connection and no error is displayed.
Your error is probably due to some bizarre condition we need to trace-back before fixing. If you don’t give us more detailed feedback it’s quite difficult to know where the problem is…
When Wi-Fi activity blocks the Zythian, it could be caused by the power supply.
How:
Wi-Fi actively scans for AP by transmitting probe requensts, due to crappy internal antenna and surrounding electronics and enclosure does not receive an answer, ramps up power for probe request transmission, the bad atenna reflects back transmission power, power supply current increases, up to a point when Wi-FI BRCM fails with current runaway, SDIO fails and takes down the entire bus. SD card access adds up to power consumption. Ths all can easily reach several amperes, power browns out and more parts of the Pi5 starve away.
Overclocking the RPi5 mangles the power supply even more.
First remedy to try: Do not overclock the RPi5.
Second remedy to try: Use a USB Wi-Fi/BT dongle with RTL8821CU chipset. It’s driver is now in-kernel, no need to install anything. TP-Link Archer T2UB is a working example.
And again Wi-Fi…
The recent update in Vangelis brought back an old issue with onboard WLAN having lousy reliability. I run my testing Zynthian in the office as an internet-radio, so I hear instantly how bad that became.
I’ve found a remedy (apart from buying and using USB dongle… but why pay extra for something that is already paid for?).
On SSH run
update-alternatives --config cyfmac43455-sdio.bin
and select 2, cyfmac43455-sdio-standard.bin 50 manual mode, reboot.
If that does not help, due to another possible experiment by RP, repair the firmware manually:
Are we sure we need a proprietary device driver for the WiFi chip and that it’s not just a misconfiguration? I notice a boot warning about the region not set for WiFi which would likely mean suboptimal performance in some regions. I’ve not had the time nor inclination to investigate as my WiFi tends to work over the couple of meters to the access point in my studio.
Normally, the Wi-Fi full (!) stack for CYP/BRCM would do passive scanning and try to connect and set the reg_domain according AP specs. For Germany, as an example, it could make sense to run (as root):
raspi-config nonint do_change_timezone Europe/Berlin
raspi-config nonint do_wifi_country DE
wich allows active scanning (after reboot), but does not override the AP region and scan mode for that connection if already established.
Any existing WLAN connection would have to be deleted and reconfigured to take up active scanning.
Disregard previous version of this post.
The only remedy to improve Wi-Fi on ANY Raspberry Pi is to use an external USB WLAN device like Archer T2UB that has in-kernel driver support.
