I forgot to bring my portable Pi media server running Jellyfin on a family trip, but had a small selection of my ripped movie and TV show library on my portable SSD.

One dreaded part of choosing a movie or show to watch after a rainy afternoon and all other avenues of entertainment are exhausted is having the kids (especially the youngest, who can't read yet) choose a movie without the 'movie shelf' showing the movie posters/cover artwork.

This is not a Raspberry Pi Pico. Despite it's tiny size and castellated edges, this is actually a full Raspberry Pi Zero 2W.

Well, sorta. At Open Sauce, probably the most interesting encounter I had was with Jonathan Clark.

You see, I was on a Reverse Engineering panel at Open Sauce, but I mentioned on Twitter, I wouldn't call myself a reverse engineer, more like a 'guy who breaks things sometimes taking them apart, and learns many ways to not break things, sometimes.'

Since I saw some posts calling out the old (now deprecated) way to increase GTT memory allocations for the iGPU on AMD APUs (like the AI Max+ 395 / Strix Halo I am testing in the Framework Mainboard AI Cluster), I thought I'd document how to increase the VRAM allocation on such boards under Linux—in this case, Fedora:

# To remove an arg: `--remove-args`
# Calculation: `([size in GB] * 1024 * 1024) / 4.096`
sudo grubby --update-kernel=ALL --args='amdttm.pages_limit=27648000'
sudo grubby --update-kernel=ALL --args='amdttm.page_pool_size=27648000'
sudo reboot

The old way, amdgpu.gttsize, will throw the following warning in the kernel log:

Framework casually mentioned they were testing a mini-rack AI cluster in their Framework Desktop presentation back in March.

Imagine my surprise when Nirav Patel, Framework's founder and CEO, was at Open Sauce a couple weeks ago, and wanted to talk! He said they had seen my Project Mini Rack posts earlier this year and thought it was the perfect application to try out their new AMD Ryzen AI Max+ 395-powered Mainboard, as its mini ITX dimensions fit inside a 10" rack.

I've been playing with Meshtastic a lot, since learning about it at Open Sauce last year. I'm up to 5 little LoRa radios now, and I'm working on a couple nicer antenna placements, so I can hopefully help shore up some of the north-south connections on the MeshSTL map.

To better understand the protocol, I wanted to visualize Meshtastic communications using SDR (Software Defined Radio). I can do it on a Mac or PC, just setting GQRX, SDR++, or SDR#, and watching the LongFast frequency centered on 902.125 MHz:

Growing up, I remember recording CRTs with any camera was an exercise in frustration. You would either get a black bar that goes across everything, a slowly moving 'shutter' of darkness over the screen, black frame flickering, or even a variety of bright artifacts, especially when moving the camera around.

Just setting your camera's shutter speed to match the refresh rate somewhat closely is usually enough to make it at least bearable (I start at 1/60th and see what looks least annoying).