I go by LxveAce and everything I make is open source.

I got sick of every board on my bench needing its own flasher. The Flipper had qFlipper, my ESP32s had like five different web flashers, and none of it talked to anything else. So I built one app to run all of it, with the devices able to actually communicate. On the Flipper side it flashes the custom firmwares through qFlipper. The point is the Flipper stops being a silo. It's in the same dashboard as the ESP32 stuff, and you can pass targets and results between devices instead of them living in separate apps.

doesn't have to run on a laptop, either. There's a Pi build, so if you're putting a It Flipper into a cyberdeck or a portable rig, this can be the thing that actually runs the setup, and there's a web mode if you'd rather drive it from your phone.

There's also a standalone flasher and a headless version for screenless setups, plus some smaller bits. All open source.

Links:

- The app + downloads: https://cybercontroller.org

- Source: https://github.com/LxveAce/cyber-controller

- Discord: https://discord.gg/lxveace

(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 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?

Been building this in my desk for a few weeks. It’s a Bluetooth speaker I made from scratch that grabs the album art from whatever song you’re playing and displays lights accordingly. It’s been a great addition to my desk setup. Still just a prototype but just finished v2 and wanted to see what you would change.

I’m working on this project here, and it has been a lot of fun. Some things were never really planned, but worked out surprisingly well.

In this video, of course, the Raspi doesn’t RUN the games shown on the 720x720 screen. But I still think it is kinda funny that it is possible to PLAY them with a Raspi Zero 2 W at over 30 FPS. The game is streamed low-latency over WiFi/internet, then forwarded via SPI over the GPIO pins to this little low-power hardware.

The video comes from the host PC, which has the GPU and renders the game. The Pi acts more like a network/input bridge here. It receives the stream, pushes the encoded video data to my decoder board, and sends input back to the host.

I wanna try to build an open-source, battery-powered handheld device like this. Maybe a simple gaming pad with PlayStation-controller-style input.

Originally, I was trying to build something more like a communicator, with the goal of a real Linux phone-ish device. But I was honestly surprised that I was able to make this work with Windows as well. Just to make it clear: Windows is not installed on the Pi. It is streamed to it. Under good circumstances, it feels native and very responsive, even over the internet.

I use the Pi’s capabilities wherever I can. GPCLK0 on GPIO 4 feeds my decoder with a clean enough clock. The encoded video stream goes over SPI at up to 64 MHz, but it can be much lower and still be sufficient. I also use I2C for the backlight driver, turning it on/off and adjusting brightness, plus touch input. Basically, my Python code handles all this on the Pi side.

For those who don’t know: with raw pixel data, this would not work at this resolution and frame rate over normal SPI. A 720x720 frame has 518,400 pixels. At 64 MHz SPI, raw RGB565 would only be around 7.7 FPS max, and raw RGB888 would only be around 5.1 FPS max, before any overhead. So the trick here is video compression.

A simple way to explain it is BMP vs PNG. Both can show the exact same image, but BMP stores raw pixel information, while PNG uses tricks to make the file smaller. My setup does something similar in spirit: it avoids sending full raw frames whenever possible.

I also bitbang some GPIO pins for JTAG to flash firmware to the decoder, which is the little square board.

Let me hear what you think. Ask me questions. I know there are plenty of ways to attach a display, be it HDMI, DSI, normal SPI displays, etc. But I like the idea of using a simple serial protocol and a small low-power decoder board.

Building an IR blaster on a Raspberry Pi Zero 2 W to control my AC. The receiver I can read my Carrier remote and capture codes fine. The transmitter won’t emit any IR.

What I’ve already confirmed:
• ir-ctl -f -d /dev/lirc0 reports the device can send raw IR (carrier, duty cycle, etc.)
• Sending runs with no error: ir-ctl -d /dev/lirc0 --send=power.txt
• The capture file is valid (full +/- pulse data)
• Checked the IR LED on a phone front camera — no flicker at all
• Swapped in a fresh IR LED — still nothing
• Transistor pinout confirmed C/B/E, emitter is grounded
So software + Pi side seem fine; I think it’s something in the breadboard wiring I can’t spot. Photo attached. What am I missing?

This is a kit being sold for $240 on which you can attach a Raspberry Pi CM5 and it becomes a fully functional Blackberry like phone with manual buttons. There are some adaptors you can buy separately to add in other functionalities. Source: https://youtube.com/shorts/X58R0j4aEWA

I built this because I wanted a dashboard for my homelab that actually looked like ink on paper, not just another glowing screen. It runs on a Pi Zero. But because I absolutely refuse to SSH into a headless Pi every time something breaks, things got a little out of hand. I ended up writing a custom Wi-Fi recovery portal and a CI pipeline to build ready-to-flash images. The repo is open-source if anyone wants to steal the code.

Here is the breakdown of the build and why I over-engineered the hell out of it.

The Hardware

• Brain: Raspberry Pi Zero W (small enough to hide).
• Screen: Waveshare 2.9" Tri-colour (Black/White/Red) e-paper module.
• Sensor: AHT20 (I2C temp/humidity sensor).
• Wiring: I skipped the plug-and-play HATs because they cover all the GPIO pins. I wired it bare-metal—SPI for the screen, I2C for the sensor—so they could share the board and fit inside a custom case without colliding.

The Over-Engineering (Fixing the annoyances of IoT)

I hate dealing with headless smart devices when things break, so I spent most of my time fixing the classic Raspberry Pi friction points:

1. The "Changed My Router Password" Problem Usually, if a headless Pi can't find the Wi-Fi, it just dies silently, and you have to plug in a keyboard or re-flash the SD card.

• My fix: On boot, InkNode tests the connection. If the internet is down, it halts the boot, spins up its own temporary Wi-Fi Access Point, and physically draws a QR code on the e-paper screen. You scan it with your phone, hit a local web portal, type in your new Wi-Fi credentials, and it safe-boots.

2. The "Spaghetti Code" Problem: E-paper is incredibly slow to refresh. If your code waits for a weather API to respond before updating the screen, your device freezes.

• My fix: Total decoupling. A background thread handles the network polling and fires lightweight plaintext telemetry directly to my MQTT broker (for Home Assistant). A separate Python Hardware Abstraction Layer (HAL) handles the screen, pulling the latest state from memory so the UI never blocks.

3. The "List of Terminal Commands" Problem I didn't want to run sudo raspi-config and pip install Every time I messed up my SD card.

• My fix: I built a CI/CD pipeline using GitHub Actions. Whenever I push a release, it grabs the canonical Pi OS Lite image, injects my Python code and cloud-init scripts into the filesystem, shrinks the image size, and spits out a ready-to-flash .img file. You literally just flash it, plug it in, and it works.

Happy to answer any questions about the hardware, the e-paper limitations, or the GitHub Actions pipeline!

Hello everyone I am 3rd year undergraduate student completed 100 days 100 iot project with Micropython

Also published two Micropython Libraries and one Arduino Libraries

Also build picodesk

As a student I have no such money to buy a raspberry pi

Can anyone send a raspberry pi for free

Here is my works

https://github.com/kritishmohapatra/100\_Days\_100\_IoT\_Projects

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.

I made this over the last few months. It’s an automated Magic the Gathering card scanner and sorter. For now it’s just a working prototype, but eventually it may stand on its own. What do y’all think?

https://youtu.be/9JX8J1ihZH4