| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 42 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:24:55 |
| Calls: | 220 |
| Calls today: | 1 |
| Files: | 824 |
| Messages: | 121,522 |
| Posted today: | 6 |
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:Apparently there are two possible chips. Broadcomm and symantec
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.Well another day of configgling
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.
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?).
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.0Disabled that baby straight off.
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!!
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...
On 15/09/2024 at 11:16, The Natural Philosopher wrote:
On 14/09/2024 22:25, Chris Elvidge wrote:Perhaps you could use vcgencmd to look at/monitor various internals.
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:Apparently there are two possible chips. Broadcomm and symantec
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 monitorWell another day of configgling
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.
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?).
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.0Disabled that baby straight off.
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!!
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...
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).
https://www.raspberrypi.com/documentation/computers/config_txt.html
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:Perhaps you could use vcgencmd to look at/monitor various internals.
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:Apparently there are two possible chips. Broadcomm and symantec
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.Well another day of configgling
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.
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?).
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.0Disabled that baby straight off.
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!!
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...
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
transgendered
On 15/09/2024 at 14:21, The Natural Philosopher wrote:
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:Perhaps you could use vcgencmd to look at/monitor various internals.
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:Apparently there are two possible chips. Broadcomm and symantec
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.Well another day of configgling
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.
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?).
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.0Disabled that baby straight off.
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!!
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...
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
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.
On Sun, 2024-09-15 at 11:16 +0100, The Natural Philosopher wrote:
transgendered
Not funny.
Besides, in English objects do not have a sexual identity.
On Sun, 2024-09-15 at 11:16 +0100, The Natural Philosopher wrote:
transgendered
Not funny.
Besides, in English objects do not have a sexual identity.
On Sun, 2024-09-15 at 11:16 +0100, The Natural Philosopher wrote:
transgendered
Not funny.
Besides, in English objects do not have a sexual identity.
On 14/09/2024 19:32, The Natural Philosopher wrote:
[ 15.888471] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save
enabled
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
On 17/09/2024 10:37, The Natural Philosopher wrote:
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 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.
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.
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.
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.
You might guess I recommend not scrimping on the access point either.
But I now have a microwave with a burnt out magnetron to fix...
Not related to the Z2W I hope!
Yesterday I brought up a brand new Pi Zero 2 W and after a bit, it was
all hunky dory.
Sometime last might, it went offline. No route to host.
I rebooted it and it lasted half an hour. Then it wouldn't reboot at
all. Its now sitting next to the wifi router is configured for and is
for now accessible.
I have no HDMI adapter for it., Its headless and normally accessible via
ssh.
On 9/13/24 14:34, The Natural Philosopher wrote:
Yesterday I brought up a brand new Pi Zero 2 W and after a bit, it was
all hunky dory.
Sometime last might, it went offline. No route to host.
I rebooted it and it lasted half an hour. Then it wouldn't reboot at
all. Its now sitting next to the wifi router is configured for and is
for now accessible.
I have no HDMI adapter for it., Its headless and normally accessible
via ssh.
Maybe a Serial Console would help?
<https://www.ebay.co.uk/itm/254214795077?>
Reading logs is one thing, but immediately being able to test a
hypothesis is much better.