Quad SATA HAT Assembly and Troubleshooting

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:

Hey, previously, the HAT and display worked perfectly but something changed in the software and it throws now an error…
*
I re-installed my NAS and the drivers, and recognized that the associated files changed from “rockpi-sata” to “rockpi-quad”. Any changes i make to the “rockpi-quad.conf” file do not take effect after restarting the service (temperature for fan and orientation of display text).
*
Checking the service status gives me an error message actually. Posting the output here:

user@raspberry4b:~ $ systemctl status rockpi-quad.service
● rockpi-quad.service - Rockpi SATA Hat
Loaded: loaded (/lib/systemd/system/rockpi-quad.service; enabled; preset: enabled)
Active: active (running) since Fri 2024-10-04 12:06:10 IDT; 2h 41min ago
Main PID: 664 (python3)
Tasks: 5 (limit: 8734)
CPU: 1min 37.613s
CGroup: /system.slice/rockpi-quad.service
└─664 /usr/bin/python3 /usr/bin/rockpi-quad/main.py

Oct 04 12:06:13 honey python3[664]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oct 04 12:06:13 honey python3[664]: File “/usr/lib/python3.11/configparser.py”, line 819, in _get
Oct 04 12:06:13 honey python3[664]: return conv(self.get(section, option, **kwargs))
Oct 04 12:06:13 honey python3[664]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oct 04 12:06:13 honey python3[664]: File “/usr/lib/python3.11/configparser.py”, line 797, in get
Oct 04 12:06:13 honey python3[664]: d = self._unify_values(section, vars)
Oct 04 12:06:13 honey python3[664]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oct 04 12:06:13 honey python3[664]: File “/usr/lib/python3.11/configparser.py”, line 1168, in _unify_values
Oct 04 12:06:13 honey python3[664]: raise NoSectionError(section) from None
Oct 04 12:06:13 honey python3[664]: configparser.NoSectionError: No section: ‘fan’

any idea how I can fix this? I would appreciate any help

added linux version: Linux 6.6.51+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt2 (2024-10-01) aarch64
and openmediavault version 7

after some digging, I found that in the misc.py file, the config called is cfg.read('/etc/rockpi-penta.conf') and not rockpi-quad.conf

I’ll have to try later if changing the conf file name or changin it in the misc.py solves the problem!image

++++++++++++++++++++
update: I changed in the misc.py file the penta to quad and now I see the expected behaviour of the oled display!

1 Like

Thanks for suggestion, mine still works :slight_smile:

I did a clean install and previously I could have my hat running with…

curl -sL https://rock.sh/get-rockpi-sata | sudo -E bash -

…but now the documentation says…

sudo apt update
sudo apt install python3-dev
wget https://github.com/radxa/rockpi-quad/releases/download/0.3.0/rockpi-quad.deb
sudo apt install -y ./rockpi-quad.deb

…which didnt save any rockpi-sata.service file.

I have several mounting scripts that depend on the rockpi-sata.service file. Did something change in general or did I do something wrong and there should be a rockpi-sata.service file?

I did a clean OS install and reinstalled it like the documentation said but now with sudo wget https://... and I saw this message:

Created symlink /etc/systemd/system/multi-user.target.wants/rockpi-quad.service → /lib/systemd/system/rockpi-quad.service.

I’ll try with this service file and maybe it would be wise to change it in the documentation aswell :wink:

Some warnings I got though, were:

WARNING: The scripts pyserial-miniterm and pyserial-ports are installed in '/usr/local/bin' which is not on PATH. Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.

WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv

…and…

N: Download is performed unsandboxed as root as file '/home/USERNAME/rockpi-quad.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

Nevertheless I :heart: your product!

Be careful, now the conf file has to be /etc/rockpi-penta.conf but the new script create /etc/rockpi-quad.conf. You just have to rename the conf file name.