Penta SATA HAT is now available

#1

We are glad to announce that the new Penta SATA HAT is available.

The Radxa Penta SATA HAT is an addon HAT designed for Pi form factor SBC with PCIe buses. It utilizes the high-speed PCIe and provides a small form factor NAS solution up to 5x disks. It has the following features:

  • Up to 5x HDD/SSD, support 2.5inch or 3.5inch SSD, up to 100T Storage
  • 4x SATA + 1x eSATA with power
  • Utilize up to two lanes PCIe 3.0 buses on the SBC
  • External standard ATX power supply support for HDD and Pi SBC
  • 12V DC power input for 2.5/3.5 HDD power and Pi SBC
  • Support HDD suspend mode
  • Support software RAID 0/1/5
  • Optional PWM control fan for HDD heat dispatching
  • Optional OLED display for IP/Storage info

Models and Pi Supports

  • RA006TE: SBC with top side E Key: ROCK 5A
  • RA006TM: SBC with top side M Key: ROCK 3C
  • RA006BM: SBC with bottom side M Key: ROCK 4A/4B/4A+/4B+/4SE/3A
  • RA006FFC: SBC with FFC PCIe connector: Raspberry Pi 5 / ROCK 5C

penta-for-rpi5
penta-for-rpi5.jpeg1920×1080 743 KB
penta-for-rpi5.jpeg
image
image.jpg2048×1150 438 KB

image
image.jpg2048×1150 410 KB

Availability:

Arace: https://arace.tech/products/radxa-penta-sata-hat-up-to-5x-sata-disks-hat-for-raspberry-pi-5

#2
#3

I was sent a sample to test and review—and I’ll start doing that soon! But I had a few questions in the mean time:

  1. I couldn’t find any Top Boards available from any resellers (the fan + OLED combo)—is that going to come back in stock soon, and also will there be any official way to mount it outside of the official case?

  2. Same question for the official case—will it be available through resellers again? It would be very nice to have it all packaged up.

  3. Failing that, is there a 3D printable case design available? I looked on Printables.com but didn’t find anything :frowning:

  4. I saw a guide for use with the Rock Pi on the Wiki, for fan control and OLED functionality. Will that be made to work on Raspberry Pi as well or is that more up to the community to program it?

  5. The Docs site has a Raspberry Pi 5 setup guide, which is great! I was wondering if that guide might also add in some suggestions for how to set up RAID, do media sharing, or any of that kind of thing. Even if it just ended with a few links to more options, that’d be helpful. (I’ll probably test mine with OMV, or just straight ZFS on Pi OS).

#4

Hi @geerlingguy

  1. We are producing the top board and it will be back in stock soon. If there is no casing, it is not easy to secure. We haven’t come up with a solution yet.

  2. We are also producing the case and it will be on the market soon.

  3. We may also provide 3D-printed case files at a later date.

  4. OLDE and the fan also work on the Raspberry Pi. Because the top board has not been sold yet, I am lazy and have not written the document completely.

  5. Great advice. We will add the RAID setup to the document.

1 Like
#5

Is it possible to recycle some of the parts from the previous Pi-NAS (for example the case, top hat, fans, etc)? I’m thinking of upgrading the previous Pi-NAS to RPi5 as the USB solution was janky as hell and unreliable… PCIe might be much more reliable, provided you are using good quality PCIe to SATA chips…

#6

Yes, the top HAT and fan can be re-used, the pinout remains the same.

#7

That’s great to hear! Good luck, and I’ll be testing the Penta SATA HAT this week—if I have any other questions I’ll be sure to post them here. It looks like a great little HAT, I completely missed that you had launched it a couple years ago with the Rock 4 as well.

2 Likes
#8

I was doing a quick look at the board compared to the previous Pi4b Quad SATA hat, I noted that the new Pi5 version no longer has fan header for the Pi heatsink. Will it be possible to add a fan header for the Pi heatsink considering all the GPIO pins are effectively taken away by the top hat and some janky workarounds is needed to control fans…

#9

I think the Pi 5 has a FAN header on the board?

1 Like
#10

Yes you are right… I totally forgot about the fan header on the Rpi5… my bad…

#11

Note that the Pi 5 Active Cooler, at least, requires a slight modification to make room for the barrel jack (see the three heatsink fins I had to shear off with a pliers…):

radxa-penta-sata-hat-13
radxa-penta-sata-hat-13.jpg3840×2160 1.01 MB

One other concern that I think the fan/enclosure could help with is heat on the SATA controller itself. It was up past 60°C in my testing:

radxa-penta-sata-hat-22
radxa-penta-sata-hat-22.jpg1560×1170 182 KB

#12

Exactly how far back does the 12v barrel jack extend?
Also, would it be possible to use a gpio extender and longer brass standoffs? It looks to me like it needs more airflow. A dual blower design would work more effectively here with the air flow pointed toward the 12v barrel jack/HDMI side rather than the back/ribbon connection side that has blocked airflow from the ribbon. That ribbon is going to take on a lot of heat and dust. The air flow should be guided to vent out above and over the HDMI and below the 12v barrel jack. Also, it would work better if the blowers were inverted with a slight spacer to allow room to pull heat away rather than draw air down from the sata vents on the hat to blow across the heatsink.
As is, putting a fan on top to vent up would cause a negative pressure zone that wouldn’t help much. With the rpi5 pulling air down through the vents the top fan would also need to pull air down. Heat rises so this cooling design is fighting against that and pulling heat down across the sata drives and through the vents and then across the rpi5 heatsinks.

#13

Here’s a side view where the jack is; it extends just into that first row of fins. Honestly there’s enough thermal mass there the Pi won’t throttle even without the fan, unless you put it in a box with no convection. I’m mostly worried that the small amount of heat rising from the Pi, hits the HAT board, which has the 60°C+ SATA controller on it.

radxa-penta-sata-hat-10
radxa-penta-sata-hat-10.jpeg2000×1125 215 KB

#14

Is there enough ribbon to raise it up another 8.5mm with a gpio header extender and some m2.5*8+6 standoffs? I think the extra space would allow for a better cooling system for both the board and the hat. I really have to watch the cooling because the ambient room temperature is rarely below 80f here and I am wanting an always on solution. I want to send files at high speed to ssd’s and let the system passively distribute them to a backup and a main storage in the background afterwards.

#15

I would think that the case design should making the fans blown from the side instead of the top in the original Pi4 quad SATA nas… it would work better in a dual fan setup… would help with thermals for all 3 main components of the setup… will draw a diagram later tonight, forgot to bring my pen out today…

#16

Good luck with such a setup while being tortured with storage traffic. :crazy_face:

I hope you’re using a ‘checksummed’ filesystem like btrfs or ZFS since this will show data corruption due to overheating way easier/earlier than relying on concepts of the past where most of this stuff gets undetected anyway (mdraid10/ext4).

#17

Not that much luck, just well designed custom software.

The extra 8.5mm would allow for the inclusion of heat shielding between the main board and the hat.
A redesign of the mainboard cooling would make it much more efficient and a well placed side blower on a customized case could then blow air up and out working in conjunction with a top fan to alleviate that heat build up on the hat that it shows in the thermal image.
There are some very efficient blowers designed for 3D printers with a 10mm clearance that could easily be adapted to 8.5mm with a simple 90 degree curved 3D printed plastic piece. That way it could be side mounted on the exterior of a case.

As for the software I made; it runs on NTFS but it uses checksums from the original files to verify all the transfers.
It also maintains directory structure and uses Google Translate on any unflagged file names that do not match the System Default Language. Software folders are automatically flagged, media files and folders as well as various other documents that are not in software folders are not flagged.
Also, file names without extensions get the headers scraped in an attempt to identify them.
Failed transfers result in a drive check and automated repair if needed and then the transfer is reattempted.
So far, it works, but I am running it directly on my main system and not passively on a secondary system such as a rpi5. I believe that transferring and verifying files onto a setup such as this running SSD’s and letting the rpi5 handle the rest would significantly reduce the time my main system is tied up with file transfers.

#18

ZFS seems to work well, though at RAIDZ1 (or any other level that needs parity data), the Pi 5 seems to struggle to maintain 1 Gbps write even for smaller file sizes (which is a little disappointing, tbh—I thought it could at least hit 115 MB/sec or so writes, and maintain that speed if the drives can keep up).

#19

I recently tested IPFire on the RPi 5 (yeah, not supported but if you’re able to combine bootloader+kernel with whatever userland – former Armbian/OMV dev here – then it works ofc). When testing NAT throughput and allowing the A76s to clock lower than ~2000 MHz cpu0 was always the bottleneck since all the IRQs ended up there and througput started to suffer.

Have you had a look at this (/proc/interrupts and watching atop/htop output)? And maybe know a way to use IRQ affinity with RPi kernels to get rid of this stupid cpu0 bottleneck by moving the IRQs in question to cpu1 – cpu3?

Or more generally speaking… did you have a look at what the bottleneck is in these situations? :slight_smile:

BTW: As mentioned in some Github issue where we met: RPi folks don’t use io_is_busy=1 while relying on ondemand cpufreq governor and in certain situations (though usually not benchmarks) this will result in the CPU cores not ramping up clockspeeds when needed.

#20

I didn’t observe atop in my testing last week, but I’ll fire it up soon. It’s annoying/odd that it only seems to affect writes over the network (samba more strongly than NFS)—any ideas why wouldn’t it also affect read performance? (Where I can saturate a 2.5 Gbps connection easily, reading 100 GB from a 4-drive array.)