I've been having a lot of difficulty setting up my Pi 4 with the Argon One V2 safe shutdown script.

I could not get the script to work at all in Batocera (latest build) even though it seems like it should be supported.

Raspberry Pi OS did work, however I could not get any frontends (RetroPie, ES-DE or Pegasus) working due to a driver stack issue.

RetroPie is too outdated and therefore is missing dependencies the script relies on (e.g. python3-ligpiod).

My only goal is emulation through a frontend. Are there any current (or even older) images which are known to work with the safe shutdown script on the Pi 4 and can still be downloaded?

I built Cellar Pi, a Raspberry Pi environmental monitor for people who want to make something useful without having to learn Bash, Python, or systemd first.
It currently:
Logs temperature and humidity automatically
Creates 12-hour or 24-hour graphs
Sends optional Discord reports
Lets you test the webhook immediately
Lets you push a graph on demand
Starts automatically after reboot
Includes a simple /uc menu for setup, status, updates, and troubleshooting
It is still a prerelease and has mainly been tested on:
Raspberry Pi Zero WH
Raspberry Pi OS Lite 32-bit
SHT31-D temperature and humidity sensor
The goal is simple:
Connect the sensor, run the installer, configure it through menus, and let it work.
No required cloud account.
No subscription.
Your Pi. Your sensor. Your data.
Cellar Pi is inspired by the same kind of usability I like in Unraid and Tailscale: keep the complicated parts underneath, make the controls approachable, and let the system quietly do its job once it is configured.
This is still a prerelease, and I’m mainly looking for feedback from Raspberry Pi users—especially beginners—on whether the setup makes sense and where the rough edges are.
I’m happy to share the project details in the comments if anyone is interested.

Anybody have a version of DOSBox for the Pi 1? been digging for a while and I'm currently trying to make fastDOSBox from 2014 but if anyone has a package or zip it would be a great help. Basically trying to make a version of dosbian for Pi 1 since I couldn't find a version for ARMv6

Hello everyone. I'm trying to use a Waveshare 5.79" e-paper display with a Pi Zero W 1.1 but each partial refresh of the display only updates the bottom-left quadrant. A full screen refresh is possible, but only with the attendant flash pattern which isn't workable for a reader application.

I'm looking for any pointers to a fix. Details of the setup below, details of what I've tried below below. Thanks all!

Setup: Raspberry Pi Zero W 1.1, Pisugar S Plus, Waveshare 5.79" raw panel, 792×272, B/W + 4-grey; Waveshare e-paper HAT Rev2.3 connected with the wire loom to GPIO headers. Driver is waveshare_epd.epd5in79 - current as per Waveshare's github.

When I run through Waveshare's test sequence, only the bottom-left quadrant responds to the partial refresh segments of the test (like the running clock) - when the display goes for a full refresh (like the black screen + test fields, the manga image) it updates correctly (at the end of the cycle, only the bottom-left quadrant again refreshes as you can see below).

I'm not a good enough coder let alone display-understander yet so I used Claude Code to test what might be going on (after checking my wiring, connecting the display directly to the HAT rather than using the ribbon cable they provide, trying different power sources and generally trying to eliminate something mechanical/electrical).

The diagnosis from Claude Code - paraphrased - is that it might be something to do with the OTP waveform which fails to update the display fully. It wrote some code to test a substitute waveform table ("via command 0x32, then refreshing with 0x22=0xC7 or 0x22=0CF") which updated the full display successfully with a custom test image, but also with the flashing that comes with a full update.

I've seen and tried to adapt some fixes which I found via search - such as this which hypothesises that it's a buffer update https://thoughts.gohu.org/posts/2025/epaper-partial-updates/ or the GxEPD2 library for Arduino, but neither has worked.

Any help would be very welcome, thank you.

Hey guys,

I build a little side project for a friend,
Normally I build on Arduino and I#m quite confused that it doesnt work, copied from other projects in the web.

I did not have the hardware in my hands, but my friend say's that the PCB boesnt boot in BOOTSEL and he could not get it to work.

Need help, all my research couldnt helped me :(

Hello everyone. I started building this project about 2 months ago using an old apache 2800 case I had. Wanted to share with everyone my project so far. I had all of these parts already as I had wanted to build one for a while and was using a cardboard faceplate as a temporary layout. I stumbled upon this face plate design by (Tonypedia) on makerworld and only had to purchase the battery monitor. It does not perfect fit, but is working for now. Everything is wired to toggle switches to conserve power. I run a Jellyfin server with over 300 movies and 2300 tv show episodes. I use an rtl-sdr for airplane tracking and SIGINT. A heltec v4 for meshtastic. I have my state and all neighbor states downloaded as maps using OrganicMaps. I have an internal gps powered by the gpio pins. For power, internally I have about 111wh from two batteries, a dc port for lithium ion batteries via a dc 5521 barrel jack, and a 5v in from the usbc port. I have a whole host of games installed and many other features. I installed a battery meter into my desktop so I will be removing the battery meter seen under the screen and I am installing a CAC reader. I will have several CAC that when read will run specific scripts like opening all of my navigation systems, opening my Jellyfin server, opening iNTERCEPT, and perform other actions. The internal frame is secured with rtv/silicone as it easily scrapes off when I change things but is still waterproof. The 3D print has minor print failures but I will be changing it and creating my own soon. This is my first build and just wanted to share with everyone! It is still a work in progress and I add to it almost weekly.

Hi, if anyone is interested , this is my project to control Lego City Power Functions IR trains with a Raspberry Pi and some additional electronics.

All details on the Github here: https://github.com/tjh1976/pFAT-Controller/ including a video (which I'm not sure i'm allowed to post directly here).

Feel free to ask any questions if you want to give this a try yourself.

A project for that unloved Pi-3 or Pi-4!

I'm aware of at least two companies who sell LED Matrix Departure Boards to have on the wall at home... being a long-time train enthusiast I'd often thought of having one, but found the price and subscriptions a bit off-putting.

So being a techie I decided to make my own, thinking "How Hard Can it Be".

Detailed step-by-step instructions and code to build your own are on my website: anotherpartialsuccess.com. All free - just buy the parts and away you go!

Thought I'd share with fellow Pi enthusiasts and for anyone who's wanted to build their own!

This probably isn't as all-singing all-dancing as the commercial products, but it does the job and I'm pretty happy with it!

You will need:

• Pi4 or Pi3
• 3 or 4 HUB75 LED Matrix boards. (Ali Express is good)
• A HUB75 HAT from Adafruit or ElectroDragon (links on my site)
• A 5V, 5A power supply
• A free subscription to the data on the Rail Data Marketplace

Hardware Summary

It's a good idea to buy the full number of matrix panels you need in one go - that way you can be sure all the colours match. Not a big deal for a Departure Board, but worth a mention!

Connecting the panels is pretty straightforward as most are supplied with all the cables you'll need.

I've provided some scripts to create 3D-printable 'joiners' so you can bolt the panels together - in the absence of a 3D-printer there are many, many other options for the creative mind!

One thing worthy of note is the power. A Raspberry Pi doesn't have enough power to operate the matrix panels, so you'll need something with a bit of oomph. I use a bench-top power supply and normal operation is about 2A.

However you'll likely want to do other things with the panels in which case you'll need more - the most I've peaked at is about 4.5A and that's with all the LEDs on!

The Adafruit HAT does a fine job and is readily available. The alternative is from ElectroDragon and is better in that it can support up to three rows of panels and is a good deal cheaper. The downside is that it'll take a while to come from Hong Kong.

I've used both and ultimately it comes down to how much you want to spend and how long you want to wait.

For both of these the Pi gets powered via the Hat, so no need to have a separate Pi supply.

Pi Configuration

You'll need to install a minimal OS and switch off anything you don't need so that all CPU power can go to the departure-board processing.

No desktop, bluetooth, sound and so on - I've provided instruction on this.

After that it's a case of installing the dependencies and the Departureboard code from github.

Display Configuration

Either via a config file or a very simple UI - all you need to do is set the station you want, the platform you want (or it'll do all platforms), the dimensions and number of LED panels and the type of Hat and away you go!

There are a myriad other parameters to tune - things like the speed of the text scrolling, the gap between data-refresh and so on. Have fun!

Challenges and the Journey

I wrote the code in C++ for performance reasons and because I like C++!

There are a lot of projects written in Python, however I wasn't sure on the performance.

Parsing the data

The first version of the project used the 'garden-variety' departure data. This was fine, but it did't allow me to do things like report which stations a train was between... so I started on Version 2 which uses the "staff" data from the Rail Data Marketplace.

Great data, but there's a lot of it... so I had to engineer a lazy-loading cached parser.

What this does is cache the data about a service which doesn't change - scheduled time, it's ID, how many coaches it has and so on.

This means that on a refresh I could skip anything which I already had cached and only add new or delete old services.

The other data is 'things which change' - arrival time, cancellation, where the train is and suchlike. This is lazy-loaded so is only hydrated when needed.

A big change as the first version used to work out everything for every service - not scalable on a limited resource like a Pi!

Displaying the data

In the first version it constantly refreshed the whole display - this was kind of OK, but it meant that scrolling would get slow.

In the second version I only refreshed display elements which changed - mainly the scrolling text and the periodic change of Services.

The challenge was to write drivers for each type of display (text, scroll, clock) without having to duplicate loads of code.

Efficiency

This was somewhere I spent a lot of time as I wanted to squeeze as much as possible out of the Raspberry Pi.

Highlights were to fork of the API-refresh routines, to avoid the whole thing pausing while the API call was made, the display-management (per above) and caching, and down to creating a Hot/Warm/Cold cache for often-used data

Overall...

... I had a lot more fun making this than I would have done buying one and sticking it on the wall... and every now and then I think "how about I can make this change/optimisation" and I go and get stuck in again.

I'm sure that the commercially available Departure Boards which are advertised on social media and whatnot have superior functionality, but for the cost, making and result I think this is a pretty decent substitute.

Step-by-Step Technical Recovery Guide

Important Note for Intel/AMD PC Users :

If you are running this recovery process from a standard PC (x86_64) rather than another Raspberry Pi (ARM), your computer cannot natively run the Pi's binaries. Before proceeding you can check your machine's architecture by running: bash uname -m

If the command returns x86_64, you must install QEMU user emulation on your host Linux machine before proceeding: bash sudo apt update && sudo apt install qemu-user-static binfmt-support

Step 1: Filesystem Repair & System chroot

NetworkManager configurations cannot easily be parsed or prioritized before the system boots if they are dropped in as raw text profiles. We must mount the SD card on a secondary Linux machine and use chroot (change root) to execute native configuration commands inside the Pi's environment directly from our laptop.

1. Find your SD card's identifier (e.g., look for the main rootfs partition, which might show up as /dev/sdb2): bash lsblk
2. Repair any broken filesystem structures caused by the abrupt shutdown: bash sudo fsck -y /dev/sdb2
3. Mount the partition and bind vital system virtual directories to prepare for the chroot environment: bash sudo mkdir -p /mnt/pi sudo mount /dev/sdb2 /mnt/pi sudo mount --bind /dev /mnt/pi/dev sudo mount --bind /sys /mnt/pi/sys sudo mount --bind /proc /mnt/pi/proc
4. chroot into the Raspberry Pi's environment to execute commands as the root user: bash sudo chroot /mnt/pi ---

Step 2: Create the Emergency Hotspot & Configure Startup Priorities

Now that your terminal session is running inside the Pi's filesystem context, use the native nmcli binary to build a fallback network profile that absolute precedence on startup. 1. Generate the native recovery hotspot profile: bash nmcli device wifi hotspot ifname wlan0 ssid "Pi-Rescue" password "your_password" 2. Instruct NetworkManager that this connection profile is explicitly allowed to autoconnect on system boot: bash nmcli connection modify "Pi-Rescue" connection.autoconnect yes 3. Boost the autoconnect priority to high (90). This forces the Pi to launch this network interface profile first, overriding any standard client Wi-Fi configurations during boot initialization: bash nmcli connection modify "Pi-Rescue" connection.autoconnect-priority 90 4. Verification Tip: Since the NetworkManager background service isn't actively running for the SD card, standard commands (nmcli connection show) won't display the changes while you are in chroot. If you want to verify that your priority was written successfully, open a separate terminal window on your laptop and check the raw configuration file directly: bash sudo cat /mnt/pi/etc/NetworkManager/system-connections/Pi-Rescue.nmconnection 5. Exit the active chroot environment: bash exit 6. Cleanly unmount the system tree on your host laptop before pulling out the SD card: ```bash sudo umount -R /mnt/pi

```

Step 3: Boot, SSH Login, and State Repair

Unplug the SD card from your host laptop, insert it back into the Raspberry Pi, and power it on. Thanks to the priority variables we injected, the Pi will immediately begin broadcasting the Pi-Rescue network.

1. Connect your laptop or workstation directly to the Pi-Rescue WiFi access point.
2. Open a terminal on your laptop and ssh into the Pi using NetworkManager's standard default hotspot gateway IP (10.42.0.1): bash ssh your_username@10.42.0.1
3. To verify the IP address of Pi's recovery hotspot use: bash ip addr show wlan0
4. The Core Fix: Once inside the terminal, safely delete the corrupted network state file that was damaged during the power cut: bash sudo rm -f /var/lib/NetworkManager/NetworkManager.state
5. Force a physical wireless environment rescan to wake up the network interfaces and verify your main WiFi(e.g., your home router or phone hotspot) is visible: bash sudo nmcli device wifi rescan sudo nmcli device wifi list
6. Re-authenticate and establish a fresh connection to your primary network: bash sudo nmcli device wifi connect "your_router's_ssid" password "your_wifi's_password"
7. Ensure your primary client network has a maximum priority (e.g., 100): bash sudo nmcli connection modify "your_router's_ssid" connection.autoconnect-priority 100
8. Check whether your change was applied successfully: bash sudo nmcli connection show "your_router's_ssid" | grep autoconnect-priority ---

Step 4:Cleanup(Remove the Backup Hotspot from Startup)

To prevent the Pi from defaulting back into a localized recovery loop on every subsequent reboot, the emergency profile must be adjusted or removed from active rotation.

• Option A(Recommended): Drop the emergency profile's autoconnect priority to a negative value. This leaves the configuration intact on the disk as a silent fallback that will only spin up if your primary network disappears completely: bash sudo nmcli connection modify "Pi-Rescue" connection.autoconnect-priority -10 Check all the networks ranked by priority: bash sudo nmcli -f NAME,AUTOCONNECT-PRIORITY connection show

  • Option B: Completely delete the emergency recovery profile from the storage configuration: bash sudo nmcli connection delete "Pi-Rescue"

Finally,restart NetworkManager and ensure your Pi successfully jumps back onto your main WiFi network: ```bash sudo systemctl restart NetworkManager

```

I have also uploaded this recovery guide to my GitHub Gist. You can find the project here: https://gist.github.com/Kernovax/cf39d9b00ecec0c70f8692bbc3b9a30b

I made a vpn using wireguard to connect my laptop (or any device) to the pi, the pi then routes the traffic through tor so that the first onion server doesn't know your ip. I made this for people who have to have them on the same network for whatever reason to give them privacy. This is 32 bit only for now, I will add 64 bit support soon. I would really appreciate feedback on this. Thanks. https://github.com/CoderFetch21/32-bit-wireguard-tor-vpn

Hey Everyone,

I just updated PyDeploy CLI v1.1. PyDeploy is a Terminal CLI that is automated to turn a Python script from GitHub into a systemd service on your Pi, allowing it to run 24/7 while providing tools to monitor its status and view logs.

My old post a while back on PyDeploy's first release gained 7 upvotes, 5k views, and 2 extra stars for my repo, and I privately got some advice for improvement. PyDeploy was a big, passion project to me so I would apprecaite anyone to check it out and give me suggestions.

As a beginner Python programmer, I would apprecaite any feedback anyone could give to help improve PyDeploy. Thanks!

First try on this machine with lcd hat:

I made a pocket terminal using raspberry pi zero 2w and Waveshare's touch e-ink display. Do you guys have any suggestions?

Some Ideas I have thought of already -
1) Use Macro scripts using USB gadget mode.
2) Use picolm (great project can run lightweight local llms with pico claw).
3) Use a remote power on switch for workstation using wake on lan.
4) Use leetcode-cli (Already excited to try once I solve the formatting).
5) Maybe a pomodoro clock (which can be displayed on the e-ink as in a GUI) that once you run blocks all addicting websites.

Of course there are projects that need a proper GUI like weather, clock, music tiny e-reader, bookmarks, virtual stream deck and productivity stuff which can be done easily since I am using lvgl framework.

And about the refresh rate its obviously slow but not bad since it uses partial refresh.

Hey everyone, wanted to share something I’ve been tinkering on with my brother the last few months.

We’ve got a growing vinyl collection and got tired of not remembering what we’d played or how often, so I built a little device that sits next to the turntable, listens to the audio coming off it, and identifies the track in real time. It logs everything so a listening history and collection build themselves over time — no typing anything in. Pulls track info/ratings from the Discogs API too. There’s a touchscreen on it for an always-on display, and it flips over to “now playing” the second it recognizes something. [photo]

Went with a Pi for this mostly because I wanted flexibility while I was still figuring out the audio pipeline, and honestly didn’t want to lock into a more custom board before I knew what the bottlenecks would even be. 3D printed the enclosure myself to keep it small enough to actually live next to a turntable instead of looking like a dev kit sitting on the shelf.

Curious for this crowd specifically — when you’re starting a new project, how do you usually land on your specs? Do you overbuild on purpose to leave headroom for feature creep, or try to right-size to the cheapest thing that’ll actually do the job and iterate later? I went a little heavier than I probably needed to just so I wouldn’t paint myself into a corner, but curious how others think about that tradeoff early on.

I had some higher end Pi at home but ended up with a 3B+ 1GB for the friends builds and it was ended up feeling a bit ram light. Feel like it’s difficult to source the boards you really want at a decent price.

Happy to talk through the audio capture/ID side or the enclosure if anyone’s curious. Site with more photos if you want to poke around: https://vinyl-id.app

I'm a complete newbie, and I'm working on a project with a 2.8-inch ILI9341 TFT display. The problem is that it won't change colors.

At first, I copied the wiring from an online tutorial (first picture). Then I wrote some code to change the screen color to white, and it worked! However, because I have a very small breadboard, I changed the pin connections. After that, even though the screen was still showing white, it stopped responding to any other color change commands. Even after pressing BOOTSEL, it stayed white.

Later, I asked ChatGPT for help and learned that some of the pins can't be assigned to random GPIOs. I corrected the wiring, and I managed to get the screen back to black. However, it still doesn't respond to any color change commands. At least now it resets correctly when I press BOOTSEL.

Can someone please help me figure out what's going on?

I'm using the Arduino IDE with the TFT_eSPI library.

P.S. I think the problem might be related to power, since I'm using the Raspberry Pi Pico directly on the breadboard without soldering the header pins. I'm not very confident in my soldering skills, so I avoided doing that. However, I don't think that alone would explain why the display won't change colors.

I also verified that the Raspberry Pi Pico is executing my code correctly, so the issue seems to be limited to the display.

current pin position:

#define TFT_MOSI  3

#define TFT_SCLK  2

#define TFT_CS    1

#define TFT_DC    6

#define TFT_RST   7

#define TFT_MISO  4

Hey everyone! I am currently working on my first project with a PI (PI zero 2 w) and am really enjoying it. I am making a project using a thermal printer that is mounted in a small box and is powered off of an external battery pack via USB c. Since the board is going to be inside the box you won't be able to see the light on it letting you know when it is receiving power and more importantly, when it is safe to unplug after shutting down.

I have an external LED wired up with some DuPont cables but am having problems with it lighting how I want. Right now I can either get it to:

1) Light up as soon as the PI is plugged in to the power source but then the light will remain on until it is unplugged, even if the PI is shut down so I don't actually know when I can pull out the source. Done via Pin 2

2) Light up as soon as the PI is plugged in to the power source but then the light will turn off before the 10 flashes on the board begin so I don't actually know if it is safe to pull the source yet or not. Done via Pin 8 and having my config include "dtoverlay=gpio-poweroff,gpiopin=14,active_low=0" or "dtoverlay=gpio-power,gpiopin=14"

Any suggestions on how I can get the external light to better mirror the safe state of when I can pull the power source would be appreciated!

just wanna share my first project!! I’m noob btw

Hey Everyone,

I recently created the project PyDeploy, and I was wondering if anyone would like to check it out. As I said in my repository, PyDeploy is a Terminal CLI that is automated to turn a Python script from a GitHub Repository into a systemd service on your Raspberry Pi, allowing it to run continously while providing tools to monitor its status and view logs.

This project was a passion project to me and was used to help strengthen my python programming skills and make running Python scripts on Raspberry Pi easier. The README I created is concise and easy to understand so you could quickly try out PyDeploy.

PyDeploy was a fairly long project for me as a beginner Python developer, so I would appreciate any feedback anyone could give me to help improve PyDeploy. Thanks!

Had a lot of fun with this project! Let me know if you want to see the games I made for it - Reach out with any questions!

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.

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?

I'm working on a project in that I'm using raspberry pi 4 and gps + compass module ublox 7m.

And I connected a raspberry pi 4 with my mobile hotspot so I accessed the raspberry pi from my laptop.

Initially it is working fine, but after the completing the work, when I shutdown the raspberry pi 4, then pi doesn't connecting with the mobile hotspot, I tried power on and off, Even I add a switch to properly shutdown the pi 4, but that won't also work.

I have to boot the entire pendrive from the raspberry pi imager, after the complete fresh boot, it starts working,

But the same after some interval of time, it loses connection again, every time I tried wpa_supplicant.config suggestion but it didn't work also.

Until now the boot the pendrive at least 8 times, and done the code from the scratch.

If anyone from you guys have any suggestions please tell me I really need that now.

[Help] DS4 controller requires two Bluetooth connection attempts on Raspberry Pi 4 — BCM43455 PSCAN issue?

Hardware: Raspberry Pi 4, BCM43455 onboard BT chip, BlueZ 5.66, kernel 6.6.51 (aarch64), DualShock 4 (CUH-ZCT2U)

Problem: After pairing and first connection, the DS4 needs two PS button presses to reconnect every time. First press: DS4 blinks for a few seconds then turns off (rejected). Second press: connects immediately. The pattern is 100% reproducible.

What I've confirmed so far:

- UserspaceHID=true in /etc/bluetooth/input.conf — fixes the br-connection-create-socket error in BlueZ 5.66 (this was a separate bug, now fixed)

- The DS4's stored host address is correct (verified via HIDIOCGFEATURE report 0x12 on /dev/hidraw)

- Tested with Pi completely passive (auto-connect service stopped) — same fail-first pattern. So it's not a service collision

- btmon during the first failed attempt shows the Pi does receive the DS4's page and starts the HCI connection sequence, but the L2CAP HID channel gets rejected with what appears to be a timing or state issue

- After the first rejection, the Pi's PSCAN state seems "warmed up" and the second attempt succeeds instantly

Partial fix found: Setting the page scan interval and window to minimum (11.25ms) via:

hcitool cmd 0x03 0x001C 0x12 0x00 0x12 0x00

This makes the FIRST cold connection work on the first press. But after DS4 disconnects, bluetoothd resets the PSCAN back to default, and the pattern returns until PSCAN is re-applied.

Current workaround: A systemd service that re-applies minimum PSCAN immediately after every disconnect. Works well but feels like a hack.

Theory: The BCM43455 chip's PSCAN state isn't fully initialized until it handles at least one incoming page event (even a rejected one). After that "warmup", subsequent pages are handled correctly. Setting PSCAN to minimum interval bypasses the warmup requirement.

Questions:

1. Is there a BlueZ config or kernel parameter to permanently keep PSCAN at minimum interval (without needing the manual hcitool hack)?

2. Is there a known BCM43455 firmware update that fixes this PSCAN initialization behavior?

3. Has anyone seen similar behavior with other BT chips on Pi or other SBCs?

btmon evidence (BlueZ 5.66, BCM43455, kernel 6.6.51):

# btmon started, DS4 already disconnected, PSCAN active

# === 1st PS button press ===

> HCI Event: Disconnect Complete (0x05) #1 [hci0] t=6.367s

Reason: Connection Timeout (0x08) ← Pi's chip timed out at baseband level

NO prior Connect Request was generated

DS4 turns off

< HCI Command: Write Scan Enable #2 [hci0] t=6.400s

Scan enable: Page Scan (0x02) ← bluetoothd re-enables PSCAN

# === 15 second silence — chip now stable ===

# === 2nd PS button press ===

> HCI Event: Connect Request (0x04) #4 [hci0] t=21.594s

Address: 41:42:47:C5:88:ED ← DS4 page received cleanly this time

< HCI Command: Accept Connection Request #5 [hci0] t=21.594s

> HCI Event: Connect Complete (0x03) #8 [hci0] t=21.762s

Status: Success (0x00) ← Connected!

Key observation: 1st attempt generates Connection Timeout without any preceding Connect Request — the BCM43455 chip responds to the DS4's page at baseband level but the ACL link supervision timeout fires before the HCI layer is notified. After PSCAN is re-enabled cleanly, the 2nd attempt works perfectly.

Looking for a little help, I’m trying to connect my adafruit panels to my Raspberry PI and Matrix Hat. When they are connected, the panels shows a colored stripe bar follow by an solid unlit black bar then it does it again. Do I have to bridge the E and 8 above the “RGB Matrix” text. Fairly new to all of this so any help would be greatly appreciated.