raspberry pi

For years, SBCs that aren't Raspberry Pis experimented with eMMC and M.2 storage interfaces. While the Raspberry Pi went from full-size SD card in the first generation to microSD in every generation following (Compute Modules excluded), other vendors like Radxa, Orange Pi, Banana Pi, etc. have been all over the place.

Still, most of the time a fallback microSD card slot remains.

But microSD cards—even the fastest UHS-II/A2/V90/etc. ones that advertise hundreds of MB/sec—are laggards when it comes to any kind of SBC workflow.

The two main reasons they're used are cost and size. They're tiny, and they don't cost much, especially if you don't shell out for industrial-rated microSD cards.

...and it's all free—so far.

Raspberry Pi today launched Raspberry Pi Connect, a free remote VPN service for all Pi OS users.

If you create a Raspberry Pi ID, you can sign up for Connect, install rpi-connect on a Pi 4 or 5 running 64-bit Pi OS 12 'Bookworm', and register that Pi with the service.

Then, on any other device's web browser, you can log in and remote control your Pi through Connect's web-based VNC viewer.

The VNC server is based on wayvnc, and the Connect service allows for as many registered Pis as you want (though I'm guessing the interface is optimized for the majority use case of one or a few).

With the Raspberry Pi 5's exposed PCI Express connector comes many new possibilities—which I test and document in my Pi PCIe Database. Today's board is the Geekwork X1011, which puts four NVMe SSDs under a Raspberry Pi.

Unlike the Penta SATA HAT I tested last month, this carrier uses thinner and faster NVMe storage, making it a highly-compact storage expansion option, which has the added benefit of freeing up the top of the Pi 5 for other HAT expansion options.

I've long been a fan of Pi clusters. It may be an irrational hobby, building tiny underpowered SBC clusters I can fit in my backpack, but it is a fun hobby.

And a couple years ago, the 'cluster on a board' concept reached its pinnacle with the Turing Pi 2, which I tested using four Raspberry Pi Compute Module 4's.

Because Pi availability was nonexistent for a few years, many hardware companies started building their own substitutes—and Turing Pi was no exception. They started designing a new SoM (System on Module) compatible with their Turing Pi 2 board (which uses an Nvidia Jetson-compatible pinout), and the result is the RK1:

In today's video, I walked through setting up Axzez's Interceptor 1U case with a Raspberry Pi as a Frigate NVR, or Network Video Recorder.

Doing so allows me to plug multiple PoE security cameras straight into the back of the device, and record their IP video streams to disk (the case has space for up to 3 hard drives or SSDs). And by adding on a USB Coral TPU, I can also run inference on frames where motion is detected, and identify people, cars, bikes, and more using built-in object recognition models.

Radxa's latest iteration of its Penta SATA HAT has been retooled to work with the Raspberry Pi 5.

The Pi 5 includes a PCIe connector, which allows the SATA hat to interface directly via a JMB585 SATA to PCIe bridge, rather than relying on the older Dual/Quad SATA HAT's SATA-to-USB-to-PCIe setup.

Does the direct PCIe connection help? Yes.

Is the Pi 5 noticeably faster than the Pi 4 for NAS applications? Yes.

Is the Pi 5 + Penta SATA HAT the ultimate low-power NAS solution? Maybe.

In what is becoming a kind of hobby for me, I've just finished testing another tiny NAS—more on that tomorrow.

But as I was testing, I started getting frustrated with the fact I've never been able to get a Raspberry Pi—regardless of internal storage speeds, even with 800+ MB/sec PCIe-based storage—to consistently write more than around 100 MB/sec write speeds over the network, with either Samba or NFS.

NFS would be more consistent... but it ran around 82 MB/sec:

Samba would peak around 115 MB/sec, but it was wildly inconsistent, averaging around 70 MB/sec:

I have a problem: I use macOS¹.

...and it's not just for Pi Day.

After posting my deep-dive into the Pi 5's new BCM2712 and RP1 silicon this morning, someone linked me to this GitHub issue: Raspberry Pi 5 cannot overclock beyond 3.0GHz due to firmware limit(?).

For the past few weeks, a few blog readers (most notably, tkaiser—thanks!) commented on PLLs, OPP tables, and DVFS and how something seemed a little off with the 3.0 GHz CPU limit—which was apparently recommended by Broadcom, according to that GitHub issue.

But today, @popcornmix generated a test firmware revision without the 3.0 GHz limit, and zealous overclockers can get to pushing the clocks higher.

Ever since I X-rayed the Raspberry Pi 5 to see inside the BCM2712 and RP1 chip packages, I've wanted die shots of both chips. Why? Mostly out of curiosity, since I'm not a silicon expert by any means.

I also ran into some weird overclocking issues after writing about my experience overclocking and underclocking the Raspberry Pi 5, and probably spent an unhealthy amount of time (and money) to learn about the clocks, PLLs, and chips on the latest version of everyone's favorite Single Board Computer.

(Some Raspberry Pi 5s were harmed in the making of this blog post.)

Silicon lottery.

Now that the Raspberry Pi 5s been readily available (at least in most regions) for a few months, more people started messing with clocks, trying to get the most speed possible out of their Pi 5s.

Unlike the Pi 4, the Pi 5 is typically comfortable at 2.6 or even 2.8 GHz, and some Pi 5s can hit 3.0 GHz (but no higher—more on why tomorrow well... this limit may be able to be lifted).

After some testing, I found the default 2.4 GHz clock on the Pi 5 is pretty much the efficiency sweet spot, and after a lot more testing recently, I can confirm that's still the case, testing a number of Pi 5 samples.