> Once I had the design [of the enclosure], I tried to 3D print it on my brand new 3D printer, which turned out to be a disaster. Took me some time to learn more about designing for manufacturing, especially for 3D printing.
Would have been nice to hear how specifically it was made to work in the end.
> Turns out, cross-fading two 4MP images at 60 frames per second on a moderately powerful single board computer is not so easy.
Yeah, at first it feels stupid that every pretty LCD screen for bus or train stops, ads or whatnot has a full computer behind it, but then you ballpark the memory bandwidth and realize you need a ~ 1 GHz device anyway just to be able to chew through the pixels fast enough. (1920² px × 24 bpp × 60 Hz = 620 MB/s.) You also realize why “fill rate” used to be such a buzzword 20 years ago and why it took a while until true color became ubiquitous.
On the flip side of the O(n²), you can easily drive a watch-sized display with pretty good ppi using a 32-bit MCU, which is why the Apple/Google/Samsung battery-guzzling approach to smartwatches seems wrongheaded to me compared to Pebble/Zepp/etc.
markb139 2 hours ago [-]
Way back in time (1980s) I worked in the broadcast tv industry.
We used to used digital still stores. A single frame of PAL took up 1MB of RAM. The machines had 2MB fitted. The board had a hardware cross fade function implemented in discrete logic chips. They also had a 20 or 40MB scsi drive. It was all controlled by a 6809 cpu. Quite impressive for the time
skippyfish 60 minutes ago [-]
Large displays are not driven by a general-purpose CPU that bit-bangs a single serial data line, and never were. They're driven by separate circuitry with direct memory access, often integrated on the die of chips meant for these applications. The actual bus to the display controller may be a parallel dot-clock RGB bus, or an ultra-speed differential multi-lane serial (MIPI DSI, HDMI, etc).
And train stop displays certainly don't need 60 fps.
The main constraint for high-resolution displays is memory, not CPU clock speed. Your (odd) 1920x1920x24bpp frame buffer takes up more than 10 MB.
interfeco 3 days ago [-]
Hey HN,
I've finally finished my dream music streamer featuring a vinyl-sleeve-sized square display, a custom carrier PCB for a compute module and a 3D printed case, running a custom-compiled kernel, Alpine mini rootfs and a small C app driving the display.
I did not think that this was doable by a hobbyist at all, let alone using free/open source software only (KiCAD, FreeCAD, VSCode). Turns out I was wrong!
dgellow 2 hours ago [-]
Congrats, that looks really neat :)
Do you have plans to make the project open source?
yenepho 2 hours ago [-]
This is super cool! Thanks for sharing :)
oinoom 2 hours ago [-]
very clean and well done!
dsign 46 minutes ago [-]
A bit tangential, and in the topic of nostalgia for old ways, remember when every block had a photo shop? Couldn’t we get a “PCB shop” in our bright near future? I wonder if the density of enthusiasts that need PCBs made is so low that the entire market is captured by only one or two companies based off China subject to the realities of shipping times.
kubb 55 minutes ago [-]
> I was able build an out-of-band protocol extension into my audio player app
I wonder how that works.
interfeco 31 minutes ago [-]
Easier than it sounds: the app runs a simple http server that serves cover art by track id. The track id is transferred via iOS's built in "Now Playing" metadata fields, which is then used by the device to construct a query and fetch the full resolution image.
jdsfijfdsifs 1 hours ago [-]
[dead]
Rendered at 16:48:35 GMT+0000 (Coordinated Universal Time) with Vercel.
Would have been nice to hear how specifically it was made to work in the end.
> Turns out, cross-fading two 4MP images at 60 frames per second on a moderately powerful single board computer is not so easy.
Yeah, at first it feels stupid that every pretty LCD screen for bus or train stops, ads or whatnot has a full computer behind it, but then you ballpark the memory bandwidth and realize you need a ~ 1 GHz device anyway just to be able to chew through the pixels fast enough. (1920² px × 24 bpp × 60 Hz = 620 MB/s.) You also realize why “fill rate” used to be such a buzzword 20 years ago and why it took a while until true color became ubiquitous.
On the flip side of the O(n²), you can easily drive a watch-sized display with pretty good ppi using a 32-bit MCU, which is why the Apple/Google/Samsung battery-guzzling approach to smartwatches seems wrongheaded to me compared to Pebble/Zepp/etc.
And train stop displays certainly don't need 60 fps.
The main constraint for high-resolution displays is memory, not CPU clock speed. Your (odd) 1920x1920x24bpp frame buffer takes up more than 10 MB.
I've finally finished my dream music streamer featuring a vinyl-sleeve-sized square display, a custom carrier PCB for a compute module and a 3D printed case, running a custom-compiled kernel, Alpine mini rootfs and a small C app driving the display.
I did not think that this was doable by a hobbyist at all, let alone using free/open source software only (KiCAD, FreeCAD, VSCode). Turns out I was wrong!
Do you have plans to make the project open source?
I wonder how that works.