Remember that failed experiment where I ran Jellyfin off of a LattePanda V1?

Do you recall all the parts where I said what this single board computer cannot do?

Yeah, I remember.

Then I took it and put the two of the most critical services running on it: the blog you’re reading right now, and my Wireguard setup.

Trust me, it makes more sense with some context. The board is incapable of doing anything else other than serving content from the eMMC module, and it has a functioning network port. It doesn’t seem to crash in these scenarios.

When I try anything else with this board, especially things that include USB connectivity, things break. This makes the board ideal for a light workload that needs to be up 24/7.

The biggest threat to my uptime is not internet connectivity or loss of power (although that did happen for the first time in a year recently), it’s me getting new ideas to try out on my setup, which results in downtime. This board is so unreliable for trying those ideas out that it removes any and all temptation to do that, resulting in a computer that has the highest chance of actually being up and running for a very long time.

To play things safe, I used an IKEA SJÖSS 20W USB-C power adapter that I got for 3 EUR, with a cheap USB-C to USB-A adapter thrown into the mix. It looks janky, but the adapter outputs 5V 3A, which makes it the beefiest power adapter that I have in my fleet for plain USB-A powered devices.

I then hit the board with some stress commands, including hitting the 2 GB of memory. It ran really well for days, no issues at all.

I also improved the cooling situation. I am now a proud owner of an assortment of M2, M2.5 and M3 screws and bits, and equipped with a Makita cordless drill, I made some mounting holes into an old aluminium server heat sink. The drilling was a complete hack job, everything was misaligned, but it was good enough. Certainly better than holding the board and heat sink together with thin velcro strips. The cooling performance is completely adequate, the board hits a maximum of 65°C with the heat sink facing down. This is well below the point at which the board starts to throttle its CPU.

The theoretical maximum Wireguard throughput on this board is about 340 Mbps, measured using the fantastic wg-bench solution.

Remember the part about the USB ports being flaky? Yeah. That didn’t stop me from getting a USB Gigabit Ethernet adapter to remove one of the main limitations of the LattePanda V1. Based off of vibe-recommendations by Claude, I got a TP-Link UE300 for its alleged low power usage and its availability at a local computer store in Estonia. It seems to work well enough, you can push gigabit speeds through it measured by iperf3, and the actual Wireguard performance that I could push through it with an actual workload was at about 420 Mbit/s, higher than indicated by the benchmark, and plenty fast for most workloads, especially in external networks that are usually slower than that.

A few hours after making that change, a HN post put some mild load on the LattePanda V1, what good timing.

As of publishing this post, the blog has been running mostly off of the LattePanda V1 for over a month now, with that gap in it being caused by contemplating getting that USB Ethernet adapter and temporarily running the blog and Wireguard off of another mini PC during that time.

Did you notice?

2026 July update

I was running out of room and network ports on my router, so I decided to stop this experiment. During all this time, there were no issues with the LattePanda V1, except when I accidentally bumped into its power cable and made it go offline. Oops.

LattePanda V1. It’s been a while, huh?

I had it as a backup server (which I blew up).

Then it got promoted to… a backup server. But then its PSU blew up.

Then it was waiting for some cool ideas at a potato enthusiast.

Now it’s back in my hands.

Unlike its modern counterpart, the LattePanda V1 is a flawed single board computer.

It’s slow.

It’s unstable if you connect power hungry USB devices to it.

It needs some cooling, but I’m too cheap to buy a properly designed heat sink for it.

It has display quirks.

It only has a slow 100 Mbps Ethernet link.

It only seems to work reliably on one side. Not even joking, the “heat sink down” configuration is the only one that works for me.

LibreELEC failed to play back any videos on it properly. The videos would play for 10 seconds, and then it would hang, no matter the encoding or hardware acceleration settings.

With hardware prices being wonky again, I decided to give this board a last chance of being useful. If new hardware is absurdly expensive, then it makes perfect sense to use what you have, no matter how slow or crummy it might be. Reduce, reuse, and only then recycle.

That’s when I decided to run a Jellyfin server off of it. Transcoding is out of the question, but serving media files over the network should still be quick enough, right?

For this experiment, I used one of the 18 TB hard drives that I’ve covered earlier. Just the single one, no redundancy here. This one drive is probably about 10x the cost of the LattePanda V1 itself, making it a perfectly reasonable choice.

For ease of troubleshooting, debugging and guaranteed eventual reinstallation, I put Fedora Server on an 128 GB USB 3.0 flash drive by Samsung. Risky move, I know, but as you might have noticed, this whole build is everything but reasonable. That left the eMMC storage as the perfect candidate for storing cache and service related files.

Cooling is solved by a random server heat sink slapped on the bottom of the LattePanda, with a few critical components like the CPU making contact with thick and soft thermal pads. The whole thing is fastened using velcro strips that I cut to a thin size in the middle so that I can route it between the components on the PCB and within the heat sink fins. The edges of the heat sink are covered with some painters’ tape that I had around to avoid shorting anything out on the board, because those parts on the board contain all sorts of metal bits and pins that have power going through them. I’m actually quite happy with that mount!

I’ve been experimenting with Podman again after Docker kept doing weird things with the v29 release, and I’ve been happy with the results, so that’s what I used on the LattePanda V1 as well. I slapped Jellyfin on it, threw in some test files and gave it a go.

Navigating the UI feels a bit slow at times, but it’s not really noticeable on an LG smart TV with a really laggy user interface.

Actual video playback that requires no transcoding works quite well, at least for smaller media sizes.

Technically, you can do transcoding on this and even utilize the tiny little integrated GPU in it, but the results are not usable. With smaller files it might be usable, but in one test I saw 7-8 FPS transcoding speeds and the server struggling to keep up, with CPU usage locked at 100%.

If we ignore all the downsides, then the LattePanda V1 can actually be a usable media server. Serving files off of a big drive does not require a lot of resources, and for that the LattePanda V1 is a solid choice. It also uses only a few watts of power on its own, so you can keep it on 24/7 guilt-free. In this build, the hard drive itself is actually the most power hungry component by a long shot (about 2/3 of the total power budget).

The 2 GB of memory is juuuuuuuust enough for this setup.

As of writing this post, it has been running for about a week, and it’s been fine. I intend to keep it running in a drawer for as long as possible just to see what will die first.

Will it be the eMMC storage?

The USB flash drive holding the operating system?

The expensive hard drive?

The power supply?

The thin velcro strips holding the cooling together?

My patience?

Don’t worry, I have backups. Well, backups of the important bits. I’m ready to lose data again.

2026-01-22 update

Okay, it was too bad of an idea.

The LattePanda V1 would occasionally just… stop.

From what I gathered by accident, it’s likely that the USB port containing the operating system would flake out and result in the system not being able to run any tools that are not in memory. I tried to move the installation to the eMMC drive, but after failing multiple times due to the display not working, or the system deciding to shut down randomly, I gave up on it. For now.

Guess I’ll have to use it in a solar-powered website project. ¯\_(ツ)_/¯

Disclosure: the review sample was provided by DFRobot, the makers of LattePanda. I am allowed to keep the review sample indefinitely, no money exchanged hands, and as always, this post covers my own thoughts and views on the product.¹

In 2023, I happened to find a LattePanda V1 for sale at a good price. Given the then-poor availability of affordable Raspberry Pi units, I got one for testing and finding potential use cases for it in my setup. However, it was just a little bit too weak for any practical uses in 2023, with its CPU and USB connectivity being just slow enough to be of less use, and the networking being capped at 100 Mbit/s.

In 2025, we have the spiritual successor to it: the LattePanda IOTA. It keeps the same form factor, but the connectivity and raw power have all received a significant jump, with the CPU performance rivalling my current home server, the trusty ThinkPad T430.

The marketing materials list all sorts of sensible use cases for it. I’m sure that it works fine for those, but I’m only interested in one thing: how close does this board get to being the perfect home server?

The perfect home server uses very little power, offers plenty of affordable storage and provides a lot of performance when it’s actually being relied upon.

In my case, low power means less than 5 W while idling, 10+ TB of redundant storage for data resilience and integrity concerns, and performance means about 4 modern CPU cores’ worth (low-to-midrange desktop CPU performance).

The model and accessories

The model I’m reviewing is the 8GB RAM/64GB eMMC one, with a Windows 11 installation on it (not activated).

Along with the review unit itself, I got sent the following accessories:

• active cooler
• M.2 M-key expansion board
• 51W PoE expansion board
• M.2 4G LTE expansion board
• UPS expansion board

The board was tested with a Lenovo 65W USB-C power adapter, because that’s what I had available. Given the specs of the board and the accessories, that should be plenty. As far as I know, USB power delivery seems to work fine and it’s not just a weird USB-C connector that requires specific voltages to work.

The M.2 NVMe SSD used in this review is a 512 GB Samsung PM9A1. I got that one from another PC that really didn’t need a boot drive that large.

Most of the testing was done with a fresh Fedora Server 43 installation, kernel version 6.17.7.

The hardware

I suggest looking at the spec sheet if you’re interested in all the fine details and available configurations.

In short:

• CPU: Intel N150, 4 cores, 4 threads, up to 3.6 GHz
• RAM: 8/16 GB (depending on model)
• Onboard storage: 64/128GB eMMC (depending on model)
• Networking: gigabit Ethernet port
• Real-time clock: yes!

The overall connectivity has been improved with the new version of this board compared to the old board. The USB ports are all fast 10 Gbit/s ones, and we have actual PCIe connectivity to play with, although the available bandwidth is quite limited with a PCIe 3.0 x1 lane available on the port that both the M.2 M-key and PoE adapter connect to.

What caught my eye was the CPU performance I’ve been proudly running an old ThinkPad T430 as a server for a while now, with some failed attempts to find a more low-power and efficient solution.

The Intel N150 is now offering similar levels of performance, but in a much smaller power envelope.

When it comes to more specialized functionalities, such as GPIO and the RP2040 microcontroller, I don’t currently have a solid use case for them, so they won’t be covered in this review. I might fancy giving them a go in the future though, it would be nice to get some environmental sensors on it to monitor the temperature and humidity of the server room (which is a closet).

Since I also don’t have an 4G LTE modem available, I did not test the associated adapter.

M.2 M-key adapter

The way you can add expansion boards to the LattePanda IOTA is quite similar to how Raspberry Pi 5 and other similar single board computers do it: you simply run a flexible cable to an adapter board, and bam, you have extra connectivity!

With the M.2 M-key adapter kit, you get the adapter itself, some mounting screws and brass stand-offs, and a tiny little flexible cable for the PCIe signal.

The link speed is PCIe 3.0, with one lane available. In theory, this means a maximum of 1 GB/s of throughput. In practice and with this board and SSD combination, I got a maximum of ~810 MB/s. I expect some levels of losses with these types of setups, so in my view this seems normal. For the test, I just did a dd if=/dev/nvme0n1 of=/dev/null bs=8M status=progress. The SSD itself supports up to 4 lanes of PCIe connectivity so that should not be a limiting factor here.

The lovely part about M.2 NVMe ports is that you can use it for a lot of off-label use cases.

Fancy some SATA ports? There’s an adapter for that.²

Or a network card? Some fancy AI accelator thingy? Or a full-sized GPU? Anything will work (probably), as long as the cables and adapters are high quality, and you provide extra power to the device through other means.

PoE expansion board

The only device on my network that is connected over PoE is currently an Ubiquiti Wi-Fi access point, and that is unlikely to change in the near future because that would require a full replacement of my networking gear.³

However, I still gave this board a quick go, and I’m happy to report that it also works as an additional standalone Ethernet port. The Ethernet controller seems to be similar or the same as on the main board, and it shows up as a separate networking device. Both are Realtek NIC-s (Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller), and they work with the r8169 driver. Realtek has a spotty compatibility story overall on Linux from what I’ve read, but this one seems to work fine on Fedora Server 43.

I was very close to pulling the trigger and turning it into a beefy router so that I can finally move my Wireguard networks on the router as my current one cannot do more than 20 Mbit/s of Wireguard traffic, but I didn’t end up going through with that idea because of how well the SBC did in other areas.

UPS expansion board

As some of you might know, I’m a fan of playing with fir- 18650 Li-ion battery cells, and I’m hoping to one day build a solar-powered server of my own (of which there are many examples).

I took some spare 18650 cells that came from an old ThinkPad battery, made sure that the voltages are more-or-less the same, and threw them on the board.

Connecting the UPS board with the standoffs was fine, but the cable connecting it with the SBC was finicky. I triple-checked that the connector was the right way, but had to still use an uncomfortable amount of force to connect it all up. The battery cells themselves sit snugly on the board, and unless you drop the board, they should not fall out on their own. You’d still want to build a case around it if you’re going to actually put it to use in rough environments.

The manual for the UPS board emphasizes that it only works on Windows 10/11, and sadly that seems to be the case, the UPS does not seem to show up as an USB-listed device, and tools like NUT did not find anything to monitor with a quick 5-minute investigation.

The UPS board also has an interesting selection of switches that you can use to adjust the behaviour of the board, like automatically turning the board on when power comes back on, and setting an 80% battery charge limit. The first one was not really necessary to use, the board would follow whatever setting you have enabled on the SBC itself. I configured mine via UEFI settings to automatically turn on with a power adapter connected, and that worked here as well.

The run time of your LattePanda IOTA with the UPS expansion board will heavily depend on your workloads and quality of your battery cells. Mine were used cells, and then I hit the board with stress -c 4 to create some load on it. It ran for over an hour like that, and then I got bored and wanted to proceed with testing other accessories. The marketing materials mention up to 8 hours of runtime, and I suspect that with good Li-ion cells and workloads where you idle most of the time, it will likely be achievable.

The board seems to trigger a hard shutdown on Linux because the host OS is not aware of a battery being connected. Not that catastrophic for most modern filesystems and database engines, but something to consider in your own workloads in case they are Linux-based.

The UPS board seems to handle power connection and disconnection events well enough, it did not do anything weird when repeatedly plugging and unplugging the USB-C cable.⁴

Based on the readings from a wall outlet energy meter, the board uses up to 20W when charging the cells. It’s possible for the board to pull more than that with a maximum CPU load and connected peripherals, so I wonder if that may be an issue with more intense usage scenarios.

During charging and discharging cycles, even under heavy loads, the battery cells did not get hot and were at best warm to touch.

Ethernet

It’s gigabit.

Fine for my use case given that I still live in 2006 and only have devices that support gigabit Ethernet speeds at best (excluding the Ubiquiti Wi-Fi AP), but certainly less than some competing products.

eMMC and USB storage

Compared to the LattePanda V1, the USB port performance is actually decent for my use case. I can connect up to three USB-connected storage devices to the board, so that’s exactly what I did.

I set up three different USB-connected devices:

• USB hard drive (Seagate Basic)
• USB SATA SSD (Samsung QVO 4TB in ICY BOX USB-SATA adapter)
• USB NVMe SSD (512 GB Samsung PM9A1 with some random cheap USB to M.2 NVMe adapter)

For each device (including on-board eMMC device), I ran a while true; do dd if=/dev/X of=/dev/null bs=8M status=progress; sleep 5; done, which puts a sequential read workload on all the drives in an infinite loop.

After about 72 TB of data read in less than 24 hours, I checked the kernel logs and there were no stability issues whatsoever. The NVMe SSD started throttling due to heat, which was expected with that cheap adapter.

Assuming no issues with any cables and adapters, the USB ports seem to be solid enough for running storage devices off of. Yes, it can be a horrible idea in some use cases, but at the same time my ThinkPad T430 has been excellent with USB-based storage, and that’s with one of the USB ports being coffee-stained!

The eMMC chip is also more performant compared to the previous iteration, with sequential read speeds averaging around 316 MB/s, writes around 175 MB/s, and average read latency being around 0.15 ms. Certainly good enough for a boot drive.

Display connectivity

The LattePanda V1 struggled with larger displays, and when I gave it a go during this review, it would not properly display an image on my 3440x1440p monitor.

The LattePanda IOTA just did it, at 60 Hz. On Fedora Workstation and GNOME, the experience was smooth. Once you start doing things in the browser, like video playback, the situation is less optimal, but as a makeshift desktop PC it is alright for most low/mid-range activities.

Windows compatibility

The board came with a Windows 11 installation (not activated). As is tradition with Windows, the initial impressions are horrible, update processes running in the background made the active cooler go wild and the device felt sluggish.

But after that process is done, the experience is not bad at all if you look past the OS being Windows.

I did not do a thorough investigation and I suggest formatting the device boot drive either way when receiving it, but the Windows 11 installation looked clean enough, with no obvious bloatware.

Linux compatibility

The LattePanda V1 had some quirks. The performance was iffy, and you had to specify a Linux kernel parameter on first boot so that Fedora Linux does not confuse the optional display interface to be an always-connected primary display.

The previous version also didn’t include a real-time clock (RTC) by default, which meant that it was impossible to schedule some systemd timers as the time would always jump on boot years ahead on distros like Fedora Server. I got stuck in a reboot loop with a scheduled reboot job that way, was not fun to recover from.

With the LattePanda IOTA, I have not observed any weird oddities and quirks with it. Even the kernel logs don’t show anything that’s problematic, and the RTC is handy to have around as that helps avoid the issue mentioned above.

Active cooler

With the LattePanda V1, the cooler was not strictly required, but strongly recommended if you were going to use the board with moderate to high sustained loads. My solution was to slap an inappropriately sized heat sink to it with a thermal pad and zip ties and/or velcro strips, which looked horrible, because it was.

With the LattePanda IOTA, the cooler is now a mandatory part of the assembly. It can be fitted with either a passive cooler, a case with passive cooling, or an active cooler.

The active cooler does a good job of keeping the board cool, but it does get super loud at higher loads. The default fan curve is very primitive, with the fan changing it speeds in big and sudden increments. Bursty workloads certainly feel bursty with this fan. You will not want to be in the same room with this active cooler.

The sound profile is very similar to a thin and light laptop, and the fan has a very strong high-pitched whine to it.

Here’s an audio recording of the noise under heavy load if you’re interested (MP3 file). Recorded using a Google Pixel 8a.

You can mitigate the active cooler noise issue by reducing the CPU clock speed by setting a lower power limit in UEFI settings, or on Linux, setting a lower CPU performance ceiling using intel_pstate driver max_perf_pct option once on boot. This comes at the obvious cost of some raw performance, but given that CPU power scales non-linearly, you may not even notice it that much.

If you are sensitive to fan noise, then do get the passive cooler and slap a Noctua fan on it, it will likely be a much better experience with both the cooling performance and noise levels.

Oh, and fun fact: I got so carried away with testing that I actually forgot to remove the plastic film on the larger thermal pad that cools supporting components.

And then I did about 24 hours of stress testing with that arrangement.

I can confirm that the design of the board is idiot-proof, as I did not actually notice any severe throttling or thermal issues with that mistake. You can actually see the plastic film being present in a few photos of the board in this review. I still can’t believe that after all these years I ended up making that one mistake that you usually see online in tech support gore posts.

Power consumption

The idle power consumption of the LattePanda IOTA seems to be around 4.0W, which is more than the Raspberry Pi 5 8GB with its power consumption being around 3.2W. Slightly higher compared to that, but lower than most x86 mini PC-s with idle power consumption typically in the range of 6-14W.

During the disk read speed stress test, I saw a maximum of 24.4W pulled from the wall.

With the disk read stress test and a full CPU stress test, I saw a peak of 36.3W, with it quickly dropping down as the CPU settled down at a lower clock speed.

Home server

This board came surprisingly close to my perfect home server criteria that I had outlined earlier this year.

Less than 5W when idling? Check.

10+ TB of redundant storage? Check.

4 modern cores’ worth of CPU performance? Check.

Enough performance during bursty workloads? So far, yes.

I then installed a fresh copy of Fedora Server 43 and moved all my home server workloads to it. The eMMC storage is used as a boot drive, journald writes are disabled, workloads requiring good latency and speed are on the 512GB NVMe SSD, and bulk storage is connected via two existing USB-SATA adapters taken from one of those WD Elements/MyBook external hard drive enclosures.

Then it just worked. No issues.⁵

The drop in the overall power consumption of my whole home server and networking stack was also immediately noticeable.

Here are my observations of the CPU performance and behaviour after hitting it with an all-core CPU load:

• 2.9 GHz for a short time period (10-15 seconds), with CPU hovering around 80°C
• 2.2-2.3 GHz after that, with the CPU dropping to around 70°C

I have seen the CPU hit around 3.6 GHz with a single core load while there is nothing running in the background, but during my normal home server operations the cores are doing enough work across all 4 cores, so that doesn’t happen all that often, and 2.9 GHz is the ceiling for single core performance.

The only limiting factor so far has been the 8 GB of memory on my review unit, but on the bright side that limitation forced me to review the memory usage of some of the jobs that I run on my home server, which ended up with me finding a few resource hogs and then fixing them all up. Now I can run about 30 Docker containers of various resource consumption on a single board computer, and with less than 4GB of RAM used. I set up an 8GB swap file on the SSD, just in case.

Thanks to the relatively small boot drive, I also learned that even if you move the Docker data-root folder to another location, containerd will still clutter up your boot drive, so you’ll have to change that path in its /etc/containerd/config.toml file root setting.

I’m genuinely impressed with how well the LattePanda IOTA runs as a home server. The board isn’t really designed with that use case in mind, and I suspect that the Intel N150 might be doing most of the heavy lifting here, but still, very impressive!

Is it the perfect home server? No, but it’s pretty damn close to my definition of it.

UEFI settings tour

For those interested in what options are available on the board via its UEFI settings, here are some screenshots of the settings.⁶

• Main view
• Advanced
• Advanced -> ACPI
• Advanced -> CPU configuration
• Advanced -> Super IO configuration
• Advanced -> Serial port 1 configuration
• Advanced -> SMART Fan Control
• Advanced -> Trusted Computing
• Advanced -> NVMe configuration (no device connected at time of screenshot, oops)
• Advanced -> Power configuration
• Advanced -> USB configuration
• Advanced -> Serial Port console redirection
• Advanced -> SDIO configuration
• Advanced -> Realtek PCIe Ethernet controller
• Chipset
• Chipset -> System Agent (SA) configuration
• Chipset -> Device configuration
• Security
• Security -> Secure Boot
• Boot
• Save & Exit

Conclusion

If the LattePanda IOTA with its adapters fits your project requirements, you’re aware of its limitations, and the price is right, then I believe it’s a solid choice for your next project. My testing didn’t immediately break it, even when I forgot to remove the plastic film on one of the thermal pads.

The current pricing of it and its accessories seem to be roughly in the ballpark of the Raspberry Pi 5 8GB (based on prices in Estonia). Boards like the Zimaboard 2 (have not tested it myself) are more expensive, but they’re also catering to a slightly different audience and have better specs, like 2.5G Ethernet ports and SATA ports with power delivery suitable for running two 3.5" hard drives straight from the board.

It’s hard to beat the bargain that you can get from a used mini PC or NAS, but it won’t come with the charm, low power consumption and bragging rights that a single board computer gets you, especially if you’re using it for an off-label use case like I am.⁷

In the meantime, I’ll keep rocking it as a home server. In case something noteworthy happens, I’ll update this post, which is brought to you by the very same LattePanda IOTA at the time of publishing.

2025-12-12 update

About a month after switching my home server workloads to it, the LattePanda IOTA is still rock solid. No issues with USB HDD stability as well.

The only complaint that carries over from the review is the fact that the active cooler is still way too loud. I’m seriously considering getting the passive cooler for it to shut it up. I can hear it from the bedroom while the IOTA is in a closet on the other side of the apartment!

I also played around with Intel RAPL settings, which allow you to control the power budget of the CPU on the fly.

The power limit is 10W by default, and short term power limit is 20W. You can control it via these toggles:

/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw
/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_1_power_limit_uw

Get current values:

cat /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw
cat /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_1_power_limit_uw

Set a new limit of 8W to both:

echo 8000000 > /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw
echo 8000000 > /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_1_power_limit_uw

These reset every boot, so you should probably set a one-shot systemd unit to call these early in the boot cycle.

The LattePanda IOTA is the most exciting yet boring addition to my setup. It just works.

Start of experiment: September 2025

Post last updated: October 2025

Check the live status of my Orange Pi Zero here!

I love the Orange Pi Zero. It’s tiny, uses very little power and it’s just neat! It’s also the subject of the very first post on my blog, which makes it a bit special.

Unfortunately I haven’t really found a good use case for it, given that its performance is quite limited and the CPU is a 32-bit ARM CPU with 4 relatively weak cores, which rules out using it as a Docker container host due to the architectural limitations.

The board is currently not doing much, but I’ll figure out a use case for it.

The board also has a few quirks at the moment that I’ve worked around. For example, rebooting seems to be broken, and it’s unlikely to get fixed any time soon. I resolved it by simply not rebooting it¹, at least not on a regular schedule, anyway. I’m hoping that any short-term power outages at home will take care of the need to reboot it.

It also runs quite hot in its stock Armbian configuration, which I worked around by running powertop --auto-tune on startup as that forces the CPU to always run at its slowest clock speed (480 MHz). Without it, I found that this board can run its CPU at 105°C, and it does have a thermal shutdown feature.

This board has been featured in a few previous posts as well, and even then it was quite underpowered:

• the little Wi-Fi AP that could
• seedbox on a wall
• database optimization adventures on low-end hardware

Now that I have it set up, will it be able to survive to year 2038 and beyond? Only time will tell.

Which issue will we run into first? Plausible options based on my previous experience:

• the cheap 8GB SD card craps out
• component on the board dies from heat-related issues
• the USB power supply dies
  • it’s currently running off of an IKEA extension cord that has two USB-A ports, so hopefully not
• board loses Armbian support completely (currently under community maintenance status)

The board is currently running the latest version of Armbian, and I might occasionally refresh its version from time to time.

If you like Armbian, then please support them! They’re doing great work with keeping all sorts of SBC-s up and running with usable versions of Debian and Ubuntu Linux.

2025-10-20 update

What are the chances that the day I make this project public, AWS suffers a massive outage? Poetic in a way. And yes, my website and the Orange Pi Zero were fully operational.

Just like most people out there, I have some files that are irreplaceable, such as cat pictures.

At one point I had a few single-board computers sitting idle, namely the Orange Pi Zero and the LattePanda V1, and a few 1TB SSD-s.

I hate idle hardware, so I did the most sensible thing and assembled a fleet of networked offsite backups for backing up the most important data.

My setup is based on various flavors of Linux, but the ideas will likely translate well onto other operating systems and solutions.

Networking

The most important part is the networking. The offsite backup endpoints connect together to my home server over a WireGuard network. The home server is, well, the server, and backup endpoints are clients.

I like this WireGuard Docker image a lot because it generates the server and client configurations automatically, but you can use plain WireGuard or a completely different networking solution to connect all the devices together. Some use Tailscale to make the setup process easier, but I like to keep things as self-hosted as possible.

I’m not a networking expert, but here’s how I’ve set up my network. For this example, the WireGuard network operates in the 10.13.69.0/24 range.¹

To only allow traffic between the devices and avoid tunneling everything through the home server, set the AllowedIPs setting to AllowedIPs = 10.13.69.0/24,10.13.69.1. We want to be able to access the backup endpoints, and nothing more.

All the devices have a static IP address in that network, such as 10.13.69.1 for the home server, 10.13.69.2 for a backup endpoint and so on.

The PersistentKeepalive = 25 option is present in the client configurations so that I don’t lose the ability to access the backup endpoints. With it, all the backup endpoints call back to the home server from time to time. The aforementioned Docker image automatically adds it to the generated configuration using the PERSISTENTKEEPALIVE_PEERS=all option. This setting is crucial. Without it, I sometimes ran into problems trying to connect from my home server to the backup endpoint, and that’s something you can’t easily alleviate without having physical access to the backup endpoints, which are offsite.

Remove the DNS configuration from generated WireGuard client configurations, as you don’t need it for this purpose.

Optionally, edit the /etc/hosts file for the home server and backup endpoints so that you can access your backup endpoints using simple hostnames, like orangepizero. Example row can look like this: 10.13.69.6 orangepizero.

if your WireGuard server operates in a network with a dynamic external IP address, as is common with many home internet connections, I recommend getting yourself a domain name that you can update whenever your IP address changes and using that in your WireGuard client configurations. Without this, an IP address change will result in your backup endpoints being inaccessible.

You’ll also likely need to set up port forwarding and/or traffic rules for your backup endpoints to be able to connect back to your WireGuard server.

Once you have the WireGuard connection set up and SSH running on the backup endpoints, you should be able to drop the backup endpoints into any network that you have permission for. Ask your friends and family, and sweeten the deal by offering free technical support or help in some other area in return. The cost of running a single-board computer 24/7 is minuscule with the typical power consumption being 1-3W, so that won’t be much of a concern.

Making backups

For making the actual backups themselves, you have all sorts of options.

I rely on rsync to copy the data over. It’s simple and it works, that’s all I expect from it. Example command: rsync -aAXvz /folder/to/back/up/ backupuser@backupendpoint:/backup/ --delete. The files will be compressed during transit with the -z option, and with --delete you’ll ensure that the target folder has all the files from the source, and nothing else.

The backup storage is specified in /etc/fstab with the nofail option present. This ensures that in case the disk dies, the backup endpoint will still boot properly, allowing me to access the machine to troubleshoot the issue and/or force a desperate reboot to try to fix things. A good alternative approach is to mount/unmount the remote disk manually as part of the backup script.

The backup storage uses the btrfs filesystem, and I use btrbk to take snapshots of the contents. If I accidentally delete all the files on the backup endpoint, then I can still recover from that situation because the data is still present in snapshots. 30 days is a good retention period: enough time to save the data in case of an accidental deletion, but short enough to avoid the backup disk getting full.

If you don’t want to use filesystem-level snapshots, then tools like restic are a good alternative. It can also operate over SSH and you can configure snapshot retention policies in your backup script. Just make sure to not lose the encryption password, and verify the backups once in a while.

Deployment

I manage my backup endpoints using some cobbled-together Ansible roles. I’ve perfected it to the point where the only manual steps are flashing the OS and setting up the storage, the rest is handled via Ansible.

I’d like to share my work here, but it will make Jeff Geerling cry. Maybe one day I’ll take the time to improve things…

Maintenance

All the backup endpoints update and reboot themselves regularly. It’s just the sensible thing to do.

Every 6-12 months I also do major OS version updates. It’s risky because of the whole offsite aspect of the solution, but so far I haven’t been burned yet.

Monitoring

Monitoring is an area where I have some room for improvement. So far, I’ve set up Prometheus node-exporter to all of the backup endpoints, and my home server keeps track of how the backup endpoints are doing.

This allows me to check once in a while if any of the backup endpoints has fallen off the network, or if the backup disk is getting full.

Issues I’ve faced

I’ve had this system running for a few years now, and it’s mostly stable! There have been some issues I’ve faced as well, though. Some are very specific to certain hardware, but I think there’s value in mentioning them.

I once blew up a backup server because of an Ansible configuration issue. That meant that I had to physically go pick up the server to re-image it.

The Orange Pi Zero was running quite hot, resulting in stability issues, so I put together a really janky cooling solution.

Hell, I did the same for the LattePanda as well.

It might look horrific but the extra cooling has fixed all the stability problems on both boards.

The lack of a real-time clock on the LattePanda has required me to make its backup script a bit special. I can’t rely on a systemd timer that automatically reboots the machine once in a while, so instead that part is present in the backup script. The issue is that the LattePanda boots up with the time being set in the past, and once it gets the actual time from the network, it will run all sorts of tasks because enough time has passed! This included the reboot timer as well.

At one point, the power supply on the LattePanda just died, and it was very visible on my graphs. That required a replacement.

Conclusion

That’s how I back up the most important data. I hope that this has given you inspiration to take your own backup approach to the next level!

A family member has a Canon PIXMA MP250 printer, originally released in 2009. It has been a very reliable piece of hardware, especially for a printer.

Then came Windows 10. The printer would not work out of the box with it and the official drivers got stuck during installation. Fiddling with the printer in device manager, trying to install drivers via Windows Update and stars aligning got the printer to work again.

Then came Windows 11. Nothing I did could get it working now, and the printer is not even officially supported by Canon on this version of Windows.

This printer works out of the box on any mainstream Linux distribution, and the family member had been using the printer with Ubuntu for years, but a certain piece of important software in Estonia was not working properly a lot of the time, which triggered a switch to Windows.¹

Quick searches online suggested that I could turn this printer into a network printer, as long as I had some patience and a spare computer.

The idea is simple: take a spare computer, hook it up to the printer, install CUPS on it, configure it and you’re good to go!

I initially tested this setup with a Zimaboard running Fedora Server, but the final solution used an old Raspberry Pi B+ running the latest version of Raspberry Pi OS.

How to set it up

The steps will be similar with other pieces of hardware and Linux distributions, you may just need to adjust a few commands and package names.

The steps are roughly based on these two guides:

• Setting up Network Printer with Raspberry Pi and CUPS
• Raspberry Pi Print Server: Setup a Network Printer

If you’re following along with a Raspberry Pi, set up your OS first. A minimal installation with no graphical interface will be just fine.

Next, install CUPS and optionally the right printer drivers for your printer. The Canon PIXMA MP250 requires the package printer-driver-gutenprint.

sudo apt install -y cups printer-driver-gutenprint

Make sure that CUPS is running.

sudo systemctl enable --now cups.service

Next, allow your user to manage printing. In this example, the username is pi.

sudo usermod -a -G lpadmin pi

Next, make sure that CUPS allows connections from other machines in your network, and then restart it.

sudo cupsctl --remote-any
sudo systemctl restart cups

Find out the IP address of the Pi and navigate to it in your browser. It will look something like https://192.168.0.49:631. The browser will likely warn you about a self-signed certificate. It’s safe to proceed.

If you haven’t already connected your printer to the Raspberry Pi via USB, then do so now.

Use the graphical interface to add a new printer under the Administration section. You’ll need to enter the username and password for your user here. It’s the same user we used earlier, so in this example it’s pi.

If you can’t find your printer model listed in the Add printer view, then you are probably missing the proper driver package, or your printer simply isn’t supported.

After adding your printer, you can use the CUPS web interface to print a test page.

If that worked, then you should now be able to use any other device on the network to print!

On Linux and Windows, open the settings section that handles printing, and add a new printer. This networked printer should appear automagically, no additional configuration required.

I also did testing using a Fairphone 5 running Android 13, and an iPhone X running iOS 16. In both cases the printing just worked.

I’ve used the scanning functionality of this particular printer on Linux and it has worked, however I forgot to test this out using this setup. I’ll try to test that out once I get the chance to try the printer out again.

Hardware tech tips

I first ran this setup with a Zimaboard to test the idea out. It worked very well, but as a simple print server it is a bit overkill.

I then replaced it with a Raspberry Pi B+, and while the printing works, I discovered that a single ARM CPU core is apparently a limiting factor during printing. A simple test page print pegged the CPU at 100%, and that’s with the 700->1000 MHz overclock applied.

If you don’t mind a slower printing speed, then any Raspberry Pi will be absolutely OK. More performant versions of Raspberry Pi will likely fare even better.

If you already have a small home server running, then you may want to hook the printer up to that and set up the printer there. It’s already running 24/7, so it would be a perfect match.

One useful aspect of this setup is that you can queue up print jobs even when the printer itself is powered off. Once you turn it on, the print jobs will start, assuming that you have enough paper and ink.

Free open source software prolongs the useful life of hardware once again. See y’all in October 2025!

2024-06-15 update

This post got featured on:

• XDA Developers
• hackster.io
• Hackaday
• Hacker News

And even the leader of OpenPrinting, Till Kamppeter, chimed in! They also held a talk about OpenPrinting at FOSDEM 2024.

Regarding scanning, seems like there’s a separate project for that called SANE - Scanner Access Now Easy.

Find out more about OpenPrinting here.

2024-11-14 update

A reader shared with me the p910nd project that can be used for a similar purpose. I have not yet tried this myself.

There’s even an OpenWRT page that describes its use on a router!

I stumbled upon this Hardware Haven video about the Zimaboard recently.

I liked it a lot.

I finally bought one.

In short, Zimaboard is a small single-board computer that is relatively affordable and comes with an interesting selection of ports, which includes an exposed PCI Express port.

Before we get down to the build, here’s a list of aspects that I want to see in my dream home server:

• low power usage (2-15W typical power usage)
• 8GB of RAM or better
• enough performance to run my workloads, most of which are containerized
• 2x SATA or NVMe SSD slots, plus option for a third drive for the OS
• passively cooled and completely silent
• compact size
• gigabit Ethernet or better

You might be thinking, “Wait, that’s your dream setup? No clusters of machines, Threadrippers, 10 Gigabit networking, crazy number of disks?”. Well, yes. After years of trying all sorts of setups and learning about my home server usage patterns, this is the set of requirements that finds a balance between performance, efficiency and silence.

Basics

I recommend checking the product page to see the exact specifications. The configuration I bought was the 832 model: 8GB of RAM, 32GB of eMMC storage and a quad-core Intel Celeron N3450 CPU. It’s not the most powerful setup or even a recent one with the CPU being from 2016, but it’s just powerful enough to fit my needs.

This variant of the board costs 200 USD, but other configurations cost much less than that, I just needed the extra memory to be on the safe side. If you don’t care about the noise and size aspect of home servers, then you can get a better deal on the used market (see the TinyMiniMicro project for inspiration), but as you know by this point, I care about those aspects a lot.

The package

What sets the Zimaboard apart from other single board computers is how polished the product feels. Unlike a board like the Raspberry Pi, this one comes with a case and a cooling setup already attached to it. I suspect that a similarily configured Raspberry Pi 4/5 with all the accessories added on top would result in a price that’s quite similar to the cost of a top-of-the-line Zimaboard.

The heatsink looks great and is practical at the same time. Under the most torturous loads I could only see the CPU being around 72°C and due to it being passively cooled it made absolutely no noise. With the case being present, I do not have to worry about placing the board on my desk and scratching the table or shorting something out.

The board does not seem to have a power button, but by default it’s configured to power on as soon as you connect the power supply, which is great if you’re going to use this as a home server.

The box that the board was shipped survived and overall I’d say that the packaging is good. The board comes with some stickers and a single SATA data+power cable. The included power adapter comes with EU, US and UK plugs all included.

Shipping to Estonia was quite fast, taking just 10 days. The shipping costs were 18 USD.

Storage

The included 32GB eMMC storage is fine for hosting your operating system. The read speeds cap out at around 175 MB/s and the typical write speeds I observed were around 50-100 MB/s. The storage is identified as mmc-BJTD4R_0xc7d04e40 under /dev/disk/by-id/, and searching online suggests that it’s a Samsung chip.

Because this board offers two SATA ports, I also added a SATA Y-cable to my order (4 USD) so that I can take my existing Samsung 870 QVO 4TB SATA drives and move my home server setup to this board.

Allegedly this cable can also be used to drive two 3.5" hard drives powered by the board itself according to the shop page for the Y-cable, but I suspect that at that point you’ll be pushing the limits of the 12V/3A power adapter.

There is also a white drive activity LED placed near the SATA power connector on the board. Perhaps not for everyone, but I like the aesthetic and the sight of the server doing server things.

The performance of the SATA ports is what you would expect. When performing read operations on both SSD-s I saw the maximum total transfer rates hover around 900-950MB/s, which is pretty close to the SATA III transfer speed limit.

There is no native way to mount the two SATA drives to the Zimaboard. The creators of the board do sell a metal bracket, but it doesn’t seem to integrate that well to the board. However, there exists a 3D printable design that houses two 2.5" drives, even 15mm ones, and that’s how I ended up using a 3D printer for the first time in my life. The print was done using a Voron v2 Afterburner printer hosted at k-space and it came out pretty well.

The SSD mounting holes were a bit finicky due to slight printing errors, and during my first installation attempt I forgot to put in the plastic middle layer of the case that’s between the PCB and the stock bottom cover, but other than that the installation was a breeze.

The drives never hit above 64°C, which is absolutely okay for these SSD-s. I’m not sure how actual spinning hard drives might fare in this environment, but I don’t think that it’s going to be that serious because 2.5" hard drives should not generate as much heat in the first place.

Power consumption

What I love about this board is the power usage. At this point my home server is not even the most power hungry component of my setup, that honor now goes to the ISP-provided router/modem combo box that always draws at least 12W, even when it’s in bridge mode.

Here are my power usage measurements (measured with a simple power meter):

• idle: 2.5W
• no drives attached, CPU stress test (stress -c 4): 9.0W
• one Samsung 870 QVO 4TB SSD attached, CPU stress test: 13.2W
• 2 SSD-s attached, typical power draw in my setup (~10-40% CPU usage): ~8-9W
• 2 SSD-s attached, max load on SSD-s and CPU: ~14W

The Zimaboard, ISP modem/router box, my TP-Link router/Wi-Fi AP and my CyberPower UPS all together use at most around 34W, all combined. That’s even less than what my Dell monitor uses at reasonably low brightness levels!

These tests are not scientifically accurate, but they should give you an idea on what power consumption numbers to expect when running this setup.

Performance

I use a simple Prometheus Node Exporter + Grafana setup to view how much resources my various servers use. My home server has lately either been an ASRock Deskmini X300 based setup or an old ThinkPad T430, and something that both had in common was that the CPU usage was generally very low, mostly at or below the 10% mark. There would be bursty loads from time to time and backup processes running that bump that up, but not significantly.

Memory usage of my setup was also quite low, with all my services and containers fitting into 2GB during typical usage. With this information and some CPU performance comparisons done, I knew that the Zimaboard will likely be able to handle my home server tasks.

This board is not very powerful, but if you mainly rely on containerized workloads and can rely on Intel QuickSync to accelerate media transcodes, then you’ll be just fine.

I was actually impressed with how well the GPU-accelerated transcode worked on this machine once you set everything up properly. If you’re running Linux and Jellyfin, run vainfo to get a list of supported codecs and make sure that you have hardware decoding selected for those in Jellyfin settings. Also enable hardware encoding. I checked with intel_gpu_top to see if work was offloaded to the GPU and saw activity there, which means that hardware acceleration for Jellyfin worked out great! Check the Jellyfin hardware acceleration for more details on other requirements that have to be met for all of this to work.

Caveats

The Zimaboard does ship with a Linux-based OS called CasaOS. However, I had no intention of using it as I know what my requirements are and my infrastructure is already decently documented and set up via Ansible, which is why I can’t say how good that experience is. I also did not test Windows 10 or 11.

During testing, I noticed that the USB 3 ports can act a bit weird. The Fedora Server USB stick would not boot properly if connected to one of the USB ports, and when doing other tests with external USB storage I noticed hiccups from time to time. Not sure what might be the cause, but I’m writing it down nevertheless. It’s not a dealbreaker for me luckily since I don’t rely much on the USB ports in typical use anyway.

I did not test the PCI Express port, simply because I don’t need it, yet. It’s a great addition, though, and opens up plenty of modding capabilities in the future.

Fedora Server and btrfs

The Zimaboard gave me an opportunity to start fresh with my home server.

I made a leap: I’ve ditched ZFS and am now running Fedora Server with my storage being on a btrfs RAID1 setup, snapshotted and backed up using btrbk. It was a bit tricky to migrate and set everything up regarding backups and snapshotting, but I got it working.

ZFS is great, but it has always felt like an unwanted guest in the Linux ecosystem. The kernel developers don’t care much for maintaining compatibility with ZFS since it’s not in the kernel due to licensing issues, and Ubuntu has been one of the few distros that actually ships a kernel that includes ZFS built in. I didn’t want to be tied to Ubuntu forever, especially because of how they try to make snap a thing. ZFS DKMS builds are generally okay on distros like Debian, but on others you might find yourself not being able to access your data after a reboot because of a kernel update.

btrfs has had some issues in the past, especially with the RAID5/6 setup, but in my single and dual disk setups it has been solid for years, except for that one time around 2018-2019 when I ran btrfs RAID1 over USB storage. To be fair to btrfs, that was a pretty stupid setup.

Before committing to btrfs, I used two USB sticks to create a RAID1 setup and created real torture test scenarios. Tests looked something like this:

• write a file to the filesystem
• use md5sum to calculate a hash of it for verification purposes
• completely wipe one USB drive with dd
• run md5sum to calculate the hash again (it matched every time)
• run btrfs scrub on the filesystem to fix all errors
• rinse and repeat with variations to this setup

After doing all that, I was quite confident that this was going to work.

One thing to note with btrfs: if you’re running any type of multi-disk and redundant setup like RAID1 or RAID10, then make sure to include the mount option degraded in /etc/fstab so that you can still mount your filesystem if one or more of your drives fail. If you lose too many drives then it’s still probably going to fail to boot.

Here’s my /etc/fstab setup to serve as an example:

LABEL=turbo /turbo      btrfs subvol=turbo,compress-force=zstd:1,ssd,degraded,nofail            0 0

When doing the migration I kept all the paths the same, and each ZFS dataset was recreated using btrfs subvolumes, which is why this filesystem is mounted on a top-level folder.

Alternatives

My notes for the next dream home server setup included a few candidates:

• the Zimaboard

• Asustor Flashstor 6 or Flashstor 12

• a TinyMiniMicro style machine with at least two NVMe SSD slots

The first two fall nicely into my requirements for the dream home server. I picked the Zimaboard mainly because it’s much cheaper and I was already running two SATA SSD-s for my home server storage, so migrating would be really easy and I would not have to buy any new drives.

If large capacity SATA SSD-s start becoming less common and NVMe SSD-s become even cheaper than they already are, then I’ll have to look into something like a Flashstor.

Conclusion

Overall, I’m very happy with this purchase. The performance is just enough for my services to work reasonably fast, the board uses very little power and it’s silent, and it looks good on my wall.

My setup is also quite flexible, so in case I need more resources, I can get more Zimaboards and make them serve different purposes. However, it’s more likely that I’m going to discover a new toy to experiment and play with by the time I run out of resources on this one.

2024-08-20 update

I ran the Zimaboard for over half a year, but decided to switch back to the ASRock Deskmini X300.

I still love the low power consumption and the expandability, but I ended up putting more load on the system than I initially anticipated CPU-wise (running over 20 different Docker containers, some heavy). Should’ve guessed that it would happen eventually.

If it came with an embedded AMD Ryzen APU, then that would probably change things up quite a bit.

Zimaboard: still the closest thing to my dream home server, but it’s that last little bit of performance being missing that gets me. If your needs are moderate or low, then it’s still a fantastic option, if the price is right.

My eyes are now on the Asustor Flashstor Gen 2 machines. Up to 12 NVMe SSD-s plus 4 cores of AMD Ryzen goodness sounds too good to be true. Let’s see what the reviews will say once it’s out.

k-space is a hackerspace in Tallinn, Estonia, and they organized a hackathon recently. Unlike in most hackathons, in this one you could whatever you like with no expectations about building a business or coming up with an MVP, just come on down to the space and start working on your passion projects!

I had some ideas on what I could do, but a few of them would have required access to workshop tools, for which I did not have a key. I could always get one, but was too lazy to bother with it. I looked at the list of ideas that had been written down by other hackerspace members and picked the one marked as [easy]: Wire up electronic lock for workshop.

If I achieve that goal, then I don’t have to worry about getting another key, and I could also get access to all the workshop tooling! And since it was marked as easy, I figured that I could do it and have some time left over for playing around with things like the laser cutter.

Impressions

Before I get to the technical part, I’d like to say a few words about the hackathon and the organization itself.

The highlight of the hackathon was the immense sense of accomplishment that I felt. I work as a software developer at my day job, which often involves dealing with incidents, migrating services from virtual machines to Kubernetes, and sometimes from Kubernetes to Kubernetes, and anything else that comes my way. The issue with most software teams is that the products that you build and maintain are often disconnected from the real world. You don’t see the physical impact of the work that you do, and that can leave you feeling empty. Sure, you spent days switching a service to Kubernetes, but you don’t feel like you did anything at all.

During this hackathon I had the opportunity to build things with my own hands, and the door controller software doing its thing resulted in real-life actions. You swipe the card, it beeps, and you can hear the electronic lock being opened. That, and the opportunity to work on a project involving a Raspberry Pi and mounting it so neatly was very satisfying.

The hackathon crowd itself was not that big, hovering around 15 or so people. We even had guests from Germany who were really helpful, great to talk with and they provided their expertise to help out wherever possible. I loved how the collaboration worked for the rewrite of the door controller software to the Go programming language. One guy knew all about the original software and how it works but was just learning Go, and the other guy was just visiting the space and had extensive Go experience.

Although this post is mainly about my own experience and the stuff that I worked on, there were plenty of other cool projects going on during the hackathon as well. One that I really liked due to how practical it was is “the kegerator” that provided cold carbonated mate tea throughout the hackathon. It lives in an old fridge and I think the execution of it was really neat! Here’s the livestream recording where other projects are also covered.

There were plenty of refreshments available and I took full advantage of that because if there’s one thing that can get my brain working on overdrive, it’s copious amounts of sugar and caffeinated beverages. Oh, and we got pancakes as well! Peetri Pizza really blew it with the pizzas though, never seen pizzas that are this sad.

There were some small issues, such as the streaming setup crapping out at the last day during the part where we presented our work, but overall I was happy with how the hackathon turned out.

For future hackathons we probably need to do a bit more marketing and think about the dates more so that we can get more enthusiasts on board. Having our German friends around really added a lot to the event and I would like to see more knowledge-sharing between communities in the future.

Build log

Here’s a rundown of what I did during the hackathon.

There’s also a video where I talk about my hackathon work!

Whenever you see the name Arti, then that refers to my good friend who helped out a lot during the hackathon.

Day 0

The hackathon began on 27th of July at 18:00.

Everyone presented their plans and then the work begun.

I used the first evening to put together a rough plan and figure out what needs to be done. In short, the plan was like this:

• buy some quick splice terminals
• assemble the Raspberry Pi with the custom HAT that is used to interact with the card reader and electronic door lock
• install the card reader on the door
• run the networking and power cables
• connect all the cables to the Pi
• set up the card reader software
• test in production

After taking some pictures of the door lock test setup that another participant assembled, I decided to go and rest for what’s to come.

Day 1

This is the part where all the action started.

I began by taking stuff apart.

After making some additional holes I ran the cable that connects to the electronic door switch. That was easy enough.

Then I began thinking about where the Raspberry Pi door controller setup would go. The workshop is a very dusty place and it would probably need some kind of protection from it. The first idea was to custom design a 3D printed case or customise an existing design, but after a short discussion and brainstorming we realized that getting a plastic box big enough to house the Pi and all the wiring makes more sense.

Me and Arti set off to find something like that in the hackerspace. After going through lots of boxes and shelves, we stumbled upon two metal boxes. Those boxes used to house some kind of security equipment and had inside circuitry that converts 220V AC to 13.6V DC, which was ideal for our use case. It also had leads to connect an UPS battery, which was even better!

Oh, and we also found this fun little thing.

Anyway, I went ahead and drilled some mounting holes for the Pi. We had M2.5 nylon screws and standoffs available at the space, and with some assistance from Arti I learned about the wonders of countersink drill bits.

I really liked how the mounted Pi looked. I’ve seen a ton of projects on YouTube and elsewhere with Raspberry Pi-s being modded and mounted in all sorts of ways, but doing it myself felt really good, especially since I was reusing an old metal box that had no other purpose.

I set up the microSD card with Raspberry Pi OS and figured that I could find it on the k-space network. However, I then remembered that the internal network was /16, which made the process much longer. I did not have access to the network switch, but I did end up getting acces to a Pi, it just wasn’t the one I just set up. That was a fun discovery.

I decided to go with the easy route and connect the Pi to an actual monitor and keyboard. That process ended up being faster than scanning the network for Pi-s.

I also added an UPS battery to the setup. It barely fit the enclosure and it had to be raised a bit so that the lid on the box would close properly. But it worked out really well!

By the end of the day we also had the card reader installed on the door. We contemplated putting the reader on the other side of the glass because the reader can read cards up to 9cm away, and quick tests showed that it would actually work, however we had concerns about mounting it that way, and it would look a bit too janky even by k-space standards.

Day 2

Day 2 started with me trying to figure out how to run the cables. Making a suitably sized CAT5e cable was easy and it worked on the first try and drilling a hole through plywood was also simple, but when trying to figure out how to run the power I ran into a bit of trouble. There was very little room in the junction point that I intended to use, and when my brain shorted out I asked Arti for some help (again). He figured out a way to run the additional cable while not interfering with the power cables that ran to the light fixtures.

Due to the way we decided to run the card reader cables, we had to extend the cable that comes from the card reader. For that I used a CAT5e cable and some quick splices. I later learned that using your thumb power alone is not enough to splice cables, you actually need to push them all the way in with plyers. Once that was figured out, me and Arti installed a very professional looking cable cover involving a random piece of plastic tube, zipties and screws. Not that I needed the help, Arti was just working on porting some Python code to Golang and wanted a break. He ended up making a lot of breaks, not sure what that says about the learning curve of Golang.

Now came the difficult part. I had to wire up everything to the Raspberry Pi without breaking anything. I had the photos I took on day 0, but in hindsight they were not that great since I had trouble figuring out what went where. Luckily another door controller in the space had a similar setup and I could use that as a reference point.

The Raspberry Pi HAT gets 12V input power, some of that is passed to the door controller, and then we have two leads that are connected to both the door controller and the electronic lock. If someone swipes their card and they have access to that particular door, the card reader light goes green and 12V is applied to the electronic door lock, making it open it. There’s software that controls it, but I did not have to worry about that too much because two other hackathon participants were working on that.

I had Arti check the cabling before the initial test and after a hesitant go-ahead from him we powered it on. The Pi powered on, but the card reader was not doing anything. It was supposed to do a few beeps and show a red light. Uh-oh. That’s when Arti reviewed the quick splices that I used and pointed out that they were not pushed all the way in. After using brute force (pliers), we powered it on again and it worked!

The rest of the evening was spent testing out the card reader software that was being ported. That revealed a few issues, but we did get a successful door opening!

At this point I was very happy and I think half the hackerspace heard that.

Day 3

At this point I was quite tired, but I felt really accomplished. I assembled the setup without burning everything down, and I only shorted out the UPS battery once after absent-mindedly connecting the same alligator clip to both power leads. Whoops.

I spent that half-day cleaning everything up and mounting the power and networking cables to the wall. I also labeled the box so that we know what that mysterious white box is and where it gets its power.

At 14:00 the hackathon timer ran to zero and we were wondering what would happen with the countdown. Well…

I presented my work, listened to what others were up to, and then we got some creative awards. Arti, the guy working on the Golang port of the door controller software, got “K-SPACE Certified Go Developer”, and I am now a “K-SPACE Certified Licensed Electrician”. Whoo!

I’d like to thank everyone who organized the event, and Arti Zirk for helping out with the project on many occasions!

That was pretty much it!

As with many homelab experiments around 2022/2023, it all started with Raspberry Pi-s being either out of stock or absurdly overpriced.

I once noticed a listing for a LattePanda V1 on a local auction site. The price was reasonable at 45 EUR, and after I looked at the specifications, I had to get one to play around with.

The auction site usually sells used items, but this LattePanda V1 was brand new in box, which surprised me. I got the 2GB RAM/32GB eMMC option.

I put the LattePanda through its paces, and here’s what I learned.

Please note that my use cases are more on the software side, I did not try out the hardware capabilities that SBC-s are also associated with (GPIO, camera/display ports etc).

The hardware

What makes the LattePanda V1 special is that it’s based off of an x86 CPU. Mine came with an Intel Atom x5-Z8350. 4 cores, not very fast ones, but similar or better to what you’d find in a Raspberry Pi 4. Most single-board computers usually come with an ARM-based CPU.

The board behaves like any normal PC. You power it on, you see the LattePanda logo, and the OS just starts up. Smashing the “Delete” key during the boot will direct you to the UEFI settings. Since this board is marketed towards the technical crowd, it has so many settings that you can play with. Definitely more than what I’d know to do with.

The board comes with Windows 10 preinstalled. I booted it up and gave it a go, and it was slow as molasses while it downloaded the latest updates. At one point I reinstalled Windows 10 and ran into issues. It “works”, but I had trouble getting any Intel GPU drivers installed on it, which rendered it almost useless for any media playback use case that I could have used it for.

The port selection is okay. It comes with 100 Mbit/s Ethernet, one USB 3.0 port and two USB 2.0 ports. I could get around 350 MB/s out of the USB 3 port with an external SSD, and the USB 2 ports pulled anywhere between 15-40 MB/s, depending on my luck. If you fancy a gigabit connection, then an USB-to-Ethernet adapter might do the trick.

Adding one external HDD or SSD over USB is okay and works well, but after adding a second one I noticed issues with either one of the disks not receiving enough power. If you intend to use the LattePanda V1 as the brains for a cheap NAS, then use drives that are powered externally.

The eMMC storage on the board is decent. Regarding performance it’s somewhere between a hard drive and a proper SSD, and the sequential read speeds max out around 150 MB/s. My main concern with it is the durability. The eMMC chip is probably hidden behind the metal shielding on the board and replacing it (if that is even possible) might turn out to be tricky. ls -lah /dev/disk/by-id/ lists the eMMC chip as mmc-DA4032, which a little bit of Googling refers to it being a SanDisk chip.

The microSD card port works, but either booting from the microSD card is not possible or the board was a bit temperamental when I gave it a go with Ubuntu Server 22.04.

The board runs hot in its barebones configuration, any decent load over a longer time period will result in the CPU throttling itself. I recommend rigging up a metal heat sink to the bottom of the board to avoid throttling and stability issues under very high load. A thermal pad, a piece of metal, and a bunch of zip ties will do wonders.

The Linux experience

When experimenting with Linux, I found a couple of annoyances. The LattePanda V1 seems to have a display connector on board. However, in Linux it turned out to be an annoyance as the system always presented a 1024x768 display being connected to the system. Booting into a Fedora Linux liveUSB environment will lead you to staring a blank view with only the wallpaper present. Playing with settings in UEFI did not lead to any improvements. What works is adding a kernel parameter: video=DSI-1:d. With Fedora Linux, if you apply this fix in GRUB when first booting into the liveUSB environment, it will persist after the installation is done.

Once I had Fedora Linux booted up, I did not have a good time. The display flickered when I dragged the mouse near the edges and the performance was awful. It didn’t take long for the desktop session to crash.

One of the main reasons I wanted to experiment with this setup was the low power usage of this board. The LattePanda V1 idles at around 3 watts, and under a high CPU load generated with stress -c 4 I could get it to 5-6 watts. This made it a great candidate for running this website and Wireguard VPN 24/7 at home. I ended up installing Ubuntu Server 22.04 on it and actually ran this website off of it for about a week or so.

The reason I stopped using the LattePanda V1 for that purpose was the performance. The 100 Mbit/s Ethernet wasn’t a disaster, but it did set limits to how much traffic I could push through the board. What made me reconsider was the CPU performance. Simply put: SSL encryption speeds were about 5-10x slower than on my ThinkPad T430 that ran as a server before.

My performance testing wasn’t scientific or anything, but I did run simple tests. One of the involved running curl against resources, such as an image on my blog, in an infinite loop and over multiple threads. The ThinkPad T430 peaked at around 650 Mbit/s of network bandwidth while the LattePanda V1 struggled at around 60 Mbit/s.

After looking for some other benchmarking options that I could set up really quickly, I also gave ApacheBenchmark a go. This more-or-less confirmed my findings and the requests per second results are the following:

• ThinkPad T430: 301.72
• LattePanda V1: 55.86

The LattePanda V1 was over 5 times slower in that test. With a slow internet uplink this might not matter much, though.

I ended up putting the T430 back in service after doing more calculations. One idea I had with the LattePanda V1 was to have that run 24/7 due to its low idle power usage and have another beefy server run during certain hours. I liked that idea until I calculated the difference in power savings. Having the main server with around 12 W of idle power turn off for 6 hours and the LattePanda running at the same time would have actually increased the total power consumption of the setup compared to having the main server running 24/7.

The math will make sense if your main server uses much more power. Most desktop PC-s that I have seen idle around 35-50 W and rack-mounted servers use even more than that, so in those situations this might make more sense. Or you can whip up a solution that starts and stops machines in your homelab on-demand.

Oh, and don’t expect to run CPU or GPU based transcoding off of this thing with Jellyfin. It works okay for certain video formats and resolutions, but a 1080p H.265 video transcoded to H.264 is just not fast enough on this machine.

A suitable use case

I might change my mind at one point and give the LattePanda a go again as a low power web server. I hate unused hardware, which is why this LattePanda V1 is now serving as an offsite backup. The USB 3 port makes sense for attaching a bigger storage device and if you run ZFS, you can also send your whole filesystem to it with zfs send/receive or syncoid. I haven’t had much luck with ARM and ZFS, but with the LattePanda and its x86-based CPU I have not had issues.

Conclusion

All-in-all, it’s a neat little board that shows signs of instability from time to time. If you intend to just run Ubuntu Server on it and your workloads are not very performance critical, then it might work out well for you. Think of it like a juiced-up Raspberry Pi 4 to get an idea of what it might be suitable for regarding performance.

It did not fit the use case I intended to use it for, but I’m still happy that I could play around with this board. It was fun!

You have probably heard about the Raspberry Pi. It’s a nice little affordable single-board computer with a huge community using it for all sorts of projects.

I got my first Raspberry Pi, the Model B+, during my first year at university, which was around the winter of 2014/2015. The idea of a super tiny PC that could actually do useful things was just very fascinating to me, and I loved the way that green PCB looked.

Over the years, I’ve used that Pi and newer revisions of them in all sorts of use cases: a simple Kodi media box, a Minecraft server, a web server, retro game emulation box, and much more.

Because the goal of the Raspberry Pi was to be an affordable platform for experimentation and learning for everyone, they had to keep the costs down. This meant that the computing power that the Raspberry Pi 1 packed wasn’t much. With the Model B+, you get one ARM CPU core that you can overclock to 1 GHz, and 512MB of RAM. It wasn’t much even at the time of release, and it definitely isn’t great in 2022.

Due to the very limited performance, the use cases for a Raspberry Pi 1 are quite limited in 2022. Use cases that don’t require much computational power are often better solved by other platforms. Use cases that are actually useful to me and solve a problem I have are too much for the Pi 1. At the same time, I absolutely hate it when I have computing equipment sitting around on a shelf doing nothing. I can’t even sell this Pi, because it is not worth much any more and it has some sentimental value for me.

Taking all that into account, and looking at my parts box, I decided to give one idea a go: let’s build the slowest damn Syncthing backup endpoint imaginable.

The build

Here’s a quick rundown of the parts:

• SBC: Raspberry Pi 1 Model B+
• Storage (microSD): SanDisk 8GB that I had lying around
• Storage (USB): Crucial BX500 1TB SATA 2.5" SSD, in an IcyBox USB-SATA enclosure
• Power: official Raspberry Pi microUSB power adapter
• Networking: TP-Link TL-WN722N USB WiFI adapter
• OS: Raspberry Pi OS 32-bit (lite)
• Acoustic foam: yes.

Use case: networked offsite backup of files that I cannot afford to lose, powered by Syncthing, btrfs as the filesystem, and btrbk as the snapshotting solution.

I set the OS up using the Raspberry Pi imager due to the useful options it offered, such as automatically setting my SSH public key authentication up. Once booted, I logged in and ran sudo apt update -y. I knew what to expect regarding performance, and was still surprised at how slow things have become. Updating the system and deploying the configuration using Ansible took hours.

The 1TB SSD is formatted as a btrfs file system and mounted to /storage. For the Syncthing service, I created a separate user syncthing with the home folder on /storage/home/syncthing. The synced data will live on /storage/syncthing. Keeping the home folder on the SSD is intentional: Syncthing keeps track of application state in a database and storing it on the microSD card will wear it out much faster. The database can also be quite big if you have a lot of files to sync.

I’m not going to go into the btrbk setup in much detail, but if you’re interested in that, then I do have a write-up about btrbk. Long story short: snapshots are cool, and they help prevent data loss in case of accidental deletions.

I set up Syncthing to allow access to the GUI from over the network by changing the ~/.config/syncthing/config.xml file while the service was stopped. Just change the GUI listen address to 0.0.0.0:8384, that will make the GUI accept connections not only from localhost, but from all machines on the same network. The next step was to set a password to the GUI and check the “Use HTTPS for GUI” box, because you probably don’t want any rando messing your machine up.

The choice to go with the WiFi for networking is related to the environment this system will eventually be deployed to. Ethernet isn’t an option there.

Once the system was all set up and files were syncing extremely slowly, I kept an eye on the Pi, especially the red power LED. I had set the CPU to run at 1 GHz using raspi-config, and with both the WiFi adapter and SSD connected, I had concerns that the Pi could not supply enough power. The power limitations of the Pi are a common source for issues and that has come up in the past as well, especially with external storage connected to the Pi. However, with this particular setup this has not been an issue so far. The fact that Pi is so underpowered that it cannot even make full use of the SSD is probably a contributing factor to the overall stability.

The file sync was very slow, but at least it was working. The typical transfer speeds hovered around 1.5 MB/s. Not great, but given the fact that this setup will operate in an environment where the download speeds are typically capped around 15-20 Mbit/s, this will be more than enough.

How well will this setup work over a longer time period? Only time will tell. Just like with other disastrous tests that I have done, I’ll try to update this post whenever anything noteworthy happens.

Does this setup make any sense if you need a performant Syncthing endpoint? Hell no. However, I’m very happy that this little Pi finally has a purpose.

Alternatives

This project was about finding a purpose for an SBC I already had lying around.

If the price and availability of Raspberry Pi-s wasn’t a complete shitshow in 2022, I would go for a Raspberry Pi 4 in a heartbeat. I can’t, and that makes me and most of the Raspberry Pi community very sad. The more performant Pi-s open up so many possibilities.

An Orange Pi Zero running Armbian was something I also considered, since I had one lying around, but it was a bit too competent for the job, and I might find a better use for it eventually.

If you wanted performance, then any x86-based PC will do just fine. My recommendation is to go for an used PC, be it a laptop or a very small and efficient PC. Just keep in mind that the power usage is typically higher on these setups compared to a small ARM-based single-board computer. If a machine runs 24/7, then the difference between 2-3 W and 10-20 W will start to matter, especially when energy prices are quite high in your region.

The Orange Pi Zero is one hell of an SBC. It has served as a Wi-Fi access point for months without issues and as a testbed for playing around with MySQL.

I wanted it to be a useful device again, but had trouble finding an use case for it due to its hardware limitations. After messing around with my amateur archival work, I had accumulated some data that might be worth keeping around. Due to my network being quite unreliable and slow, I decided to go with torrents as the main distribution method. I could have just hosted the torrents on my main server box, which is what I later did anyway, but then I realized that hosting torrents is a workload that a weak machine could handle just as well.

I took a board that was left over from a shelf, grabbed some twine and nails and banged together this monstrosity:

This brave little machine runs on Armbian and hosts one Transmission instance. This instance is a mirror for some of the data that I collect as part of my archival effort. The OS lives on a 120GB Crucial SSD with the help of the nand-sata-install script that Armbian provides, and the data lives on one 4TB Seagate hard drive that is somehow still working.

The board is pressed against the metal part of an AMD AM4 socket stock cooler with the help of a thick 5mm thermal pad and solid copper wires taken from an electrical cable. This looks very janky, but the cooling performance is absolutely fantastic: 30C when idling and not more than 50-60C under the heaviest workloads.

The total power consumption of this setup is typically between the 5-10W range, which isn’t the lowest, but still acceptable. The CPU is a 32-bit one, so let’s see if this board can make it to 2038.

2021-04-02 update

The 4TB Seagate HDD decided to start a career in experimental music production and started clicking and not showing up when connected to a PC. And thus, the seedbox on a wall has been put on pause for now.

I used to work on a short-term project a while ago where the goal was to visualize some metrics that were collected from a pretty fancy smart home setup. This data included power usage of various sections of the building, temperature sensors, water usage levels and more. The data itself was collected by a proprietary piece of software that sent this data to a MySQL database. My job was to understand the data, get useful values from the binary data and visualize it.

The hardware

While testing out this solution, I started with an Orange Pi Zero that a good friend had given to me. You might remember this board from a previous adventure. This board boasts a whopping 4 ARM 32-bit CPU cores running at 1000MHz, 100 Mbps networking and one USB 2.0 port. The slow USB port means that the read speeds for any storage you attach to it will be capped out at 40 MB/s.

With all of this in mind, I still went ahead and built this monstrosity. I took a 480 GB Kingston SSD that was lying in a box and connected it to the board.

The workload

This server had two jobs: collect the incoming data from sensors to a MariaDB instance and visualize it using a tool like Grafana. The first part was OK, since the amount of incoming data was not that high and the SBC could handle it. However, I hit some roadblocks when trying to visualize it.

The first hurdle was to convert the binary values into something usable. Going by the documentation, I could figure out how to show signed and unsigned integer values correctly by utilizing some SQL magic that did the conversions more-or-less correctly. However, with other data types, such as floating-point values of varying precision and other fun formats, I could not use the same methods to perform the conversion.

The second hurdle was performance. The incoming data was put into one table, which would periodically get split up on a month-by-month basis to avoid the table getting too big. Not a bad solution, but since I was planning on using Grafana, having all the data in one table was the only sensible solution if I wanted to show data for previous months as well. This meant that I had one big table with all the important data, plus some adjacent ones that provided details for the sensor/meter type, its value type (integer, floating point, etc.) and more. Performing SELECT statements with a couple of joins proved to be a headache: the queries would trigger a full table search, which was very painful on a system where the maximum read speed of the SSD is 40 MB/s. Understandably, lookups on a database that was already at a couple of gigabytes in size and growing would be slow even for shorter time spans (30 days).

These limitations meant that in its current state, the solution was pretty limited in functionality and very slow to use as well.

The solution

I soon learned that the company behind the hardware and software of this system provides a tool which can be used to connect to the database and read the collected data, with values converted properly and sensor/meter names provided as well. And to top it all off, this thing was written in Java!

I decided to dig around in the provided .jar file using IntelliJ IDEA and stumbled upon some interesting files. These files corresponded to different data types, and also contained the logic that was used to convert the binary data to usable values. I can only guess that this conversion was made with the goal of keeping the database size as small as possible, or to just avoid users from using this data for other purposes using tools made by other companies.

There were still the performance issues to resolve. I looked into optimizing MySQL/MariaDB tables and queries and stumbled upon some useful tips and tricks. While I cannot remember the exact details, I did end up testing the different DB engines (InnoDB vs whatever they had previously), configuring various cache sizes and limits, indexes on various column types, investigating query plans and the performance benefits of denormalization.

And then it clicked.

What if I wrote a small Java service that would handle the data conversion and put all the data into one table that holds only the relevant data and has the correct set of indexes set up? The service would periodically check the main table that collected all the data, select the results, convert the value into something that a human can understand, and then insert it into a new table that is optimized for read performance.

After hours of work, I had this Java service up and running on the underpowered server and started testing this solution. Queries that would previously take minutes to run, would now finish within seconds. Even queries with a time window of 90+ days would still finish within 5 seconds. This improvement in performance is further amplified by the fact that Grafana is able to show multiple graphs at the same time, resulting in multiple queries running at the same time.

Deployment

The hardware that I tested this solution on was pretty neat and used up very little power. The total cost with the SSD included was roughly in the 100-150 euro range. However, it was decided that the deployment would be done on a more conventional machine.

I went ahead and built a tiny PC based on the AsRock Deskmini A300. The build included a dual-core AMD Athlon APU (cut-down version of a Ryzen APU), 16 GB of DDR4 RAM because it cost just as much as an 8 GB DDR4 kit did at the time, one 120 GB SATA SSD for the OS, two 512GB Kingston A1000 NVMe SSD-s for the main storage (ZFS mirror) and a cheap 480 GB Kingston A400 SATA SSD for local backups. This whole build fit in a 500 euro budget and was a bit overkill for the purpose, but the performance that you could get out of this build was insane. And to top it all off, the server itself is very tiny and energy efficient, meaning that you could stick it pretty much anywhere, and it would still run happily while consuming less than 50 watts even under the most intense workloads.

The performance optimizations that I did were a must-have on the SBC that I did most of my testing on. On this new build, however, all the bottlenecks were lifted. The CPU probably had more processing power than 20 of the Orange Pi Zero boards combined, and the maximum read speeds on the crazy fast ZFS mirror were measured in gigabytes per second. Queries that took a second to run on the old setup were now done in the blink of an eye (or in other words, measured in milliseconds).

This deployment would probably last years without any intervention from anyone, assuming that the incoming data would not grow too fast. Unfortunately the solution itself did not find much use, so I could not test this theory out. The box itself is still happily running at the time of writing.

Lessons learned

The main reason that I am writing about this experience is the simple fact that it was a fantastic challenge to try to extract as much performance out of the Orange Pi Zero based server. Getting your queries from 30 seconds down to 0.3 seconds felt like a great achievement, plus I got to revisit some database related topics that I first learned about during my university days.

This experience also shows that even low-end hardware can achieve a lot if you are aware of its limitations and can work around them with a little bit of effort. After this project, I have played around with my homelab setup a lot and have finally settled on a solution that does not consume a lot of power, but can still run all the workloads that I want to run.

I have a bad habit of testing things whenever a “good” idea pops into my head. This is a short overview of one of them.

The Orange Pi Zero is a SBC (single board computer) that has a slow 32-bit ARM 4 core CPU, 512MB of RAM and no display output. It’s actually quite OK for many tasks, such as reverse proxy (assuming 100Mbit/s is enough for you), low-performance NAS (assuming you are fine with 10-12MB/s file transfer speeds) or a Syncthing relay. Oh, and you can also turn it into a Wi-Fi access point.

Why?

Because Armbian made it really easy to test out and I was interested in seeing what kind of performance an old USB Wi-Fi dongle could offer. This cheap AP could also come into handy in situations where my main access point dies for some reason.

How?

Go to the Armbian device page for your SBC and download the latest image, then write it to your microSD card using the tool of your choice, start your SBC and finish the initial setup.

After all that is done, start armbian-config as root. This tool allows you to do many things over a terminal UI, including a no-hassle method of setting up an Wi-Fi AP.

The option you are looking for is under Network -> Hotspot.

Follow the on-screen instructions to set everything up. After the initial setup is done, make sure to navigate to the same menu again to change the SSID and the Wi-Fi password because the defaults are horribly insecure.

After all this you should be good to go!

Issues and troubleshooting tips

It would not be a proper project if something didn’t go wrong in the process.

Before starting this configuration, run ip a to see if your Wi-Fi device is present. In my case the Orange Pi Zero also has onboard Wi-Fi, but that particular one has poor support, so I use an USB Wi-Fi dongle instead.

If your Wi-Fi device is not showing up, make sure that the correct firmware is present. In my case I had to install firmware-atheros package so that my ath9k_htc based Wi-Fi adapter would start working. dmesg and lsusb -v can help determine what chip your Wi-Fi adapter is using and what driver it needs.

The Orange Pi Zero that I have could set everything up, but it would crash hard with the logs not really showing much. After testing the USB Wi-Fi adapter in all the different USB ports with no success, I opted to use armbian-config menu System -> CPU to limit the CPU clock speed to 480MHz and set the CPU governor to performance to rule out power delivery issues that might be caused by variations in CPU power usage. That seems to have done the trick, because after that change the Wi-Fi AP has been rock solid.

Testing and conclusions

After setting it up and tweaking it a bit I started testing this thing out. The AP had no major issues throughout the day and did not crash.

The performance, however, isn’t anything to write home about. Speed maxes out at 30Mbit/s and is generally lower than that, especially when more than one client is connected. You can do things like Steam Remote Play (stream your game over your home network), but the quality will suffer. It was still quite fun to mess around in GTA V regardless of the image quality and during ~1h of play time there were only 4-5 stutters that were caused by the network.

Would I use this as my main Wi-Fi access point?

Definitely not. Any half-decent router will out-perform this setup.

Can it still be useful?

Definitely. A crappy Wi-Fi AP is better than no AP.

Parts list

• Orange Pi Zero SBC (512MB RAM)
• Orange Pi Zero expansion board (adds two USB 2.0 ports)
• Cheap case for the Orange Pi Zero
• 32GB Sandisk microSD card
• TP-Link WN-722N USB Wi-Fi adapter
• Official Raspberry Pi microUSB power adapter

Update (2020-08-22)

It’s still working and is happily serving as a temporary Wi-Fi access point.

During additional testing I could also hit 40 Mbps speeds when testing in an environment with far fewer competing Wi-Fi access points nearby.

Update (2020-08-30)

It’s still running well and it seems that it won’t be a simple temporary solution after all.

Update (2020-11-30, approximately)

This setup has now been retired. It had 0 issues throughout its lifespan as a Wi-Fi access point, but I replaced it with a more standard Wi-Fi access point so that this board can be used somewhere else.

The setup did surprisingly well and even survived nightly automated updates and restarts, which can be attributed to the good work that the Armbian project has done.