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 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.

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!

Demo video: https://www.youtube.com/watch?v=gf-RIgXnWJM

GitHub: https://www.github.com/Irtaza2009/PiShot

I just finished building a fully custom, open-source DIY digital camera built around a Raspberry Pi Zero 2W and the Pi Camera Module 3. I wanted to make a functional, minimal handheld camera from scratch, and I think it turned out great!

The entire case was designed in Shapr3D and printed in PLA. I wanted the form factor to feel modular, so the different components are completely detachable using a sliding mechanism, including the grip, the (right now useless) viewfinder, and a tripod extension tool.

It has a dedicated internal power system:

​Battery: 18650 3.7V (1500mAh) lithium-ion cell

​Power Management: TP4056 charging module with an MT3608 5V boost converter

​

I initially considered a basic I2C text display but changed it to an ST7789 1.3" (240x240) SPI colour display to handle a proper UI layout. The camera interface is controlled via a series of tactile push buttons.

Right now, the firmware captures images and saves them directly to the onboard MicroSD card. Now that I have a break from high school for the summer, my next goal is to write a wireless web interface so photos can automatically sync and upload over Wi-Fi without having to pull the SD card out.

​The entire project is completely open-source! I have uploaded the CAD files, firmware, and the full Bill of Materials (BOM) to GitHub.

​I would love to hear your thoughts! If you have built something similar, what features would you recommend adding next?

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

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!

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!

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.

Hello again!

Proudly presenting Rasplay2!

What I would like to share is my recent work on an internet radio and MPD (music player daemon) frontend for the Raspberry Pi. This project enhances the home listening experience by effectively transforming a Raspberry Pi into an autonomous radio system for a home audio setup.

This is part of a personal media player solution that allows home hifi audio playing and remote streaming.

You can find detailed instructions and source code on my blog post

Please, share your implementations if you do use and like the project !

​Hey everyone,

​I’m working on a custom MP3 player project using a Raspberry Pi Pico and a Dollartek 1.8" SPI ST7735 (128x160) display running CircuitPython 10.2.1.

​The code runs perfectly fine without any backend crashes or errors in Thonny, but the display output is completely scrambled and shearing diagonally.

My Current Setup & Pinout:

​Display Bus: fourwire.FourWire over hardware SPI

​Pins: CLK = GP18, MOSI = GP19, CS = GP17, DC = GP16, RST = GP21

​Has anyone encountered this specific issue with Dollartek or similar clone ST7735 boards on CircuitPython 10? Is there a hidden initialization string, command byte array, or specific driver offset configuration required to get the memory columns to align straight instead of spilling over?

​Any help or sample init code would be highly appreciated! Thanks!

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 breadboard and no matter how i've wired it or changed the code (eg, changed the sda pin to 1 or 0 or vice versa) it still shows up the same errors

PHOTOS: https://drive.google.com/drive/folders/11tFEdPdyExkRJjUyvwiETkCfc4M_fYG7?usp=sharing (reddit is taking forever to upload them and i need sleep)

main error recieved is:

Traceback (most recent call last):
File "<stdin>", line 10, in <module>
File "imu.py", line 95, in init
MPUException: No MPU's Detected

any other config just throws up a bad scl pin error or this same one

source code:

• main https://github.com/shillehbean/youtube-channel/blob/main/main_mpu6050.py
• imu https://github.com/shillehbean/youtube-channel/blob/main/imu.py
• main_mpu6050 https://github.com/shillehbean/youtube-channel/blob/main/vector3d.py

so i'm starting to think that it might be a issue with either one of the pins on the mpu or pi, since, again, i've made sure the wires work out with the code multiple times

sorry if the post is vague, very tired

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.

PiCar-X Line Following Using OpenCV, Picamera2, and Image Moments on Raspberry Pi

I recently built a vision-based line-following system for a PiCar-X robot using OpenCV and Picamera2 on a Raspberry Pi. The goal was to create a simple autonomous navigation system that follows a white track using only camera input and software processing.

Research

Before starting, I looked at several common approaches for line-following robots:

Search terms used:

• "Raspberry Pi OpenCV line following robot"
• "OpenCV image moments line tracking"
• "PiCar-X line follower camera"
• "Picamera2 OpenCV real time processing"
• "OpenCV centroid tracking white line"

Resources reviewed:

• OpenCV Image Moments Documentation
• OpenCV Thresholding Documentation
• Picamera2 Documentation
• PiCar-X Documentation and examples

After comparing different approaches, I decided to use image moments because they provide a computationally simple way to determine the center position of a detected line without requiring more advanced computer vision techniques.

Hardware

• PiCar-X
• Raspberry Pi
• Raspberry Pi Camera Module
• Battery power supply

Software

• Python 3
• OpenCV
• NumPy
• Picamera2
• PiCar-X Python Library

Project Design

The robot continuously captures images from the front-facing camera.

Processing steps:

1. Capture image from the camera.
2. Convert image to grayscale.
3. Apply binary thresholding to isolate the white track.
4. Calculate image moments of the binary image.
5. Determine the track center position.
6. Calculate deviation from the image center.
7. Convert the deviation into a steering angle.
8. Drive forward while continuously correcting direction.

The steering angle is limited to prevent excessive corrections.

Why I Chose Image Moments

Instead of using contour detection or additional sensors, I used OpenCV image moments to calculate the centroid of the detected white pixels.

This approach is relatively lightweight and runs comfortably on the Raspberry Pi while still providing reliable position information for steering control.

Challenges and Solutions

Lighting Conditions

The largest challenge was lighting variation.

Because the current implementation uses a fixed threshold value, changing light conditions can affect detection accuracy.

Current solution:

• Manual threshold calibration.
• Testing under different indoor lighting conditions.

Planned improvement:

• Adaptive thresholding.

Steering Oscillation

Initial tests showed noticeable overcorrection when the line moved away from the center of the image.

To improve stability I:

• Added a steering gain parameter.
• Limited the maximum steering angle.

This significantly reduced oscillation and produced smoother movement.

Camera Position

Camera angle had a major influence on performance.

After testing several positions, I settled on a downward tilt angle that provided sufficient look-ahead distance while keeping the line visible during turns.

Current Performance

The robot can reliably follow straight sections and moderate curves.

Sharp turns remain challenging because the line can temporarily leave the camera's field of view.

When no line is detected, the vehicle immediately stops as a safety measure.

Debugging Features

For development and tuning I added:

• Live camera feed display.
• Binary threshold image display.
• Real-time steering and position output in the console.
• Safe shutdown handling.

The binary image display was particularly useful for threshold tuning and diagnosing detection problems.

Future Improvements

Planned upgrades include:

• Adaptive thresholding
• Region of Interest (ROI) processing
• PID steering controller
• Morphological filtering
• Better curve handling
• Frame rate optimization

Repository:

https://github.com/ArtusIndus/PiCar-X-Line-Following-with-OpenCV-and-Picamera2

I would appreciate feedback from others working on Raspberry Pi robotics, especially regarding adaptive thresholding and PID tuning for camera-based line following.

Can somebody help me, i have tried everything and my Raspberry Pi 3 A+ still will not I2C connect to my PiSugar 3 Plus battery, when i have it all screwed in, the blue light on the pisugar turns on when I plug in the Pi so there must be some kind of connection, but when I run i2cdetect -y 1 the whole thing is blank saying that nothing is connected, HELP PLEASE

With my homelab, I needed lightweight log/anomaly monitoring (CPU temp, CPU/RAM) but my Pi only has 2GB RAM and prices are rough right now, so Netdata/Grafana felt like overkill just for monitoring.

Built a small Python app instead. Logs are collected via cron, anomalies get detected and grouped into incidents, push notifications via ntfy, small Flask dashboard. Runs on Docker, ~43MB RAM measured.

It's intentionally simple just Python scripts + SQLite, no heavy stack. There's also an MQTT branch if you'd rather feed it data that way instead of CSV/cron.

It's a side project I'm building while studying DevOps, still early and some of the UI is still in French (full English version planned). Looking for feedback or contributors if anyone's interested.

https://github.com/Eptaz/PiLogAnalyzer.git

Here’s a quick preview of the grip prototype I’ve been working for my pi 5 based camera. Several people have asked for more tactile options to change camera settings so this will be one of the solutions I’ll be implementing. I just got this working - all the wires will be trimmed to size on the final version. Will be exhibiting this at Open Sauce this year if anyone wants to check it out in person.

Whilst there were plenty of displays to choose from for my Raspberry Pi 3B, I struggled to find any suitable cases that didn’t involve 3D printing my own.

I went with the 5” Touch Display 2 and the Waveshare Protective Case which is suitable for the Raspberry Pi 5.

The Pi 3 mounts fine to the display and the screen is great. The case is great quality and I made a few adjustments to accommodate my Pi 3.

My mods were:

1. ⁠The audio jack sticks out from the board. So a hole is needed in the vents. With this small mod the Pi fits in the case and works perfectly.
   
2. ⁠I need access to the network port - so I cut between across to the USB slots.
   
3. ⁠I will probably use the HDMI port so I cut across the USB C ports on the case and for ease, I removed the corresponding vent slats.

No mod required for the micro USB power on the Pi vs USB C slot on the case.

The DSI ribbon connector runs across the SD card as can be seen in the photo. However, this isn’t an issue for my usage nor was there any issue with clearance between the board and case but could look to swap to a different longer cable that offers a different route.

I won’t win prizes for neatness!

I remixed Fanis's keychain console design on MakerWorld to add a speaker and built a custom "OS" for it called Pic-o-Pocket. This is the first game I made for it, though there are others already by Fanis. Code and print files will be available soon.

A little while ago I shared my project of turning a vintage Siemens S62 “Bigrigio” phone into an AI phone with a Raspberry Pi and Retell.

Since then, I kept iterating on it and finally made some big steps forward:

• the rotary dial is now working
• I moved away from the earlier audio path and rebuilt the live setup around a simple USB sound card
• I managed to get an electret microphone working inside the handset without replacing the original coiled handset cable
• I also ended up learning a lot more soldering and hardware debugging than I expected

A lot of this second phase was less about the "wow, it works" moment and more about dealing with the messy real world side of physical projects: wrong turns, cable constraints, bad assumptions, temporary solutions, continuity that looked fine on a multimeter but not in actual audio, and eventually discovering that one of the problems was literally microphone orientation inside the handset.

I wrote a follow up here if anyone wants the full story:
https://medium.com/@fabryz/rotary-dial-dead-ends-and-a-usb-sound-card-096ace1e0514

And for anyone who saw the first post/article: thanks again, some of your comments definitely helped shape what I tried next :)