RPi4 with Fan SHIM and Unicorn HAT HD drops network connection when opening Chromium

Hi, there.

I recently ordered two Raspberry Pi 4 (4 GB) boards, two fan SHIMs, an Ubercorn, and a Unicorn HAT HD. Each board has a fan SHIM, the same model of power supply and microSD card, and each has one of the HATs. Both are running Buster.

The unit with the Ubercorn works perfectly fine, but the one with the Unicorn HAT HD works (mostly) fine until I open Chromium. Upon doing so, any network activity will hang. If I close Chromium quickly enough, traffic continues, but if I leave Chromium open for more than a few seconds, network connectivity does not return. Some tampering might make it return, but I usually have to reboot it. I feel like I had tried another browser once and experienced the problem, but I couldn’t reproduce that; further testing with Firefox and Epiphany resulted in no traffic problems — only Chromium caused the network connectivity to halt.

I’ve wiped it repeatedly, installed Raspbian through different sources, but the problem continued.

I swapped the microSD card from the Ubercorn into the one with the Unicorn HAT HD, and it experienced the same problem, so at that point, I knew that it was a hardware issue.

I removed the Unicorn HAT HD, and it works with no problems when Chromium is opened. Putting the HAT back on, the problem returned.

From this, I’m not entirely sure what the issue could be. I suppose it could be a faulty Unicorn HAT HD, as I previously purchased a faulty Unicorn HAT (at least I assume that it was faulty; wasn’t able to figure out what was causing the problem), and my other Unicorn HATs HD work fine on my 3B+ units. The only thing that makes me wonder if it might be problem with the RPi4 itself is that my keyboard/mouse USB dongle doesn’t function in the bottom USB 2.0 port; other devices work in that port, and the dongle works in other ports, but just not that dongle in that port, and I have no idea why.

So, in summary, removal of the HAT avoids the problem, but with that strange behaviour along with the dongle port pickiness, I’m not sure what the cause might be.

I have not yet tried swapping the HATs around to see if the unit that had the Ubercorn now experiences the problem, but if there’s any chance that a faulty HAT may have caused damage to the RPi4 that may have resulted in the strange USB behaviour, then I wouldn’t want to risk the other RPi4. Hence, I figured that I should ask for help here first.

Thanks for reading!

The Unicorn Hat HD uses SPI for all its magic.

The Ubercorn uses that same Unicorn HD Library so I assume it also uses those same SPI pins.
I’m not sure that helps, but it may be info you don’t have.
If you do up a fresh Raspbian card, with no Unicorn hat attached and no Unicorn Hat software installed, do you have any issues?
Does anything change once you plug the Unicorn Hat in but don’t install its software?
And the final test is with Hardware and software installed.
You could also run the Unicorn Hat installer on your other Pi 4, just don’t plug in the Unicorn hat, and see if anything goes amiss. That would tell you if its just a Buster software issue.

Yes, it is simply having the HAT attached that causes the network to drop, whether or not the software is installed. When the software is installed, the HAT does function correctly, but with the network dropping. Leaving the software on and removing the HAT eliminates the problem.

WIFI or Ethernet? Maybe its interfering with the wireless signal?
I have a Unicorn HD and a PI 4B.
If I get a chance I’ll put my Unicorn on my Pi 4B and see what happens. The unicorn is currently on a black hat hack3r board. I might just hook it up with the ribbon cable first. Then directly to the GPIO. .

I tried my Unicorn Hat HD with and without ribbon cable. No issues, and web browsing was fine.
One thing to watch out for, if your not using a booster header or any standoffs, is the bottom of the Unicorn Hat could touch the Pi and maybe short out on the HMDI or Power connectors.
I don’t have a fan shim. I had a heatsink on my SOC but had to take it off to connect my ribbon cable. Clearance was just too tight. Not a big deal as I have a sheet or the double sided stick thermal pad to use to reattach it.

EDIT: This got me thinking, how do you have both connected? A picture of your setup may help if possible.

Thank you for doing those tests!

I did a bit more playing around.

I’ve been connected over Wi-Fi, and haven’t tried ethernet yet.

I removed the fan SHIM and the Unicorn HAT HD with booster header and connected a different Unicorn HAT HD (from one of my 3B+ boards), and I had the same issue: network connection drops when HAT is attached, but runs fine with HAT disconnected.

It sounds like a faulty RPi4 board to me.

I tend to agree, what else can it be?
If you go to the main Shop page there is a contact us link at the bottom. That will let you e-mail Pimoroni about your issue. I’d put a link in that e-mail to this thread. Then see what they have to say.

Unfortunately, the “contact us” page directs people here for any technical support, so it looks like they’re not to be bothered with my issues.

Things became much stranger. I ended up having the unit swapped, but the issue continued! I have two routers: one connects through the fairly-thoroughly-firewalled university campus internet connection (ASUS RT-AC87R), and the other uses that connection to connect to a VPN (PIA) using L2TP and distributes that connection (TP-Link Touch P5). We’ve had issues with an Android device and its captive portal detection indicating on the primary router that there’s no internet connection despite it actually connecting and working with no real issues, but didn’t give the issue on the VPN router. When I connected the HAT-issue RPi4 to the VPN router, the problem doesn’t happen! So, it only happens when connected to the ASUS router, and only when a HAT is attached, and only when some applications are opened (I have since noticed things halting with Synaptic, as well as laggy but still functional with Firefox).

I was wondering if it was maybe an IPv6 issue, but IPv6 was active on both, and disabling it on the ASUS resulted in no change. I’m not really sure what else to try, and can say that I’m completely baffled.

If you go down far enough in the Contact Us there is an e-mail option. I’d use it if I already posted here with no answer. Just put a link to this thread in the e-mail to show you tried using the forum.
I have no idea what’s going on, or wrong, with your setup?

Well, I can’t say that I understand the problem that well, but I have found a way around it.

Wi-Fi channel.

While no other devices showed any signs of poor performance related to interference, changing Wi-Fi channels on the router have completely eliminated the problem.

Those two routers mentioned before are both broadcasting both 2.4 GHz and 5 GHz networks. Naturally, it made sense for them to all be on different channels (which I had manually set). The poor performance on the main network but not the VPN network had nothing to do with filtered traffic, but that they were on different Wi-Fi channels. While the 5 GHz signal is rather weak in the room that I’ve been working in, I connected to the main router’s 5 GHz network, and it was working fine.

I was going back and forth between the ASUS router’s 2.4 GHz and 5 GHz advanced network settings, and couldn’t really find anything significantly different between the two… aside from channel. So I swapped the two 2.4 GHz channels on the two routers, and the performance flip-flopped as well — now shoddy on the VPN router, but fine on the main router.

From that point, it was just a matter of looking at ping statistics as I manually switched through the 11 channels, and came down to optimal performance setting the 2.4 GHz networks to channels 3 (main) and 5 (VPN).

They were originally set to 9 (main) and 3 (VPN), and noticed performance improve when moving from 9 to 8; with Chromium open, the ping average and standard deviation did skyrocket, and some packets were lost, but at no point did it drop the connection. That’s where the band experimentation came in, and was ultimately optimised to channels 3 and 5, with a ping to the routers of around 2 ms or 3 ms now, whether or not Chromium is opened (i.e., no trace of the original problem).

The most peculiar thing to me is how I feel like it must somehow be software related, because when I reinstall my chosen operating systems from NOOBS or PINN, it was connecting to the network and downloading the installation imagines with no problems, despite the HAT and SHIM still being physically attached.

Also, thank you very much for being the only one helping me through this, alphanumeric!

No problem, glad you got it sorted. One down side to manually setting your Routers channels is it can’t auto adjust for interference from other networks. I’ve done what you did in the past and it worked Ok. I’ve found just letting my router pick the channel worked just as good so I gave up on the manual setup. As always YMMV. ;)

An option to add an external antenna has been asked for on the Pi foundation forums. Doing that opens a big can of worms as far as WIFI certification and compliance goes so its not an option.
It can be done on a Pi Zero with a bit of resoldering etc. I have the surface mount connector to do it but chickened out doing the required modification. My eyes and coordination aren’t what they used to be lol.

Ha, what you call a downside to manual channel setting, I call an upside. I have never encountered any router or client that appropriately changes channels or handles the changing of channels well. Aside from despising the (not always brief) blips in connectivity any time the channel changes, I’ve often found that they end up changing the channel from something that has good performance to one that performs terribly, and for some reason often decide to cling to the poorer channel for unreasonable periods of time. Guaranteed that changing from auto channel selection is one of the first things that I do when configuring a router.

Honestly, I would love to know what situations that auto channel selection is supposed to work well in, as I was under the assumption after a decade of it being a terrible abomination that no such situation exists.

I honestly don’t think it matters if you live in a highly congested area like I do. Your still rolling the dice in auto or manual. But hey, use what ever works best for you. I try to use wired connections when possible.