Hey everyone!,

A while back, I shared a very early version of a project I have been working on.
Today, I’m incredibly happy to showcase the Alpha 1.0.0 Release of Atomic Launcher—a "Steam-like" platform built specifically to distribute, showcase, and play Pygame games.

My ultimate goal/wish would be to make it truly community driven. That being said I will be posting all my future pygame projects to the platform. Check out the source code, download the alpha, or submit a PR here: https://github.com/mironczuk-dar/Atomic-launcher.git

What's New in Alpha 1.0.0?
I’ve moved far beyond the basic launcher script. The platform now features:

• Zero Dependencies / Portable Setup: No Python or Git installed? No problem. I packaged portable Python and Git right into the release. It’s a literal one-download ZIP or one Git clone. Just extract and double-click the .bat file (Windows) or run the .sh script (Linux/Raspberry Pi) and you're in.
• A "Steam-like" Storefront: A dedicated, polished "Featured" tab to highlight community games.
• Media Previews: Game pages now support full image and video previews so players can see gameplay before downloading.
• Control Filters: Users can instantly filter games by input type (Mouse-only, Keyboard, Gamepad) to find games that fit their setup.

I just implemented a new manual focus assist mode for my camera using picamera2 and opencv. It’s a selective focus peaking mode that’s less distracting than full screen focus peaking. It’s still a work in progress and would love your feedback.

(Pi 3b+)The thesis for this project is both simple, and a fun challenge: Design a model that only relies on locally gathered data, to predict severe weather events with minimal false negatives and an acceptable level of false positives, then put it all into a box that 'just works' when plugged in, unlike many 'smart' devices sold today.

I once bought a meat thermometer. I opened it to use on the Christmas roast, and the app greeted me with "we are happy to have been a part of your cooking experience. Unfortunately, as of <date 4 months prior>, our servers are shutting down."

Panicking about the tight timing of christmas dinner and cursing the God who made me, I ran out to get an emergency thermometer because <local big box store> sold me a brick! 

I got my money back eventually, but it's given me a vendetta against any machines or services that require offsite hardware, or require some company to pay their bills to work.

On June 10th, a major wind storm came to my city. That storm was powerful enough that it knocked all the NWS ASOS stations near me offline for a few days. Remembering my vendetta, and eyeballing the cheap Amazon-special weather station i recently acquired,  the seeds of an idea formed.

The result of that idea is Weather Station Alpha: A self-contained forecasting box that predicts seven distinct severe weather hazards across 1-hour and 24-hour horizons, using local sensor data only.

 The hardware sits inside a metal project box running neural net inference on a schedule, with an SDR, LEDs, a barometer, and its own cooling fans, so it runs at the absolute limit of what the Pi's power supply can handle. Any more overhead and this little guy undervolts. Ask me how I know.

I wrote five services to orchestrate the ui and api, sensor data pipeline, machine learning pipeline, active cooling, and physical LED status animations.

The prediction engine runs an LSTM neural net with attention, trained on 30 years of official NWS data. To resolve prediction confidence, the system blends a 500-pass Dropout Monte Carlo simulation 50/50 with a distance-weighted K-Nearest Neighbors algorithm. The Monte Carlo engine generates randomized path variants to simulate realistic transitions, while the KNN uses the network's N-1 layer as a vector embedding space. 

This acts as a real-time learner, and is the real strength of the system: when local anomalies or sensor quirks arise, you can flag the timestamps in the admin to inject new example vectors, teaching the box about local climatology and sensor quirks instantly without retraining the underlying neural network.

The data collection relies on an RTL-SDR USB dongle pulling radio transmissions from local wireless sensors, combined with an on-board USB barometer. 

After I got all the bits in the box, i drilled 1/2" holes. 2 in the lid for the antenna and LED, and one in the back for power. I put rubber grommets on those holes. I also added some o-rings to the silicone diffuser, and cut a nice decal and lettering for it with my circut machine. I think it came out pretty sharp :)

After initial setup, I spent a week calibrating it against the real local data..adding and removing samples and tweaking thresholds. It was a particularly stormy week so I had good data to test against. After that week, I was satisfied with its sensitivity and dataset...or so I thought.

About a week after this calibration a funny thing happened with the real time learning...The box was giving me a "wind" warning one afternoon. I looked outside at the nice calm day...and decided this was another false positive to be corrected and tamped down. I raised the thresholds and added a none point for that time.

Whelp, 15 minutes later, a gust front came thru that was strong enough to knock some tree branches off.

I sheepishly deleted that none point and put the thresholds right back where I had them. It was then I vowed to wait a week before questioning the black magic of the box and applying corrective inputs.

Now, if society collapses tomorrow, the National Weather Service disbands, and all the doppler radars are shut down...I'll still have a decent little severe weather warning system so long as I keep that computer powered, adjust it for events it misclassifies, and change the AAs in the sensors every 9 or so months. 

No one using this box will ever get a message saying "we are happy to have been a part of your weather experience, but our servers dont exist anymore, sorryyyyy".

The entire parts list, a more in-depth explanation, and the code are open-source and ready to build, available on my github.

Project repo: https://github.com/Dominic-Muscatella/weather-station-alpha

OR, skip over the setup instructions and go right to the explainer:
https://github.com/Dominic-Muscatella/weather-station-alpha/tree/master#how-it-all-works

I have had an Alexa from way back when they launched and were all the hype. However, they always fell short of my expectations when it came to answering simple questions that I would normally ask ChatGpt. All I use them for is to play music from spotify and check weather 😅

Moreover, I wanted one that can be customized to my exact needs (like giving me a dump of the latest hackernews updates every morning). 

So I built OpenLily: An open source voice assistant that is powered by LLMs. The core agent harness is easily customizable so can use any LLM (gpt-5.5, opus 4.8, etc) with any tools (like checking emails, slack, etc). 

Running it on a raspberry pi attached to a speaker phone is trivial. Here’s a video of me chatting with one in my bedroom :) 

Here’s the repo if anyone wants to try it: https://github.com/getlark/openlily 

Happy to answer any questions.

I have just finished my latest project: restoring and upgrading this vintage radio! It had been a fantastic project to work on and I want to go a little into detail and explain how I built it.

First of all, a bit of backstory: A friend of mine had this unit in his living room as a decorative object. It was not working in its original state. That's why he had put two cheap PC speakers inside the cabinet and connected them to a equally cheap turntale with Bluetooth. As this wasn't exactly an elegant solution, he reached out to me and asked if I could restore and modernize the radio. He wanted bluetooth, (internet)radio and if possible AirPlay. All while preserving the original aestetics of the unit. So I got to work...

The first thing that came to mind was the screen. I deffinitely wanted a display that fits into the scale showing the current tuned frequency. As a screensaver, a custom VU meter in the radio's frontplate design shall be shown, so it blends in nicely with the overall looks. I ended up getting a waveshare 1280x400px touch screen for Raspberry PI.

The choice of a raspberry PI as the main computer was also pretty obvious. It ticks all the boxes spec wise, has great software support and using HATs I can expand the funcionality further.

Of course, I also need some sort of amplifier. Originally, I wanted to keep the tube amplifier inside the unit, but it consumed so much space, was extremely low power and the heat from the tube probably also would not have been that good for the PI. So I opted for a HiFiBerry AMP 2. Super efficient, high power class-D amplifier made for the RPI.

The original speaker setup also had to be replaced. The electrostatic tweaters would have sounded amazing, but cannot be driven using the amplifier I have chosen. But of course, I kept them in storage for later use. As I was on a pretty tight budget, I chose two Visation BG20 full-range drivers. They are very cheap at only around 35€ per piece and had some good reviews. This turned out to be a great descision as they really sound amazing for their price.

So that's it for the components.

Next up, software: And that was the first big challenge. There are quite a lot of options out there. I started with MoOde. Easy to set up and good functionality. But it is not very extensible. I needed a UI that works with a rotary encoder, as I could not use the touch screen of the display through the glass. And due to the architecture of MoOde, it would have taken ages to implement all that.

So after a lot of searching, I stumbled across Berryaudio: www.berryaudio.org . It is a very new media player OS, but has some very good features. And being written in python using a very extendable architecture, it was the way to go. I want to give a huge shoutout to the developer of Berryaudio, Varun Gujar, who really did some amazing work with his project. I changed quite a lot, so it suits my very specific needs. You can find my forks of the core and frontend here: https://github.com/FloTec508/berryaudio https://github.com/FloTec508/ba-frontend. Mainly, I added support for RadioBrowser, my custom button and encoder system, UI navigation using rotary encoders and some UI tweaks to fit the letterbox screen. Some of my changes are now even part of the official repo.

The first parts started to arrive and I began design and assembly.

One of the biggest hardware challenges were the source selection buttons. There are six latching buttons at the front of the unit. I wanted to use them for source selection. But there was one issue: what if the user switches source using the web interface or the screen on the device? In this case, the buttons would be out of sync with the software. Soooo, I decided to motorize them. I prototyped the first revision of the design, utilizing small 9g servos and levers to actuate the buttons from the back. That worked surprisingly well, so I refined the design and had a working mechanism.

I needed some way to control and monitor the buttons and encoders and report changes to the berryaudio core. I decided to offload the monitoring to an external STM32 microcontroller. I wrote a bit of code that continously reads the button and encoder states and creates a event "fifo-type" buffer, where events are pushed in. Once new events are inside the pipeline, a interrupt pin gets pulled HIGH to signal the Raspberry PI to request data from the STM32. I does so using the virtual serial port of the STM32 and receives a list of all registered events scince last request. This way, I only have to monitor one pin on the PI and have enough headroom for delays thanks to the event buffer. The system is bidirectional. so the RPI can send Events into the STM32's timeline for it to process. In my case this is only used for updating the button states.

All of that took a lot of tweaking and testing, during which I started building the speakers. This was my first time building speaker cabinets. After some research, I decided to use a bass reflex design. The speaker chambers originally were open at the back, so not airtight at all. Therefore, I needed to seal everything using acrylic sealing compound and wood plates where needed. I build adapterplates for the new, bigger speakers and fitted them. Inside the hole of the former tweaters I put the bass reflex tubes. I calculated their length and printed them on my 3D printer. Lastly, I added padding to all sides of the chamber and sealed them up. And to my surprise, they sound incredible! Nothing high-end for sure, but keeping in mind I paid 70 bucks for the drivers, the result is amazing! I tuned the EQ a little to get even more out of the speakers.

So all in all I am very pleased with the results. It looks, sounds and feels amazing. And my friend was impressed and happy with the results. So what do you want more?

Inspired by Pete Cybriwski's Instagram post of his RPi-based ASCII Aquarium, I set our to create my own. Like Pete, I based mine on the GitHub OpenGhost repo, but unlike Pete, I didn't write my own aquarium program. I started with the GitHub asciiquarium-pythom repo.

I forked both repos and made extensive modifications to each to create a more interactive aquarium. Through the camera, OpenGhost recognizes hands gestures for feeding the fish, triggering "Happy Fish" mode, stopping the aquarium program, shutting down the RPi, and one more hidden Easter egg mode. You can see a couple of the gestures in the reflection of my hand in the video.

My forks of both the OpenGhost and asciiquarium-python repos are available publicly. I am preparing a comprehensive instruction document and have already created an all-in-one installation script. I also redesigned the case to make it stronger and a little more aesthetically pleasing (IMHO). I expect to release everything on GitHub next week.

It’s not much but it works and I made it.

After reaching a goal of being able to mill for QFN56s with a 3020 CNC, I made this RP2040 board as a proven template for larger projects.

Two firsts for me this go around were external flash and 16 pin USB-C with data transfer, which was almost as difficult as QFN. It’s only been micro USB in the past or 6 pin USB-C for power only.

Other than that, it’s got a user LED, and addressable LED and a tiny potentiometer for testing the ADC.

I got a lot of cool ideas cooking now I have this and a proven ESP32-S3 template.