Pi 4 4GB- Wifi not working when resolution is set too high

[RasPiFanFromFRG]

Good afternoon.

I'm watching this phenomen after reading about it in a German IT magazine today.
Well, my performance without a problem on a Raspi 4B looks like this:

1. I baught a high quality HDMI cable plus a power supply from an electronic reseller store here who offers the original Raspian products
2. Than I always changing my monitor resolution to DMT standard with 1920 x 1080 @ 60 Hz 16:9 widescreen mode
3. As you can see I don't use the prebuild GPU automode plus it's not recommended to use industrial CEA TV output standard instead DMT TFT computer monitor output. You will enjoy a crystal clear desktop
4. I use the µHDMI output 1 instead 0 on my Raspi. Yes the µHDMI output connector no. 0 is to close at the power input chip set region. I noticed the signal is growing one line
5. The location of my WLAN Router Fritz.Box 7490 (manufactured by AVM in Berlin) with 2.4 & 5.0 GHz is in the kitchen, my little Raspi working in the living room. Between both are a distance of round about 49 ft each other. The antennas are nearly in one level over ground of the floor. The level of this WiFi constellation is a bit low by his signal but both frequencies working
6. A test with a RasPi 3 B and a RasPi 3 B+ doesn't show effects different

So everything looks normal and do his job.

I think it's not a big problem to solve it. First what I recommend is to ask always the user itself before call the "master". Bad equipements means bad results coming up.

Best regards.

[jamesh]

Previous Pi generations could use the

Code: Select all

config_hdmi_boost

setting in config.txt to control the HDMI "signal strength". The documentation claims that setting is ignored by the 4B, is that still the case? Has anyone tried playing with it?

Correct, hdmi boost is not implemented on the Pi4. Think its something do with the new HDMI HW not having the same scheme. Won't help in this case anyway - this seems to be a problem with a bad cable and a bad adapter with inadequate shielding, and a specific HDMI clock rate which means it's actually broadcasting on a harmonic of the 2.4G wireless out of the badly shielded cable. We are taking a closer look.

[RasPiFanFromFRG]

Previous Pi generations could use the

Code: Select all

config_hdmi_boost

setting in config.txt to control the HDMI "signal strength". The documentation claims that setting is ignored by the 4B, is that still the case? Has anyone tried playing with it?

Correct, hdmi boost is not implemented on the Pi4. Think its something do with the new HDMI HW not having the same scheme. Won't help in this case anyway - this seems to be a problem with a bad cable and a bad adapter with inadequate shielding, and a specific HDMI clock rate which means it's actually broadcasting on a harmonic of the 2.4G wireless out of the badly shielded cable. We are taking a closer look.

I share this opinion at the present.

[Diablo2_Fan]

The output of the script is (I replaced SSID and MAC address):
...

Thanks a lot. I have very similar results respectively with HDMI switched on there is no connection possible. The only difference is that I use the original micro-HDMI cable and have a DVI-adapter directly at the monitor.

1920x1080 and 5 GHz Wifi:

Code: Select all

values with enabled hdmi:

wlan0 IEEE 802.11 ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on



values with disabled hdmi:

display_power=0
wlan0 IEEE 802.11 ESSID:"myssid"
Mode:Managed Frequency:5.18 GHz Access Point: mymac
Bit Rate=121.5 Mb/s Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=46/70 Signal level=-64 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

display_power=1

[Paul Webster]

A bit surprised to see this in daily email from The Register today.

[jamesh]

A bit surprised to see this in daily email from The Register today.

Us too, yet another storm in a teacup, amplified by click bait websites.

[Aardappeltaart]

A bit surprised to see this in daily email from The Register today.

Us too, yet another storm in a teacup, amplified by click bait websites.

I'm not surprised, the problem is real.
https://www.raspberrypi.org/forums/view ... 8&t=255870

I guess there are quite a few badly shielded HMDI connectors/cables for sale. Because I think those are the main culprit, I've had that experience.

There is interference, a warning to use good quality micro HDMI cables will harm nobody and save users money and troubles.

It's less easy to buy the official HDMI cable then to buy a RPI4.

[jamesh]

The problem seems to be very very specific. You need to be using specific HDMI modes, specific Wifi channels and using bad cables. We are still looking in to mitigation to cope with these bad cables. Not easy though. Sorting out RF interference is a difficult thing, way out of my knowledge base.

[Aardappeltaart]

The problem seems to be very very specific. You need to be using specific HDMI modes, specific Wifi channels and using bad cables. We are still looking in to mitigation to cope with these bad cables. Not easy though. Sorting out RF interference is a difficult thing, way out of my knowledge base.

Mine too , but running into these troubles is quite easy with the RPI4.

Responding with: "Yes, there can be interference, just use high quality cables", is better than downplaying it, I would say. It, at least, would have saved me some headaches a week ago.

[jamesh]

The problem seems to be very very specific. You need to be using specific HDMI modes, specific Wifi channels and using bad cables. We are still looking in to mitigation to cope with these bad cables. Not easy though. Sorting out RF interference is a difficult thing, way out of my knowledge base.

Mine too , but running into these troubles is quite easy with the RPI4.

Responding with: "Yes, there can be interference, just use high quality cables", is better than downplaying it, I would say. It, at least, would have saved me some headaches a week ago.

"Yes, there can be interference, just use high quality cables" is what we have always said, I believe. Maybe not in those exact words, but certainly that is what we advise. I did some testing on this, and could not replicate any issues, because I never hit the exact combination that can cause problems. We can replicate this now with lower quality cables, and the additional information provide here and elsewhere.

[Aardappeltaart]

"Yes, there can be interference, just use high quality cables" is what we have always said, I believe. Maybe not in those exact words, but certainly that is what we advise. I did some testing on this, and could not replicate any issues, because I never hit the exact combination that can cause problems. We can replicate this now with lower quality cables, and the additional information provide here and elsewhere.

Then I missed that. And I'm afraid I'm not the only one, hence the fuss.

Most people out there I've spoken think it is a Raspberry Pi 4 problem and not a faulty HDMI cable. And I searched in the forum, before I posted my problem, I could not find the cause, nor did anybody suggested it.

A sticky forum post in Troubleshooting would have helped. I'm not sure how big the problem is, but I'm sure users run into it easily.

[jamesh]

"Yes, there can be interference, just use high quality cables" is what we have always said, I believe. Maybe not in those exact words, but certainly that is what we advise. I did some testing on this, and could not replicate any issues, because I never hit the exact combination that can cause problems. We can replicate this now with lower quality cables, and the additional information provide here and elsewhere.

Then I missed that. And I'm afraid I'm not the only one, hence the fuss.

Most people out there I've spoken think it is a Raspberry Pi 4 problem and not a faulty HDMI cable. And I searched in the forum, before I posted my problem, I could not find the cause, nor did anybody suggested it.

A sticky forum post in Troubleshooting would have helped. I'm not sure how big the problem is, but I'm sure users run into it easily.

We've always said, for years, that good cables are vital for best performance (USB and HDMI). However relating HDMI to Wifi instability has been relatively recent - once it came up here, the first advice was always ensure you have a decent HDMI cable.

There may be tweaks to get round the dodgy cable problem, we are still investigating.

As for how big it is, we've only had a few reports in, and since the particular combinations are unusual, it's not huge. 2560x1440 reduced blanking appears to be the culprit mode, combine that with a low quality cable and 2.4Ggig wireless and you *might* see a problem.

[Aardappeltaart]

As for how big it is, we've only had a few reports in, and since the particular combinations are unusual, it's not huge. 2560x1440 reduced blanking appears to be the culprit mode, combine that with a low quality cable and 2.4Ggig wireless and you *might* see a problem.

I had it with TV-Hat and 1920x1080 HEVC 50FPS.

[globiboulga666]

On a desktop computer, using DVI Digital cable, when the resolution was 1920x1080 60 Hz then I was unable to make phone calls while close of the computer (terrible reception). My brother came with radio receivers (kind of talkie walkies) and noticed a lot of perturbations appeared as soon as the display switched full resolution

So this is half surprising to see troubles with video signal cables on Pi4 too, even if the consequences here, is limited to the Pi4 WiFi module

Best first solution seems to be some notice about known cases of WiFi and RF interferences using HDMI adapters or low quality cables.
Enforcing the futures Pi4 to be stronger against those interferences would be nice, of course, but may be difficult on already manufactured models

[jamesh]

As for how big it is, we've only had a few reports in, and since the particular combinations are unusual, it's not huge. 2560x1440 reduced blanking appears to be the culprit mode, combine that with a low quality cable and 2.4Ggig wireless and you *might* see a problem.

I had it with TV-Hat and 1920x1080 HEVC 50FPS.

I suspect that is an entirely different issue, but perhaps a similar cause. 1080p cannot cause the RF problem with the Wifi that we are seeing here.

Can you describe your exact process for making it fail?

Edit: We would need output from xrandr and iwconfig to be able to test here, but initial thoughts from HW guys is that this is not the same issue.

[jamesh]

On a desktop computer, using DVI Digital cable, when the resolution was 1920x1080 60 Hz then I was unable to make phone calls while close of the computer (terrible reception). My brother came with radio receivers (kind of talkie walkies) and noticed a lot of perturbations appeared as soon as the display switched full resolution

So this is half surprising to see troubles with video signal cables on Pi4 too, even if the consequences here, is limited to the Pi4 WiFi module

Best first solution seems to be some notice about known cases of WiFi and RF interferences using HDMI adapters or low quality cables.
Enforcing the futures Pi4 to be stronger against those interferences would be nice, of course, but may be difficult on already manufactured models

I cannot comment on some random desktop, which appears to be radiating at some very bizarre frequencies. So far we are pretty sure this isn't a Pi HW issue, but to do with bad cables and very specific HD resolutions.

[globiboulga666]

Yes my point was just : you aren't alone, this problem also exists outside of the Pi 4 world.

[jamesh]

Indeed.

Anyway, to help us out, I wonder if anyone who is seeing this issue (or I guess any issue where wifi disappears for no apparent reason), can they provide the following information in this thread.

Monitor being used.
Resolution being used.
EDID as supplied by the monitor (`tvservice -d edid.bin` then `base64 edid.bin`, then cut and paste the result to here)
`vcgencmd version`

Thanks.

[globiboulga666]

In order to give some help, tried, and successfully reproduced the issue on Pi4 using HDMI 0 :

Monitor is : Samsung S22D300 - plugged on HDMI 0, nothing about config.txt (standard settings)
Using resolution 832x624 at 74.55 Hz, no more WiFi (transferts suddenly stops and if booting, WiFi hotspot is visible but cannot connect)

edid.bin:

Code: Select all

pi@Pi4-Crobe-PiCraft:~/Desktop $ tvservice -d edid.bin
Written 256 bytes to edid.bin
pi@Pi4-Crobe-PiCraft:~/Desktop $ base64 edid.bin
AP///////wBMLT8LSDhaWjIYAQOAMBt4KpVhpVVSoCgPUFS/74BxT4HAgQCBgJUAqcCzAAEBAjqA
GHE4LUBYLEUA3QwRAAAeAR0AclHQHiBuKFUA3QwRAAAeAAAA/QAySx5REQAKICAgICAgAAAA/ABT
MjJEMzAwCiAgICAgAX0CAxGxRpAEHxMSA2UDDAAQAAEdALxS0B4guChVQN0MEQAAHowK0JAgQDEg
DEBVAN0MEQAAGIwK0Iog4C0QED6WAN0MEQAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUA==

vcgencmd version :

Code: Select all

pi@Pi4-Crobe-PiCraft:~/Desktop $ vcgencmd version
Sep 24 2019 17:34:30 
Copyright (c) 2012 Broadcom
version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (clean) (release) (start)

WiFi Channel 13

Used arandr to switch resolutions live, while WiFi transferring with iperf
Doing more tests to keep you informed

EDIT : more informations :
iwconfig before switching to the cursed resolution :

Code: Select all

pi@Pi4-Crobe-PiCraft:~ $ iwconfig 
wlan0     IEEE 802.11  ESSID:"WeeFee-2.4GHz"  
          Mode:Managed  Frequency:2.472 GHz  Access Point: 30:B5:C2:7F:46:16   
          Bit Rate=65 Mb/s   Tx-Power=31 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=54/70  Signal level=-56 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

eth0      no wireless extensions.

lo        no wireless extensions.

Right after switching :

Code: Select all

pi@Pi4-Crobe-PiCraft:~ $ iwconfig 
wlan0     IEEE 802.11  ESSID:"WeeFee-2.4GHz"  
          Mode:Managed  Frequency:2.472 GHz  Access Point: 30:B5:C2:7F:46:16   
          Bit Rate=65 Mb/s   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=54/70  Signal level=-56 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

eth0      no wireless extensions.

lo        no wireless extensions.

xrandr output :

Code: Select all

pi@Pi4-Crobe-PiCraft:~ $ xrandr 
Screen 0: minimum 320 x 200, current 832 x 624, maximum 7680 x 7680
HDMI-1 connected primary 832x624+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080     60.00 +  60.00    50.00    59.94  
   1680x1050     59.88  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x800      59.91  
   1152x864      75.00  
   1280x720      60.00    60.00    50.00    50.00    59.94  
   1024x768      75.03    70.07    60.00  
   832x624       74.55* 
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00    50.00  
   720x480       60.00    60.00    59.94    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08  

For doing the test, I used this Micro HDMI to HDMI adapter, and HDMI cable :
https://www.amazon.fr/Momorain-Adaptate ... 0817RFD69/

Tried on HDMI physical port 1 instead of 0 :
Not much better, but just a little bit better : The Pi was unable to connect until I plugged my keyboard. Started the iperf test, was performing well, until I unplugged the keyboard (the data transfer rate then almost felt to 0). Plugged and unplugged the keyboard several times : confused : sometimes it does something, sometimes not.

Trying again with a true micro HDMI to HDMI cable : same results

And then added those lines into config.txt :

Code: Select all

hdmi_edid_file=1
hdmi_edid_filename:0=edid-1920x1080.bin

Without the screen connected, I can set the cursed resolution and everyting works. But as soon as the screen is physically plugged, the WiFi goes off.
Connecting the cable alone does nothing : the cable should be connected to the Pi 4 and the screen to cut off the WiFi.

My WiFi hotspot is 20 MHz bandwidth (short GI disabled to gain some signal quality at the cost of few Mbps)
I tried to change the WiFi channel from 13 (which is 2.472 GHz, more exactly [2.462 to 2.482]) to 1 (which is 2.412 GHz more exactly [2.402 to 2.422]) but the results are exactly the same (no difference)

Power supply block is the official one.
I guess it's all for now, unless you want me to try something else

[Aardappeltaart]

Reproduced problem testing 2 cables and 2 monitors. Problem more complex than thought, because not only cable but also the monitor is causing issues. Also, counter intuitive HDM1 is worse than HDMI0 on ONE monitor.

SETUP
RPI4 2GB Official PSU
Cable (1) micro HDMI 1.4
Cable (2) micro HDMI 2.0

WIFI AP Domotica 2.4Ghz with 6 devices connected. Channel 3 and 12 tested.

USB3 SSD Crucial BX500

TV-Hat DVB-T2 1920x1080 HEVC 50fps

Living in city, so approx. 25+ WIFI 2.4Ghz and 15+ 5.0 Ghz around.
Getting a spontaneous headache reading what I just typed.

Distance RPI4 - monitor ~1.5m.

Kodi on Buster.
gpu_mem=320

vcgencmd version
Sep 24 2019 17:34:30
Copyright (c) 2012 Broadcom
version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (clean) (release) (start)


Iiyama Prolite E2208HDS (FHD)
AP///////wAmzQpWJzAAABETAQOAMBt4//////////8SUFS/74BxT4GAgY+VAJUPqUCzAAEBAjqA
GHE4LUBYLEUA3QwRAAAeAAAA/wAxMTAyODkxNzEyMzI3AAAA/QA3TB5UEQAKICAgICAgAAAA/ABQ
TEUyMjA4SERTCiAgAHo=

HDMI->DVI adapter

Somehow it needs, otherwise it will not always turn on.
hdmi_group=2
hdmi_mode=82


LG 32UK550 (4K)
AP///////wAebQZ3NqQCAAIdAQOAPCJ46j4xrlBHrCcMUFQhCABxQIGAgcCpwNHAgQABAQEBCOgA
MPJwWoCwWIoAWFQhAAAeBHQAMPJwWoCwWIoAWFQhAAAaAAAA/QA4PR6HPAAKICAgICAgAAAA/ABM
RyBIRFIgNEsKICAgAQMCAzhxTZAiIB8SAwQBYWBdXl8jCQcHbQMMABAAuDwgAGABAgNn2F3EAXiA
A+MPAAPjBcAA4wYFAQI6gBhxOC1AWCxFAFhUIQAAHlZeAKCgoClQMCA1AFhUIQAAGgAAAP8AOTAy
TlRVVzUzMTEwCgAAAAAAAAAAAAAAAAAAAAAA9A==

HDMI input
Kodi GUI set on 1920x1080 (recommended)


TESTING

HDMI0 CABLE 1

Iiyama
WIFI channel 3
AP: All devices are dropped as soon as it outputs anything to the Monitor.

WIFI channel 12
AP: A few devices are dropped when playing something.


LG32UK550
WIFI channel 12
Some devices are dropped

WIFI channel 3
All devices reconnect with ``sudo systemctl restart hostapd.service` when monitor is at sleep
Some devices are dropped when playing something.
4K seems better than FHD 1920x1080 50Hz.

HDMI0 CABLE2

Iiyama
WIFI channel 3
AP: Devices do not connect with channel 3 when screen is on
Do connect when screen is off
All devices drop when screen turns on.

WIFI channel 12
AP: Some devices drop

LG
WIFI channel 3,
AP: all devices connect and stay connected.

WIFI channel 12,
AP: all devices connect and stay connected.

LG
(with 1080 config settings)
hdmi_group=2
hdmi_mode=82
gpu_mem=320
Devices do connect with channel 3 when screen is on
BTW 4K is played at 4K, despite config.txt

Conclusion
Cable 2 is better than Cable 1


Testing HDMI1 Cable 2
Iiyama
WIFI channel 3
AP nothing connects: monitor off or on,
so it is even worse than HDMI0.
Reproduced this, after reboot.

WIFI channel 12
AP: Some devices connect, and stay connected

LG
WIFI channel 3
AP Devices do connect stay connected with channel 3, no problem here.

I also used a QHD AOC Q3279VWFD8 monitor a few weeks ago. Could not test it today, but it had broadly speaking the same problems as with the Iiyama. AP: all devices dropped.
Somehow the LG (not necessarily a better cable) makes a huge difference.

That's all for now. Done for the moment.

[JohnFluter]

As a total newbie to the Pi I may have found something that most are not aware off regarding the networking issues with the Pi 4.

I have a Pi 4 OKDO starter kit. I was keen to play with my new toy and skipped all the opportunities to install updated software. It worked without any problems. In fact, I thought the WiFi performance was really good.

After a couple of reboots and getting the resolution to match my TV (not Hi Res) I went to the terminal and did the usual update and upgrade routine.

A lot of data was downloaded (over WiFi) and at the next boot my connectivity was completely screwed up.

I have been able to return it to its previous working state only by turning off my WiFi and reinstalling the NOOB on the supplied SD card. It seems to date from July 2019.

Because there had been a connection, and it could be still made (at snail pace) this was the easy way to force the original installation. Not even an ethernet cable would speed things up. I've updated the system since (I had to accept repository changes) and all is still good. (Firefox 60 esr would not install before the update but it works fine now). I will not be upgrading any time soon. I've spent too much time with this already.

I plan to start again with another card and NOOBs with more recent dates to see if my conclusions are valid.

I see that there is a lot of noisy discussion on the WiFi starting in August. For what it is worth, and I may be completely off topic and off target, I think that something in the upgrade has caused the networking problems.

[jamesh]

If you are using 2560x1440 mode can you try `sudo rpi-update` - we've wiggled the timings a bit to see if it helps.

[hippy]

Most people out there I've spoken think it is a Raspberry Pi 4 problem and not a faulty HDMI cable.

That's probably because most people have been led to believe that expensive and so-called better HDMI cables are not necessary, are a money-taking scam; cheap cable is just fine, and in most cases it is

That, as they are now finding, isn't the full story. But it's not surprising, when they find their cable which otherwise has never caused a problem before does with a Pi 4B, that they jump to the conclusion it must be a Pi problem rather than a cable problem.

[jamesh]

Most people out there I've spoken think it is a Raspberry Pi 4 problem and not a faulty HDMI cable.

That's probably because most people have been led to believe that expensive and so-called better HDMI cables are not necessary, are a money-taking scam; cheap cable is just fine, and in most cases it is

That, as they are now finding, isn't the full story. But it's not surprising, when they find their cable which otherwise has never caused a problem before does with a Pi 4B, that they jump to the conclusion it must be a Pi problem rather than a cable problem.

We've got a pretty good handle on what is happening. We've got to run through some stuff which I won't talk about, but should be possible to mitigate. As above, rpi-update will already get you a newer firmware which may help. As will a decent cable as they definitely cause problems.

[skibum]

I thought I was going made until I came across this post.

pi4 4gb. Official power supply and hdmi cable.

Monitor is LG 43UD79 running at 4k and hdmi_enable_4p60=1

Code: Select all

pi@pi4-4:~ $ vcgencmd version
Sep 24 2019 17:34:30
Copyright (c) 2012 Broadcom
version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (clean) (release) (start)

pi@pi4-4:~ $ base64 edid.bin
AP///////wAebQhb/C4IAAkcAQOAPCJ46jA1p1VOoyYPUFQhCABxQIGAgcCpwNHAgQABAQEBCOgA
MPJwWoCwWIoAWFQhAAAeBHQAMPJwWoCwWIoAWFQhAAAaAAAA/QA4PR6HPAAKICAgICAgAAAA/ABM
RyBVbHRyYSBIRAogAdYCAy9xTJAiIAQDAgFhYF1eXyMJBwdtAwwAMAC4PCAAYAECA2fYXcQBeIAD
4w+AAQI6gBhxOC1AWCxFAFhUIQAAGlZeAKCgoClQMCA1AFhUIQAAGgAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFg==

pi@pi4-4:~ $ iwconfig
wlan0     IEEE 802.11  ESSID:"BT-C6A5X7"
          Mode:Managed  Frequency:5.18 GHz  Access Point: 4C:1B:86:B4:EF:B0
          Bit Rate=180 Mb/s   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=50/70  Signal level=-60 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:886  Invalid misc:0   Missed beacon:0

eth0      no wireless extensions.

lo        no wireless extensions.

Also another pi4 connect to the same machine. Again official power and cable. Attached to same monitor, just via a different hdmi port on the monitor.

Code: Select all

pi@pi4-4zig:~ $ vcgencmd version
Sep 24 2019 17:34:30
Copyright (c) 2012 Broadcom
version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (clean) (release) (start)

pi@pi4-4zig:~ $ base64 edid.bin
AP///////wAebQhb/C4IAAkcAQOAPCJ46jA1p1VOoyYPUFQhCABxQIGAgcCpwNHAgQABAQEBBHQA
MPJwWoCwWIoAWFQhAAAeVl4AoKCgKVAwIDUAWFQhAAAaAAAA/QA4PR6HHgAKICAgICAgAAAA/ABM
RyBVbHRyYSBIRAogAVACAxxxRZAiBAMBIwkHB20DDAAgALg8IABgAQIDAjqAGHE4LUBYLEUAWFQh
AAAeAAAA/wA4MDlOVEpKRlMzMTYKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbg==

pi@pi4-4zig:~ $ iwconfig
wlan0     IEEE 802.11  ESSID:"BT-C6A5X7"
          Mode:Managed  Frequency:2.437 GHz  Access Point: 4C:1B:86:B4:EF:B1
          Bit Rate=72.2 Mb/s   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=58/70  Signal level=-52 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:761  Invalid misc:0   Missed beacon:0

eth0      no wireless extensions.

lo        no wireless extensions.

Until recently only pi4-4 had the issue. But in the last week or so, both have now started having the issue.