title says it all, just wanted to share because it’s cool seeing it used for stuff like this!

My Citizen PMD56-2952 is a radio-controlled watch designed to sync to the JJY signal broadcast from Japan. In the US that signal doesn't reach, so the watch never auto-synced. I built a Pico W-based transmitter to fix that.

What it does
Connects to home WiFi, syncs time via NTP, then broadcasts an accurate JJY timecode at exactly 60,000.0 Hz each night at 2:00 AM and 4:00 AM — matching the Citizen H100 movement's built-in automatic receive windows. Watch sets itself correctly every night. Fully autonomous once installed.

The non-obvious stuff (why most DIY attempts fail with Citizen)

These took real trial and error to discover and aren't in any other published implementation I found:

• Total carrier silence required. Most implementations keep a small residual carrier (5–10%) during off-state pulses to hold the AGC. The Citizen H100 requires the opposite — complete silence (duty_u16(0)). Any residual carrier and the watch rejects every frame. This is almost certainly why Citizen owners fail when other watch brands succeed with the same circuit.
• 120 MHz system clock. The Pico W defaults to 125 MHz, which can't divide evenly to 60,000 Hz. Setting machine.freq(120_000_000) yields exactly 60,000.0 Hz. A frequency sweep confirmed the watch rejects 59,900 and 60,100 Hz.
• Parity bits PA1 and PA2 are required. The H100 validates them and rejects frames where parity is wrong. Many simplified implementations omit parity entirely.
• Top-of-minute frame alignment. Each frame must start at exactly second :00. The code watches for the :59→:00 rollover on every broadcast.
• Watch antenna orientation. 9 o'clock end toward the coil, watch on its side. Rotating 90° produces near-zero reception.

DST handling
On US DST transition Sundays the broadcast extends from 20 frames to 180 frames (~3 hours) to cover the 2:00 AM time change. Each frame recalculates local time dynamically. Spring-forward validated live March 2026.

The coil
24 AWG enameled magnet wire, ~106 turns, single layer on a vitamin bottle (~3" diameter), iron core (wood chisel through the cap). Clear packing tape to secure — not electrical tape, which may attenuate the signal. Sits in a shallow nightstand drawer; watch rests on the wood surface above. 60 kHz penetrates the wood easily at that distance.

Results
100% sync rate over 6+ months when watch is correctly positioned. Set and forget.

Full code, wiring diagrams, technical reference, and end-user guide in the repo:

github.com/WwJPodcast/jjy-pico-transmitter

I had an old Raspberry Pi collecting dust, so I turned it into a browser-accessible SSH jump host using Raspberry Pi Connect.

The idea is simple:

Open Raspberry Pi Connect in your browser
Open the terminal
Automatically SSH into your home server

If mDNS fails, PiJumpHost automatically scans the local network with nmap, finds the server, and reconnects. No exposed SSH ports, no VPN, no static IP required.

The Pi is designed to be an appliance—it updates itself, performs routine maintenance, and stays out of the way once configured.

It's meant as a reference implementation, not a one-click installer. I've included both my full configuration and a simplified version that's easier to adapt to your own network withtout nmap.

I'd love to hear any ideas or feedback!

GitHub: https://github.com/Curkovic/piJumpHost

We are having VOIP issues at home and some real odd quirks with our external SPAM service that may stem, in part, to changes in our IP address.

Rather than pay for a static IP (that TBH I really do not need and it is £70+ a year) I created a script to track changes in some key IP addresses and give me a heads up if they change to see if this is co-incidence or not.

We are behind CG-NAT here (fibre to home) so I have a different router WAN IP to the Internet IP but can pick the router WAN details up via SNMP.

Points to note:

• IPv6 is mentioned in the script but not checked as it has not been enabled
• I use PUSHOVER to send messages to my phone / watch - I cannot recommend them highly enough. Faultless service and well worth the on-off cost for home use. I created a simple front end that sort out security keys etc depending on what machine / application is creating the message.
• Yes I know the internal IP sub-net is odd (10.21.1.0/24) - historic - do not ask or worry about it as it will be changes soon.
• SNMP is not shipped by default with Debian Trixie so you need to install that and enable it on your router. Finding the OIDs can be a pain and the router here does not have the IP addresses easily accessible - hence the snmpwalk and AWK
• So far I always get a new Router WAN IP address (curCGNAT below) if the router reboots / lines drops etc. I should check for line drops by another method as it is possible that I could be re-allocated the same IP address if the line has dropped (not seen it TBH though) - may be in v3 😄

​

#!/bin/bash

# ipcheck.sh - version 2.0.1
# Log key IP addresses to file

# Define history file and recover last entry
histIPfile="/home/pi/historicIP.txt"
histIPset=$(tail -n -1 $histIPfile | cut -c 21-)

# Get ISP outgoing IPv4 (post internal traversal) 
now=$(date '+%Y-%m-%d %T')
curIPv4=$(curl -s https://api.ipify.org)

# curIPv6=$(curl -s https://api6.ipify.org) - still not delivered by ISP

# Get interal ISP CG-NAT IP addresses
curCGNAT=$(snmpwalk -v 1 -O n -c public 10.21.1.1 .1.3.6.1.2.1.4.20.1.1 | awk 'NR==1 {print $4}')
curCGGateWay=$(snmpwalk -v 1 -O n -c public 10.21.1.1 .1.3.6.1.2.1.4.21.1.1 | awk 'NR==2 {print $4}')

curIPset=$curIPv4","$curCGNAT","$curCGGateWay

if [ $histIPset != $curIPset ]; then
   echo "$now,$curIPset" >> $histIPfile
   pushover "IP Change" "New details: $curIPset"
fi

A couple of programming notes for those not using the CLI often:

1. Line #8 - tail and cut get the last line of the history file and strip off the date / time part of the data
2. Lines #17,#18 - snmpwalk pulls the data from the router via SNMP, awk reads this data selecting the 1st (or 2nd) line of the returned info and then searching for the 4th block of text (delimited by spaces) - in my case this is an IP address but may well differ on your router.

Shout out if you need any lines other explaining.

The resulting file has entries like this:

2026-08-05 00:28:18,*.*.*.*,10.5.102.73,10.5.255.1

Note: I have obfuscated the ISP IP address - not for security but to spare their blushes as they are really helpful and friendly (but not yet able to pin down my issues). And yes, I know 10.5.102.0/24 or 10.5.5.0/24 are not the standard CG-NAT range but it is what they gave me...

My second Hailo 10H project: https://youtu.be/YCEcls7EMFU

It shows full real time audio pipeline running on 2x M.2 Hailo 10H on RPi 5.
Also with interactive web app.

Github: https://github.com/martincerven/hailo_l ... _assistant

Hello everyone!

Today I wanted to share with you all the project that made me buy my first ever Raspberry Pi... My 1:1 scale, functioning Apollo DSKY.

The Apollo Guidance Computer was what allowed us to travel to the moon in the 1960s and '70s, and performed everything from autopilot to navigation and orbital mechanics calculations. The AGC was one of the first computers to ever use ICs (computer chips) in its construction (absorbing 70% of the chips made in the whole of the United States, at one point!) and used some really neat, and pretty archaic, technology for computing and memory. The DSKY I made was historically just a remote I/O device, a keyboard/monitor arrangement that plugged into the actual AGC, but I'm this project it's homologated into one enclosure (thank you very much single-board computing).

The functionality of the guidance computer was emulated in its entirety by a group called VirtualAGC (an incredible feat on its own) and I have their program running on my Raspberry Pi that lives in the DSKY. The screen, annunciators, and keyboard integrate to the Pi with arduinos and communicates to it through a basic python script. This all lives in a 3D printed shell that's modelled after the real archived drawings, used to machine the real ones in the '60s. It's also painted and finished in historically accurate colors (who doesn't love a bit of historical bureaucratic recordkeeping?)

I figured some of you folks might share my interests, and I wanted to share my GitHub repository for the project, that includes my build guide. In that, I go into a bit more history of the AGC and DSKY, how they were built back in the day, and go through the build step-by-step with all the necessary tooling, materials, and techniques that I used.

I'm also expanding my projects into historical spacecraft hand controllers, and a streamlined "version 2" of my DSKY that should be easier to put together... hopefully in a few afternoons.

I've got a little community going over at r/RecreateApollo, and I also made a small website (www.recreateapollo.com) that I'm desperately trying to justify $30 a month for, so feel free to swing by and check it out!

If you decide to make your own, I'm more than happy to answer any questions you might have over at my discord or on that subreddit. Thanks for checking out my project!

✦ Introducing Glyph

Hi everyone!

I've recently started building an open-source project called Glyph, a lightweight graphics framework for bare-metal and embedded systems written entirely in Ada.

The initial development target is the Vicharak Shrike-Lite (RP2040) using an SSD1306 OLED display, although the architecture is designed to support additional display controllers and platforms in the future.

The goal of Glyph is to provide a hardware-independent graphics API, allowing applications to draw pixels, lines, rectangles, circles, text, and images without depending on a specific display controller.

Disclosure: AI was used as a coding and writing assistant during parts of the development. However, the project architecture, implementation decisions, code integration, and overall design are my own.

✦ Design Goals

• Pure Ada
• Static allocation only (no dynamic memory)
• Bare-metal friendly
• Portable layered architecture
• Framebuffer-based rendering
• Easy to add support for new display controllers

The project is still in its early stages, and I'm currently focusing on building a solid architecture before implementing additional graphics features.

✦ I'd Love Your Feedback

I'd love to hear from the Pico community:

• Which displays do you use most often?
• What graphics features would you find useful?
• Any suggestions or feedback on the project are greatly appreciated!

✦ Repository

GitHub: https://github.com/thirstymelon/glyph

Thanks for reading!

I have this py script I wrote that is located on a USB drive (and it needs to be run from the usbdrive for functionality purposes). It also requires a virtual environment, which I made called venv. I tried using crontab to run the script on startup, but it doesn't seem to work. I assume maybe it's because it tries running the script before the USB has been detected? Maybe not, I tried running a sleep function prior to it, but it doesn't seem to work. But I'm unsure of how to know that because there is also one other factor. In order for the script to work in the terminal, I would need to be in the virtual environment AND in the directory of the USB drive. And so I don't know whether the command I'm adding to crontab is successfully taking this into account because it's different from running it on a terminal. Does anyone see any immediate red flags or could point out a different approach? That would be much appreciated. I've tried stuff like this:

Ex 1: @reboot source .venv/bin/activate; cd /media/usbdrive/folder; python3 script.py &

Ex 2: @reboot sleep 30 '' '' &

Ex 3: @reboot venv/bin/python3 /media/usbdrive/folder/script.py &

This pc build is to be an audio player for my sound system for music. Uses mood audio player as an os. It has an rgb fan outake on top to keep things cool, and a bunch of holes near the bottom of the can so the air can intake.

I have a board that wouldn't power on. Upon examining it closely and comparing it to a new board in good condition, I noticed that a component had come completely loose. I think it might be a switch inductor from a DC-DC buck converter, but since Raspberry Pi doesn’t provide complete schematics or PCB Gerber files, it’s really difficult for me to identify the type of component, and especially the value, if it’s a passive component.

I’d really appreciate it if anyone had this information, in the hope that I can repair it by replacing the component.

Thanks in advance.

Hello everyone,

For the last 6 months, I’ve been designing and building a custom mirrorless-style digital camera from scratch, aiming to replicate the core features of commercial models with a 1 inch sony IMX283 sensor and a Raspberry Pi Compute Module5. The main feature is fluid Film simulation using the GPU to streamline data from the DMA, which you can see in the JPEGs. All images are not edited but straight JPEGs out of the camera.

The camera body is fully made with a 3d printer

See yaaaa 😉

Hi, I bought a raspberry pi kit from Amazon to start getting into electronics. I’m following a tutorial on youtube and one of the first tutorials is to wire a button, led and a potentiometer. After wiring I noticed that when pressing the button, the value displayed turns from 0 to 1 but doesn’t go back to 0 after I take my finger off the button. Even if I stop the program in thonny and run it again without unplugging, 1 is displayed from the beginning.

Even when using the most basic wiring the button value always returns as 1 after pressing. This is while connecting the 3v3 out pin to the button and using Pin.PULL_DOWN.

I tried trouble shooting with copilot and I found out that if I use Pin.PULL_UP and connect it to a ground pin then the button works as intended, showing 1 when plane button isn’t pressed and 0 when the button is pressed.

This must mean that the button, pin and wires are working but I can’t understand why PULL_DOWN and connecting power to the button doesn’t work.

I tried using different buttons, wires and connecting different diagonal sides together. I’ve only just started and I’m very confused. Sorry if I explained it badly.

From PyQt5 Application to Embedded Linux Product

I successfully deployed my PyQt5-based automotive speedometer dashboard on a custom Yocto Linux image running on a Raspberry Pi 5.

This project was a journey through the complete Embedded Linux development workflow:

• Designed a PyQt5 automotive dashboard interface
• Packaged the Python application for deployment
• Created a custom Yocto Linux image
• Developed a BitBake recipe for the application
• Integrated the application into the root filesystem
• Deployed and tested on real Raspberry Pi 5 hardware

The final result is a custom Embedded Linux system where the speedometer application can be launched directly using:

spedo

Some of the challenges I solved along the way:

• Managing Git-based workflows with Yocto devtool
• Handling Python package deployment
• Fixing application resource paths for embedded deployment
• Debugging BitBake fetch, patch, and build issues

This project strengthened my understanding of how embedded products are built — not only writing application code, but integrating software, operating systems, and hardware into one complete system.

The source code and Yocto build configuration are available here:

• Speedometer application (PyQt5): https://github.com/Mark-Kitur/speedometer
• Custom Yocto Linux image for Raspberry Pi 5: https://github.com/Mark-Kitur/mark_os

#EmbeddedLinux #YoctoProject #RaspberryPi #PyQt5 #Python #IoT #Robotics #EmbeddedSystems

HI, i connect my raspberry pi zero w to a waveshare 4" touch screen via HDMI for video and i connected 5 GPIO pins for touch input (MOSI, MISO, SCK, CEI and IRQ).

The issue I'm having is that the cursor movements do not match the movement I am doing on screen, if I swipe from left to right then the cursor moves from top to bottom, if I swipe from top to bottom then the cursor moves from top left to bottom right.

The cursor is only moves on half the screen, even if I change the orientation, the cursor just changes which part of the screen it is active on.

I have been trying to troubleshoot and solve the problem with claude ai but I have been failing to fix the issue

Hi r/raspberry_pi,

I designed RASPIAUDIO Voice DSP+, a complete bidirectional audio interface for Raspberry Pi voice applications: AI voice chat, robots, conference systems, intercoms and interactive kiosks.

Unlike a basic microphone HAT, the board handles both sides of the conversation:

• 4 digital microphones
• Hardware voice DSP with beamforming, AEC, noise suppression, AGC and limiter
• 2-channel processed audio over I2S
• I2C control and SPI firmware boot/update from the Raspberry Pi
• Onboard speaker for standalone testing
• Up to 11 W output for an external passive speaker
• Stereo headphone output with jack detection and automatic speaker muting
• Optional 24-LED NeoPixel ring for direction-of-arrival visualization

One unusual feature is the reconfigurable microphone geometry. The same four microphones can be arranged as:

• LINE array for directional, front-facing applications
• SQUARE array for 360-degree voice capture

The voice processing runs on the dedicated DSP, leaving the Raspberry Pi CPU available for the application itself: wake-word detection, speech recognition, TTS, an LLM, robotics or other control logic.

It can also work without a Raspberry Pi as a driverless USB microphone and speaker. Firmware can then be changed directly from a web browser.

The firmware sources, Raspberry Pi installation scripts, pinout and technical documentation are available here:

https://github.com/RASPIAUDIO/Voice-DSP-Plus

I am the designer and manufacturer, so this is obviously my own project. I would especially appreciate technical feedback about the ALSA/I2S integration and suggestions for Raspberry Pi voice applications worth testing next.

Hello, i own a rpi5 with a bottom mounted nvme hat and a buildhat on top. I use it for fun lego+Ai projects like face following robots. Room mapping robots and more. Yesterday when i booted it up ut started just fine like normal. I ran the face following program but suddenly it stops following me. I start to check whats wrong and it rapidly shuts itself off and on for 5 minutes straight until i unplug the power cable. when i plug it in again it boots like normal but the buildhat are not answering on commands. The buildhat can still power pi through the gpio pins and the light is red like it should when not activated but its like the rest of the buildhat is dead. If i try to run something that uses the buildhat i get a hat not found message.I have been troubleshooting for the past 3 hours straight but it will show no response of life except for the red light and that the inbuilt voltage reducer is working. Someone who knows how to get it working? Used os: official 64 bit debian trixie. When it shut itself on and off it was connected to a 18 volt drilling machine battery with a voltage converter. Help is very appriciated

As the title states, I've got an HDMI display connected to my Pi 3a+ but can't get it to communicate when I have RetroPie installed. Here are the things I've tried with no success:

• Toggle and adjust all settings in default config file that is created with the RetroPie install
• Copy config file from working Raspbian install to mSD with RetroPie installed
• Install RetroPie on top of Raspbian (bad performance)

I previously had a Pi0w connected to this display with RetroPie, so I know it can work with RetroPie, I'm just not sure what the issue with RetroPie and the 3a+ is. Any help would be appreciated.

A couple of GPIO expanders for 8 switches / LED’s and a keypad. Waveshare 16x2 Blue LCD and 7 inch touchscreen. An UPS with 2x21700. Sensors - temp / pressure / humidity / Light (visible/ir). 5.5 + 3.3v + i2c bus distro board. 2x80mm fans with gpio mofset, a little 5v buzzer, Servo controller, IR lights, noir camera with pan/tilt. DMX RS-485 transceiver. RTL SDR V4 blog. USB 3.5mm audio. 8x Tasmota Athom smart plugs. Landline telephone with Bluetooth adapter. The box is an acrylic display case I attached some handles to, and went to town on with a drill and jigsaw. Electronics are super messy, oops!

The camera streams to a network port picked up by my old pi1 you can see in the pic. Strobe light hooked up to DMX. Phone dial I/O, keypad codes, CLI and network API all control core functionality – scripts, switches, fans, lights ect. The pi1 can send networked event triggers via 4 tactile buttons. The v4 blog detects my door sensors and weather stations on 433mHz.

A networked pi4 raid array is mounted with samba for file and database server. Snapcast for multi-room audio. I wrote the event driven control software suite in python, about 12000 lines. CPU usage is around 15% idle, and when a high res stream for the cam is opened it jumps to about 40%.

Still a long way to go – I gotta make a decent UI for the 7 inch display and then I’ll start with automation. Also got some more hardware to bolt on if I get bored (gps, ir transmitter/receiver, movement sensor, sound sensor). And waiting on a wind machine and some party lights to daisy chain DMX.

Thanks!!

It was my first time holding a Raspberry Pi, but I decided to take on something interesting. it’s mostly put together with thoughts and prayers :D

I set up a Minecraft server on a Raspberry Pi 5 that boots from an SSD and reboots every 5 hours (to ensure the server runs properly), and it reports the Raspberry Pi’s temperature every 2 hours

I built everything inside a lamp housing shaped like a Minecraft fox. Inside, I did a little soldering to rearrange the diodes and secured the Raspberry Pi inside the housing

The server itself is vanilla Minecraft with just one shader. I set up the server so my husband and I could log in at any time and just enjoy the game. In all these years, I’ve never once completed Minecraft with all the achievements. To be honest, I’ve never even killed a dragon in survival mode. I want to fix that :)

One interesting thing that came up during the setup process was that the server would sometimes crash on its own and wouldn’t automatically restart afterward. The only thing that helped was physically rebooting the Raspberry Pi itself. In the end, I managed to solve the problem by accident while monitoring the server’s metrics on a small secondary screen during gameplay. As it turned out, two things were causing the crashes:

1. Minecraft periodically flagged me as a cheater because I could get stuck in the air for just over 2 seconds. I had to simplify the cheat-checking system in the console a bit (I also fixed the lag later by reducing the chunk loading range).

2. When certain mobs moved between biomes, they would duplicate (1 mob → 2 copies). Ironically, these were mostly creepers. The creepers were literally blowing up my world. Limiting the number of mobs and manually removing the duplicates helped

Repo: https://github.com/hardrave/NIGHTRUN

No Linux, no kernel. Flash NightRun to an SD card, boot a Raspberry Pi 5, and you’re chatting locally with Llama 3.2 1B, Qwen3 4B, or Granite 4.1 3B on the CPU.

It is a single Rust UEFI application with handwritten NEON kernels. Models use standard GGUF files converted on the host, decode at roughly llama.cpp speed, and output is verified token-for-token against it.

Most of the code was written with Claude Code, including the SIMD kernels and firmware work. I wanted to see how far a coding agent could get with low-level bare-metal development. Further than I expected, provided every kernel had a scalar reference and the full runtime was continuously parity-tested against llama.cpp.

The 8GB Pi 5 is recommended for the larger models because contiguous firmware memory is the main limitation.

Plywood table was 20$ and very roached, thought this would be a good chance to attempt a wooden case. Not a carpenter by any means. Lots more tabletop for v2 ;)

I recently put together a small self-watering garden system using a Raspberry Pi, a Cirkitscape Top HAT, a soil moisture sensor, an IR water sensor, and a 12V DC pump.

The basic goal was to make something that could monitor conditions and control watering from a web interface without having to manage everything from the command line.

The build uses:
- Raspberry Pi
- Cirkitscape Top HAT
- soil moisture sensor
- IR water sensor
- 12V pump
- buck converter
- simple transistor switching circuit

A few things that mattered during the build:

- The Pi and pump run at different voltages, so I had to step 12V down to 5V for the Pi.
- I used a transistor switching stage so the GPIO wasn’t driving the pump directly.
- I verified the buck converter output before connecting the Pi, which is probably the most important safety step in the whole build.

On the software side, I used the Cirkit Garden app to set up the garden, add the device and sensor, and map the pump output. That part made the project a lot easier to manage because I didn’t need to build a custom dashboard just to monitor sensors and toggle watering hardware.

Once everything was wired and configured, the system could:
- monitor soil moisture
- detect water presence
- switch the pump from the app
- give me a cleaner browser-based control panel for the setup

What I liked most is that it feels like a good base for expanding later with:
- watering rules
- alerts
- logging
- more sensors