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

On 15/09/2024 12:49, Chris Elvidge wrote:

On 15/09/2024 at 11:16, The Natural Philosopher wrote:

On 14/09/2024 22:25, Chris Elvidge wrote:

On 14/09/2024 at 19:32, The Natural Philosopher wrote:

On 14/09/2024 16:38, Chris Elvidge wrote:

On 14/09/2024 at 15:37, The Natural Philosopher wrote:

On 14/09/2024 11:33, The Natural Philosopher wrote:

On 14/09/2024 08:12, Pancho wrote:

>
>

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 shit. 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

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

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 01-70bd2af7 es7
[   15.888471] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
>
That's exactly  the same as my 'working perfectly' Pi Zero 1W...
>
So its probably not that.
>
>
>

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!!
>

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?
>

>
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]

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

I think over_voltage is a red herring, it limits the CPU/GPU upper voltage doesn't set it (AFAICS).

 > https://www.raspberrypi.com/documentation/computers/config_txt.html
 >
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
--
When plunder becomes a way of life for a group of men in a society, over the course of time they create for themselves a legal system that authorizes it and a moral code that glorifies it.
  Frédéric Bastiat