My question isn't about the fault, its about how to find it.

Maybe a Serial Console would help?

Reading logs is one thing, but immediately being able to test a hypothesis is much better.

Prolly easier to get an HDMI and USB adapter and pop a monitor and keyboard on it. I spent hours yesterday googling for PI ZERO 2 W WIFI DISCONNECTS and everybody has the same problem. Must be 1000 posts out there. It seems that the 2W is basically a piece of s*it. People try SD cards that work perfectly in the Zero W, but don't work in the 2W.

I tried every methodology suggested, and its still doing it.

I am tempted to buy the old version, two of which have been faultlessly connected to the same wifi point for several years....

Unfortunately I soldered a header block to this one so I can't return it. Bin job probably.

Well another day of configgling

Tried to make it talk to a different wifi point. Bricked it. Reinstalled OS lite and started setting up. (again!)

The Pi ZERO 2W apparently uses a different wifi chip - SYMANTEC SYN43436, not the old BROADCOMM BCM43438

There is scuttlebutt that this doesn't play nice with some older wifi points, hence using a different one

Well, we will see.

Where did you get this info? On mine module cfg80211 is loaded by brcmfmac (broadcom?).

Model : Raspberry Pi Zero 2 W Rev 1.0 Revision : 902120 Raspberry Pi OS (bookworm, full); kernel 6.6.47+rpt-rpi-v8

No problems with wifi over the last few weeks. Wavlink M30HG4.V5030.191116

Now bluetooth, there's a whole nother story!!

Broadcom sold their wireless division to Cypress, and subsequently it went to Synaptics[1]. There may be slightly variations between the different part numbers but I'd not expect huge differences. There could be bugs, of course.

(Broadcom like putting the same silicon in different parts with different options, like the BCM2835 in Pi1 is actually the BCM2708 silicon inside)

There could be firmware differences or something, I suppose.

Theo

Apparently there are two possible chips. Broadcomm and symantec I THINK I have the broadcomm

dmesg | grep brcmfmac [ 12.461334] brcmfmac: F1 signature read @0x18000000=0x1541a9a6 [ 12.467893] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1 [ 12.468806] usbcore: registered new interface driver brcmfmac [ 12.731339] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2) [ 12.732079] brcmfmac: brcmf_c_preinit_dcmds: Firmware: * BCM43430/1* wl0: Jun 14 2023 07:27:45 version 7.45.96.s1 (gf031a129) FWID

That's exactly the same as my 'working perfectly' Pi Zero 1W...

So its probably not that.

Disabled that baby straight off.

Its very strange.

Its 64 bit instead of 32 bit.

But that's all that seems radically different hardware wise.

Again some rumours are that the zero 2 being power hungry may be loading the PSU more.

But in the middle of the night? Doing NOTHING?

Weird. I thought broadcomm majored in wifi chips, so what else do they do?

I started with 32bit lite but swapped to 64bit full just to see what happened. I had had no problems with 32bit lite (except bluetooth, see above). However I haven't stopped bluetooth, just don't (as yet) use it. My dmesg looks much the same as yours.

I feed mine from a 2.4 amp source. But I also have USB3 hub + ethernet port feeding 256Gb SSD and USB speaker.

Mmm. I was feeding mine, on the basis that it was drawing less than half an amp, from a very small PSU I normally use for Pi Picos.

I swapped that for a generic phone charger PSU and added a line that someone suggested to config.txt:

over_voltage=2

Its been stable doing an rsync backup of itself overnight, and is still up this morning.

Power saving is in fact on, on the wifi interface.

Journalctl reveals no entries to do with wifi AT ALL since 8 o clock yesterday evening when it was rebooted.

I think the key was in realising that on mine at least the wifi hardware was the same as on the 32 bit zeros.

So if they connected to my old POS Netgear ex ADSL router transgendered into a wifi access point, so should this one.

I will probably try reverting to the PICO power supply and see if that makes any difference.

And get a voltmeter or scope on the supply rails.

Maybe there is trash...

Perhaps you could use vcgencmd to look at/monitor various internals. E.g. vcgencmd [measure_temp|measure_clock core|measure_volts] I think over_voltage is a red herring, it limits the CPU/GPU upper voltage doesn't set it (AFAICS).

Oh I have checked all those. Only difference was temp went up from 45°C to 48°C with power saving off.

measure volts says 1.325.

Clock is 250000000

Mmm. Well I am in the process of trying to eliminate stuff that doesn't make any difference.

I agree that that documentation implies it is a bit of irrelevant nonsense. ;-)

If the thing stays stable, I'll reboot with that removed and see if it is then simply the power supply that made the difference.

Its odd, because I cant at a brief glance at the (limited) schematic, see anything that uses raw 5V, but the schematics omit the wireless chip and symantec and broadcomm do not publish specs.

The Pi PICO doesnt care if you go down much lower than 5V. I think it will run of 3.3v

Hey ho. Back to theorise and test, with as usual no hard information.

Mmm. It hasn't crashed, but the messages about reconnecting every few minutes and taking too long reappeared after about an hour totally idle.

I wonder if disabling power management would sort that out.

Well now it's disabled. Let's see.

The official PSU specification calls for 2.5A although the board only takes 300mA. My mini PSUs were only an Amp.

Maybe reconnecting wifi from power saving needs a lot of instantaneous power? Third party tests suggest up to half an amp.

Should be OK on a 1A supply, but is that a "Chinese" 1 A?

Tests continue

Best of luck. I've just looked and power management is on on both a PiZ2W and one Pi3B+ with no disconnects. Also 'thin' power transfer cores in the USB power cable could be a problem.

Well. power saving didn't cause a problem per se, but it got rid of some warnings when I turned it off.

Today's hypothesis is that power saving causes the wifi to [partially?] disconnect and that the reconnection process with a flaky chinesium PSU was simply too much current draw for the PSU, but it does reliably reconnect with the slightly better PSU. Eventually. With warnings.

Without power saving it never has to reconnect anyway. So no warnings...

Its been idle for a few hours today and is still online to the access point that was flakey as hell before, so there is a strong suspicion that I have arrived at an OK setup for now, at least.

The key would seem to be a bigger PSU.

More bits have arrived from amazon, so I will hope its stable, connect up the rest of the hardware and start to build the software underneath.

Keep me off the streets for a few days.

I probably ought to get more USB supplies. I am alarmingly short of them. The mobile phone plugs into a computer USB port....

I think the key message is that the 2W is a more hungry beast than the old Zero W, and that bookworms default 'power management on' state is probably not ideal.

Not funny.

Besides, in English objects do not have a sexual identity.

Many connectors do - back in the days when I dealt with RS-232 a lot I carried a kit of handy tools among them two varieties of gender benders. They had a different name in the Black Box catalogue but that's what everyone called them.

Oh sorry, I didn't realise you were so sensitive a little flower.

Of course they do. That's what the arguments are all about.

You may find it is slightly more reliable with power saving disabled.

To disable temporarily use:-

sudo /sbin/iw dev wlan0 set power_save off

To make persistent create a file called /etc/udev/rules.d/71-wifi_power_save_off.rules containing the line:-

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="brcmfmac", KERNEL=="wlan0", RUN="/sbin/iw dev wlan0 set power_save off"

---druck

I have done this. I think it is more stable. It is more appropriate in a server anyway

I used nmcli I think...yes. I have recorded everything I have done on this implementation in case I have to do it again.

sudo nmcli c modify [SSID] 802-11-wireless.powersave 2

I had to do it for the other SSID as well.

I made a decision - as with systemd,- that in NetworkManager was the 'supported' way to do stuff, I might as well [learn to] use it.

I am less interested in learning the more recondite areas of the distro, than achieving a stable platform on which to build an application.

I am not saying 'solved' BUT since using the bigger power supply, it hasn't *dropped* at all, however there are still the odd reconnects that occasionally take too long...on one wifi point. Oddly I have two now configured and after retrying the first one a few times it decided to try the one literally inches away and has been solid on that one ever since.

And interesting discovery was that the configuration of a static address applies to one SSID only - a 'connection' in Network Manager parlance - not to the *interface* wlan0..

Which is why I thought it had bricked when I changed wifi access points on the fly. The next time I did that I realised it was now back on DHCP...and was available on a different IP address...

Anyway the final conclusions seem to be :

1. The ZERO 2W is hungrier for electrons than the old ZERO W.
2. The symptoms of starvation are evident first in the WiFi hardware. The CPU and nearly everything else is fed from 3.3V, 1.8V and 1.3V downconverted supplies. No documentation showing what voltage was used by the WiFi chip exists that I could find.
3. On at least my model, whilst the name of the company may have changed, the old Broadcomm wifi chip and driver is still used.
4. Apart from having to use journalctl, it is unusually not possible to blame systemd for these issues.
5. Whilst a chinesium USB source *may* be able to deliver the quoted current, it is not necessarily able to deliver it in a noise free or voltage-retaining fashion.

I never got round to putting a meter or a scope on the thing - it's a bit awkward especially with a 'hat' on.

Interestingly the Pi PICO W uses a chip that works down to 3V.

Now I have achieved stability, the unit will go to a different location to further development where it will naturally connect to the original POS wifi point.

But I now have a microwave with a burnt out magnetron to fix...

Sigh.

The Zero W uses the same SOC as original Pi, and I ran that happily for years on a 0.7A first generation Samsung Galaxy phone charger. When we got the multicore Pi 2B it really needed a proper PSU rather than a phone charger for reliability. The Zero 2W initially used the same SOC as the 2B, then switched to the 3B's one when that was no longer available.

You can't go wrong with the official power supply, I've not had one fail yet. I've used others when I needed a longer USB cables, and have had to replace some more than once.

You might guess I recommend not scrimping on the access point either.

Not related to the Z2W I hope!

---druck