Quad SATA HAT Assembly and Troubleshooting

Hello
I have a problem with my SATA HAT (for Raspberry Pi4).
I observed that my harddisks (4 SSDs) disappear after a few days of usage.
It seems that the USB 3.0 bridge (the PCB with 4 USB male connectors on it) is faulty.
I can sometimes get it to work by removing the bridge and reinserting it again.
I thought that I can replace it with 2 short USB 3.0 cables with male to male connectors (A-A).
So I bought 2 cables and connected them instead of the faulty bridge. Unfortunately the cables do not work (and I am sure they are correct, they are new from a shop and tested). Why I can’t use such cables? How can I replace the faulty USB bridge? Where I can buy new bridge replacement?

Best regards

Have you tried this method?

You can use just cables I think, but you can buy new bridge from here: https://shop.allnetchina.cn/collections/sata-hat/products/quad-sata-kit-usb-bridge-sparepart

Sadly, it’s sold out, so you have to wait :frowning:
But in my case, my bridge is also REALLY SENSITIVE, so if you touch it a little bit, it will definitely interrupt the connection between the RPi4 and HDDs.

You might be able to loosen the hat and the Pi screws, push both hard over towards the USB socket end, and retighten. I do not know how much slop is left over, but I found that the bridge plug lengths are somewhat shorter than the plug lengths on other USB cables I have, With the case being between the boards and the plug, anything you can do to shorten the gap might make a difference.

Is there a way to turn off all LED? Both on raspberry pi 4 and the quad sata hat?

My new quad hat is only partly working so far. The little screen on the fan is displaying CPU load, uptime, etc, and the little blue light is on next to the one 2.5 sata drive in socket 1. However, the drive itself is not showing up in lsblk nor can OpenMediaVault find it. It is the v1.3 quad hat on a Pi 4 4GB. I tried 3 different 2.5 drives, one at a time, that all work in another system. Any ideas how I might get it going?

Hi !
I have finally recieved my RPi4 and have been able plug in the quad sata hat I bought way back in 2020.
I’m experiencing a problem with port number 4, although I have a drive plugged-in it just doesn’t work, the corresponding LED never lights up, and only drives sda through sdc show in /dev/
I’ve tried to swap two drives together and the problems is still with port number 4. I’ve tried to unplug and clean the USB bridge to no avail. What can be done to solve this problem, could it be that I ended up with a faulty board or bridge or something of that nature ?

Help would be very much appreciated

Hi !
I have some news on my issue.
I’ve tried to plug less than four drives and no matter what I do, whether it’s a single HDD, two or three, any drive plugged into the fourth SATA port never shows up. The LED never lights up and it can’t be found in /dev/
I’ve also tried without the bridge and the LEDs do light up on SATA ports 1 through 3 but not on 4.
So in my mind, it rules out the eventuality of a faulty USB bridge and leaves me with either :

  • A software issue (but it seems unlickely since ports 1 to 3 work out of the box)
  • A faulty topboard
    Does anyone have an idea on how to solve this ?

Hi @Bowbaq,

The SATA 2 and SATA 4 use the same USB. it looks like there may be a problem with the SATA 4 socket, can you take a clear photo of the back and send it to me via email at setq@radxa.com

Hi there, i bought the quad port kit over a year ago but only just got round to using it lately. Set it all up and then about four weeks later two of the disks disappeared. when i run lsusb only one of the SATA QuickPort Duo show up. I ended up reinstalling everything again and re-seated all the connections but still only one of the SATA controllers show up.

Has my SATA board died?
Many thanks

Found a post about the usb bridge not being seated. Kept unplugging and re-plugging until it work :slight_smile:

I’m experiencing the same issue with accessing the OMV6 SMART page. Whenever I try to access it, the smartctl command is executed, which causes all four drives to disconnect.

I would like to know if there is any solution for this problem.

I did a little playing around and for me, if I have enabled the smart panel in the dashboard I lose the drives. If I disable it I can use the smart panel under storage and see the temps of the two drives. I don’t know why they should be different, but perhaps they are using different parameters to the smartctl command.

I am using OMV 6.7.1-2 and Linux 6.1.21-v8+. and smartctl 7.2 2020-12-30 r5155 [aarch64-linux-6.1.21-v8+] (local build).

I have updated the controller firmware, but that was a couple of years ago.

There are some solutions for this issue:

  1. this don’t happen with UAS mode on, but probably You will get other random disconnects on high volume data transfers, just note this fact because on some boards UAS with this chip is just useless
  2. not every smartctl parameter cause this issue, therefore You can avoid running particular query. There was even script for that, I’ll paste it at bottom, it comes from odroid cs2 and it’s probably outdated now, but the idea is to modify omv smart function to not query everything
  3. this also is not a problem if You use hardware RAID feature, then You will have one drive for each controller instead of two (RAID 0, RAID1 or JBOD), with own smart informations, of course You can’t do RAID5 or RAID6 with all four drives, but as bonus You will have more cpu power compared to mdadm.

promised script:

#!/bin/bash

SRCPATH1="/usr/share/php/openmediavault/system/storage/smartinformation.inc"
SRCPATH2="/usr/share/openmediavault/engined/rpc/smart.inc"
SRCPATH3="/usr/share/php/openmediavault/system/storage/smartstoragedeviceabstract.inc"

function chSrc() {
	
	local SRCPATH=$1;
	
	if [ ${SRCPATH} = ${SRCPATH1} ];
	then
		CMDRE="$(grep "\"-x %s\"" ${SRCPATH} | grep escapeshellarg | wc -l)"
		DIDIT="$(grep "\"-H -i -g all -c -A -f brief -l xerror,error -l xselftest,selftest -l selective -l directory -l devstat -l sataphy %s\"" ${SRCPATH} | grep escapeshellarg | wc -l)"
		OPTION="-x"
	else
		CMDRE="$(grep "\"--xall\"" ${SRCPATH} | wc -l)"
		DIDIT="$(grep "\"-H -i -g all -c -A -f brief -l xerror,error -l xselftest,selftest -l selective -l directory -l devstat -l sataphy\"" ${SRCPATH} | wc -l)"
		OPTION="--xall"

	fi

	if [ "${CMDRE}" -eq "1" ];
	then
		sed -i s/"${OPTION}"/"-H -i -g all -c -A -f brief -l xerror,error -l xselftest,selftest -l selective -l directory -l devstat -l sataphy"/g ${SRCPATH};
		echo "Okay"
	elif [ "${DIDIT}" -eq "1" ];
	then
		echo "Okay. You did it already. You don't need to try it"
	else
		GOTERROR=true
		echo "ERROR : This is a script to fix HDD disconnected from the system, "
		echo "        when you access S.M.A.R.T information."
		echo "        Read me using any text editor and fix it"
	fi
}

chSrc ${SRCPATH1}
chSrc ${SRCPATH2}
chSrc ${SRCPATH3}

if [ ${GOTERROR} ];
then
	echo "You have to see \"Okay\" three times"
	echo "If you got an ERROR even one time, please modify the files by hand"
	echo "1. ${SRCPATH1}"
	echo "2. ${SRCPATH2}"
	echo "3. ${SRCPATH3}"
fi

Hello All,

I’m having an issue with my Quad SATA Hat running on RaspberryPi 4B 8Gb. The thing is that the fan on the top is active at 100% all the time. I’ve posted in this thread:

I also saw that there are other people with similar problems:


I’ve tried some of the suggestions, but they didn’t work. I’ve ordered a brand new top hat with fan and oled included - same issue.

At this point I’m wondering if I’m doing something wrong, but so far I can’t find anything wrong with the config.

Any ideas are greatly appreciated!

does your display work? does the fan spin up as soon as power is connected, even before boot? in this case, as suggested earlier on, this points towards faulty hardware.

in a very unlikely, yet possible case, could it be that the replacement you ordered is defective as well? Do you have a spare fan which you can use as a replacement to test? I ordered some PWM controlled Raspberry Pi fan in AliExpress with same dimensions and voltage, and LED design: https://de.aliexpress.com/item/1005002518918026.html?spm=a2g0o.order_list.order_list_main.144.42e35c5fl2z723&gatewayAdapt=glo2deu

The HAT worked instantly with new fans. I also had ordered some fan that was for 3D printer with same dimensions and PWM, but that one was not compatible. So, make sure to try fans that are compatible with Raspberry Pi.

The fan should not spin up at power on, but only after drivers habe benn loaded during boot.

Good Luck!

does your display work? - Yes, it does.
does the fan spin up as soon as power is connected, even before boot? - Yes it does, the moment I plug the 12V barrel plug it lifts off at 100%.
in a very unlikely, yet possible case, could it be that the replacement you ordered is defective as well? - It could be, I have no idea.
Do you have a spare fan which you can use as a replacement to test? - I do. And that sir, I haven’t tested out yet. But I will now! Any chance anyone has a scheme which pin goes where? (I have the exact same pin layout for my fan as shown on the PWM fan you shared from AliExpress)

The fan should not spin up at power on, but only after drivers habe benn loaded during boot. - That’s the thing I noticed first when I swapped the 4Gb Pi with the 8Gb version. The old one waited for everything to load and then the fans spin up. In comparison this one (8Gb) model blasts at full power immediately. Even after #sudo shutdown now , the top hat fan keeps going…

You are describing a situation where the 8Gb Pi and the 4Gb pi differ in their response. Is this with the same sd card in each? That would suggest a problem with 8Gb board where the GPIO is always on.

Any other Pi’s to test with with the same sd card that runs in the 4Gb. If you get another to work, it more implicates the 8Gb board than the software.

So it worked with 4GB raspberrypi and now with 8gb version it doesn’t work anymore? Hmm, that would be weird and it means that the problem is not the hat or the fan…!?

In my case, I had exacly the same problem, working display, fan constantly spinning no matter what… after swapping the fan it worked.

You can try to swap either hardware part and then see which combination works.

If I remember correctly, the wires of the original fan that came with the hat are coloured:
Red = 5V
Black = GND
Yellow = PWM

so just connect the pins accordingly to your other testing fan (sometimes we have other colours, such as blue for PWM or white for GND), I’m sure you’ll figure it out

Is this with the same sd card in each? - Yes, it’s the same sd card.
So it worked with 4GB raspberrypi and now with 8gb version it doesn’t work anymore? - Yes, indeed. Although I will give it another test with another RPI4. I just sent the old one to work as PiKVM, thus the upgrade for my Quad SATA Hat to 8Gb. But definitely will try another RPI4 board as well.

And things got even weirder at this point. I listened to the advice of @Walter_White and connected the spare fan I have at home in place of the top hat fan. It works, however there is a difference in the behaviour. When the top hat fan blasts 100% all the time the spare starts at 100% and then it stops for a while then starts again. It feels like it’s trying to follow the PWM instructions, however the behaviour is sporadic and not as expected. This process repeats itself constantly. It’s definitely a HW issue, but I cannot pinpoint the failing element.

Update:

After some time troubleshooting and no I didn’t resolve the issue, just made it bearable, here’s what I did:

  1. Changed the RPi4 with a new 8Gb version - no change.
  2. Changed the top board with the LCD - no change.
  3. Tried different sd card with different levels/versions of software - no change.

Semi-solution was to buy a Noctua 40x40x10 3 pin 5V fan and after some soldering, wiring and tinkering with washers, bolts etc. installed it in the enclosure. Still at 100% but at least not screaming like the old fan.

I was kind of disappointed in my whole interaction with Allnet China, where I ordered the board from as the Quad Sata Hat was the only thing I haven’t changed or replaced yet. I got a reply from representative that the issue will be brought to the developers attention, but alas nothing has happened since 01.Oct.2023. I hope they will at one point take a look.

Here’s how the whole enclose looks with the new fan though: