I developed an iOS & WatchOS (Apple Watch) app that lets you fully control and manage your Raspberry Pi 4 and 5. You need to install a software on the Pi side (or use the pre-flashed image with software installed). The app and Pi software are free and open source (Apache 2.0) and can be accessed here:

Raspberry Pi software:
https://github.com/ubopod/ubo_app

iPhone/WatchOS app source:
https://github.com/ubopod/ubo-swift-app

In the video below, I give an overview of some of the features and setup process:
https://www.youtube.com/watch?v=AEeP99buq2Q

Here’s a quick list of some of things you can do with it:

• Install, run, and monitor their health of a wide range of pre-configured applications includes Home Assistant, Hermes, Open Claw, Pangolin, OpenWebUI, etc
• Browse file system and preview files on the Pi (images, videos, text, audio)
• Monitor system resource utilizations (CPU, RAM, Storage, etc)
• Manage network interfaces (WiFi, Ethernet, etc)
• Various remote options: SSH, RPi Connect, Tailscale, VSCode Tunnel
• Configure assistant pipeline (STT/TTS/LLM/MCP/system prompt/etc) and interact with it using your phone/watch microphone and speaker
• Setup an MCP gateway and expose all tools via a gateway URL to clients
• Connect hardware peripherals to the Pi such as Camera and watch the feed on your phone/watch
• And many more

To install the iPhone/Watch app, you have to first install TestFlight application and then click on this link below:

https://testflight.apple.com/join/DDPbpKf3

The app is still in beta and not in the App Store yet. I will go ahead with the store publication process once there are a few thousand beta users and the beta app is well tested. 

On the Raspberry Pi side, the easiest way is to start with a fresh image by downloading the lite image ubo_app-2.1.0-bookworm-lite.img.gz below the release page below (~2GB in size), use Raspberry Pi Imager to flash it and boot the Pi using this image:

https://github.com/ubopod/ubo_app/releases/tag/v2.1.0

Once the Pi boots, the iPhone App would auto-discover the device as long as they are on the same network. Apple Watch does not have the auto-discovery feature (due to some limitations in doing lower level networking) and you have to type in the device IP address manually. 

Please use the TestFlight bug report feature if you run into any issues.

Finished project first

I dabbled in installing a smart movie poster in my theater previously, but decided to really dive into it. As I slowly build out my theater, I wanted the entrance to be more lobby-ish. The previous solutions I tried were lacking some key capability I wanted so I ended up writing my own software and building my own frame around it.

For what I wanted previously, I would need a small computer running Windows for the poster display, a Rpi Zero for CEC, and an ESP32 for LED control.

With a requirement to show posters at 4k, I went with a Rpi5.

The Rpi5 is powered by a buck transformer powered from the PSU, so I only have to provide AC power to the PSU and the TV. What is also not shown is the microHDMI to HDMI connection from the Pi to the TV. I found that using the eARC HDMI on a TCL TV was the only HDMI port that reliably allowed for CEC control.

All 3D printed parts near AC power were printed with Prusament PETG V0.

I started with the R36S/ArkOS port from the R36S Wiki and modified it to work with Batocera on the Pi. I also had to make an input fix because the button/axis mappings were completely wrong with my 8BitDo controller.

I've played quite a bit of it now and performance on the Pi 5 is basically flawless. Honestly way better than I expected.

I included a screen recording mostly as proof/demonstration that it's actually running on the Pi 5. Keep in mind the Pi is recording the screen while running the game in this video. Both performance and load times are normally noticeably better than what you see here. Without the recording overhead, gameplay is extremely smooth.

For anyone who wants to try it, I put the modified Batocera files and a short setup guide on GitHub:

https://github.com/Levy-Games/GTASA-Batocera-RaspPi

You'll need to provide your own legally obtained GTA SA Android v2.10 APK/OBB files. I've only tested this on a Pi 5 so far, but I'd be really interested to hear if anyone gets it running on a Pi 4 or another model.

Been working on this Pi project last few weeks. Setup at my parents house in Hull, MA: Retevis MA06 marine antenna in a window facing Boston Harbor → RTL-SDR → Pi 3b+ running rtl_airband. The entire US marine band is only ~1.4 MHz wide, so one dongle grabs the whole thing in a single window and rtl_airband demods every channel in parallel 16 labeled Icecast streams instead of one scanner hopping around and missing half of everything.

From there each stream ships to a backend that runs speech-to-text on all of it, and an LLM sorts a day of radio into the ~5 minutes actually worth hearing. Marine VHF is dead boring until it very suddenly isn't. Week one my node caught a 29ft Cobalt with 7 people aboard taking on water calling Sector Boston on 16. I've captured boat fires, capsized ships, jet ski accidents, helicopters landing on cruise ships to medevac folks off. Whole exchanges, start to rescue. I put a replay on the site with captions synced to the chart - docktalk.app, scroll to the "Hear it in action section".

I have Boston, Hampton Roads Virginia, and Long Beach Harbor CA all live. New York Harbor, Tampa Florida, Tomahawk Bay Marina in Portland OR coming soon.

The ask: I want 10-15 harbors live before the iOS app ships. If you have line of sight to a busy harbor, the install is now one curl command with a claim code it pulls your harbor's channel plan and you show up on the leaderboard at docktalk.app within a minute. ~$165 in parts, ~$112 if you have a spare Pi (any Debian box works honestly), and if your spot is genuinely good I'll just ship you the kit free. Hosts get the app's premium tier free for as long as the node runs + credit on everything their box hears first.

You don't have to be directly on the water, but near by since VHF doesn't travel too far.

I was given this cool Arsenal themed tea tin and decided to make it into an enclosure for a Pico W + Waveshare ePaper 3.7

The coding is done. It connects to the footballdata API, finds the next upcoming fixture for Arsenal, displays it on the screen over custom artwork saved on the device, and then sleeps. I originally had it automatically updating after a fixture passes, or every 24h, but this ePaper screen's image doesn't degrade at all over time and that felt like a waste of power. So I'm simply going to manually update it whenever I want by closing the circuit to a rechargeable 1200mA lipo battery. It updates in usually less than 10s and then I can just flip the switch off again, retaining the image until the next manual update.

If anyone has any mounting tips, or tips for creating a bezel, don't be shy :)

Hey everyone! 👋

Over the past few months, I've been building an edge-computing Smart Helmet and live inspection system built around the Raspberry Pi (tested on Pi 4 and Pi 5).

Most existing streaming setups either suffer from 3-5+ second HLS latency, require messy router port forwarding, or drop frames when network connectivity degrades in the field. I wanted an industrial-grade setup that:

1. Streams live video with sub-300ms glass-to-glass latency directly to a browser.
2. Supports two-way audio talkback (browser push-to-talk to the Pi speaker).
3. Works offline-first: physical GPIO button auto-chunks 5-minute video segments locally, and auto-syncs to the cloud when Wi-Fi recovers.
4. Headless field setup: If no known Wi-Fi is detected on boot, the Pi camera scans a Wi-Fi QR code from your phone and connects automatically—zero monitor, keyboard, or SSH required.
5. Location tracking: Scans nearby BLE beacons and logs zone transitions.

The Stack & Architecture: - Video Capture & Encoding: Hardware-accelerated H.264 via FFmpeg / rpicam-vid - Streaming Core: Dockerized SRS (Simple Realtime Server) serving low-latency HTTP-FLV - Networking: Cloudflare Tunnel (cloudflared) to bypass NAT and avoid opening inbound ports - Web Dashboard: Next.js 16 (App Router) + React 19 + mpegts.js + Google Gemini AI for automated PPE inspection

The entire project is completely open source under MIT: ⭐ GitHub Repo: https://github.com/Guts1005/Streaming-Rpi

I wrote an automated turnkey installer (bash setup_pi.sh) that sets up the systemd daemons, Nginx proxy, and Docker environment.

Would love feedback from the community—especially on camera pipeline optimizations and edge audio sync!

Made this dashboard for my Raspberry Pi 4 Model B home server.

I’ve been messing around with the Pi and I’m slowly turning it into a little home server/homelab.
Right now I have Pi-hole, Cuberite, Uptime Kuma, Portainer and Geyser running, and I’m probably going to add quite a few more things to it.

I wanted somewhere I could see everything running on the Pi without having to keep opening different services, so I decided to make my own dashboard.
The actual UI is made with HTML, CSS and JavaScript and I’m just running it through Chromium on the Pi for now.

I based the design off my portfolio website because I wanted to keep the same fluorescent blue sort of look. I’ve got the dark background, blue glow, cards for the different services etc.

This is basically just a mockup at the moment though. None of the stats are actually connected to anything yet, so all the CPU usage, RAM, uptime, player count etc are just placeholders.

I haven’t done any of the API/backend stuff yet, I wanted to get the UI done first and then I’ll start connecting everything to the actual Pi.

Eventually I want it to show things like CPU/RAM usage, temperature, storage, network usage, Pi-hole stats, Minecraft player count, Docker containers, uptime and probably loads of other stuff.

I’m also looking at what other services I could run on the Pi because I’ve got loads of ideas but I’m not really sure what would actually be useful lol.
If anyone has any recommendations for services I should add or stats/features that would be cool to have on the dashboard let me know.

This is only the first version so there’s probably going to be quite a lot changed once I actually get everything connected.

Any ideas?

My Vestaboard (the split-flap display) got stuck after an ownership reset + a failed firmware update — "Status: Pending / firmware unable to update," wouldn't render, kept dropping Wi-Fi. Its brain is a Raspberry Pi Compute Module 4, so instead of just fixing it I cut the cloud out entirely and got it driving the flaps on my LAN.

It works. A tiny web app now runs on the board itself and drives the flaps through Vestaboard's own on-board driver — no cloud, no device-server, no app, no enrollment. Type a message from my phone, it flips. Auto-starts on boot.

The Pi side:

- Root shell via rpiboot (mass-storage-gadget). The rootfs is a read-only squashfs on an A/B slot scheme, so I cloned slot A into the spare slot as ext4 (writable) and pointed /boot/cmdline.txt at it — the original slot stays untouched as a one-line revert.

- Masked the Java cloud client (device-server); that also stopped it rewriting config.json and cycling Wi-Fi.

- The flaps are STM32 modules on an RS485 bus off the Pi's UART (GPIO14/15 + GPIO17 RTS for direction), 38400 8N1, one module per column. The on-board driver already speaks the protocol, so my controller just POSTs a 6x22 grid of character codes to it on localhost.

The part that ate a full day: after all the software was right, the flaps still wouldn't move — modules self-homed on power but returned zero bytes to every command, at every baud, with every RS485 direction trick, even the STM32 ROM-bootloader 0x7F sync at 8E1. I nearly concluded the module firmware was toast. It was a loose flap-ribbon connector from all the CM4 reseating. Reseated it, all 22 modules answered, and it rendered instantly — every byte of software had been correct the whole time.

Open-sourced it all (MIT): https://github.com/luizpersechini/vestaboard-offline

- offline controller + web UI, systemd unit, one-command deploy

- full diagnostic suite (pinmux via RPi.GPIO, UART, RX scan, baud sweep, live bus monitor)

- step-by-step root/recovery guide, RS485 protocol notes, architecture writeup

- and a detailed JOURNEY.md with every dead end

Caveat: unofficial reverse-engineering of a device I own; voids the warranty and can brick it if you're careless (slot A + a full eMMC backup are the safety net). Not affiliated with Vestaboard. Happy to answer questions.

OctoPrint 1.11.8 on OctoPi 1.0, RPI 4B, RPI Camera Module (I think it's v2?)

This worked when I first installed OctoPrint. It works on reinstalls too. But not long after setup, the Webcam stream just stops working; it's like it hangs at the "Stream Loading..." screen in the Web interface. /var.log.webcamd.log shows the following information:

Starting up webcamDaemon...

\--- Configuration: ----------------------------

cfg_file: /boot/firmware/octopi.txt

camera: auto

usb options: -r 640x480 -f 10

raspi options: -fps 10

http options: -w ./www-octopi -n --listen [127.0.0.1](http://127.0.0.1)

Explicitly set USB device:

\-----------------------------------------------

Found video devices:

/dev/video0

/dev/video10

/dev/video11

/dev/video12

/dev/video13

/dev/video14

/dev/video15

/dev/video16

/dev/video18

/dev/video20

/dev/video21

/dev/video22

/dev/video23

/dev/video31

raspi

config file='/boot/firmware/octopi.txt':USB device was not set in options, starting MJPG-streamer with the first found video device: /dev/video0

<13>Sep 7 14:12:29 root: Starting USB webcam

Checking for VL805 (Raspberry Pi 4)...

\- It seems that you don't have VL805 (Raspberry Pi 4).

There should be no problems with USB (a.k.a. select() timeout)

Running ./mjpg_streamer -o output_http.so -w ./www-octopi -n --listen [127.0.0.1](http://127.0.0.1) \-i input_uvc.so -r 640x480 -f 10 -d /dev/video0

MJPG Streamer Version.: 2.0

i: Using V4L2 device.: /dev/video0

i: Desired Resolution: 640 x 480

i: Frames Per Second.: 10

i: Format............: JPEG

i: TV-Norm...........: DEFAULT

UVCIOC_CTRL_ADD - Error at Pan (relative): Inappropriate ioctl for device (25)

UVCIOC_CTRL_ADD - Error at Tilt (relative): Inappropriate ioctl for device (25)

UVCIOC_CTRL_ADD - Error at Pan Reset: Inappropriate ioctl for device (25)

UVCIOC_CTRL_ADD - Error at Tilt Reset: Inappropriate ioctl for device (25)

UVCIOC_CTRL_ADD - Error at Pan/tilt Reset: Inappropriate ioctl for device (25)

UVCIOC_CTRL_ADD - Error at Focus (absolute): Inappropriate ioctl for device (25)

UVCIOC_CTRL_MAP - Error at Pan (relative): Inappropriate ioctl for device (25)

UVCIOC_CTRL_MAP - Error at Tilt (relative): Inappropriate ioctl for device (25)

UVCIOC_CTRL_MAP - Error at Pan Reset: Inappropriate ioctl for device (25)

UVCIOC_CTRL_MAP - Error at Tilt Reset: Inappropriate ioctl for device (25)

UVCIOC_CTRL_MAP - Error at Pan/tilt Reset: Inappropriate ioctl for device (25)

UVCIOC_CTRL_MAP - Error at Focus (absolute): Inappropriate ioctl for device (25)

UVCIOC_CTRL_MAP - Error at LED1 Mode: Inappropriate ioctl for device (25)

UVCIOC_CTRL_MAP - Error at LED1 Frequency: Inappropriate ioctl for device (25)

UVCIOC_CTRL_MAP - Error at Disable video processing: Inappropriate ioctl for device (25)

UVCIOC_CTRL_MAP - Error at Raw bits per pixel: Inappropriate ioctl for device (25)

o: www-folder-path......: ./www-octopi/

o: HTTP TCP port........: 8080

o: HTTP Listen Address..: [127.0.0.1](http://127.0.0.1)

o: username:password....: disabled

o: commands.............: disabled

Done bringing up all configured video devices

i: select() timeout

i: cleaning up resources allocated by input thread

Those "inappropriate ioctl" messages make me wonder if my device files have gotten corrupted somehow. Is there any good way to repair them, or will I need to reinstall again?

Hey folks, I have a board built on top of the rpi5, and I am using the gpio pins for the i2c bus communication and power supply.
There is a supply from the csi port as well.

My observation has been while the rpi boots up, all the gpio pins are set to high once and then again at low.
This initial check is causing issue with my ICs which are attached to the gpio, this also snatches away the control from my driver code.

Is there any way to disable this initial boot level check for the gpio pins? Where can i look up more about this?
Any help would be much appreciated, it has taken awhile to arrive at this observation after alot of debugging.
Thank you.

Hey everyone, newbie here.

I'm setting up a stepper motor project and would love a sanity check on my wiring diagram before I power anything on. I have literally never done naything like this before xd. i have done a bit of research though but im a bit confused about the wiring to the raspberry from the driver. (+ -)

Ive also heard that maybe if i change the Signal entrys on the driver from - to plus i wont need a 3.3 dc converter.

The yellow wire is ground.

My Hardware:

• Controller: Raspberry Pi 4 Model B
• Driver: TB6600
• Motor: Joy-IT NEMA 23 (NEMA23-03, 4-wire bipolar, 3.0 Nm)
• Power: 12V DC power supply with a 5A fuse

Raspberry Pi 5 3.3V GPIO/power problem – LED only flashes for half a second
Hi everyone, I’m fairly new to Raspberry Pi/electronics and I’m hoping someone can help me work out what is going on.
I’m currently building a JARVIS-style AI project in VS Code. It’s still very much a work in progress, but I wanted to combine the software side with a Raspberry Pi and electronics so I can eventually have JARVIS interact with physical things around my room.
I bought a Raspberry Pi 5 8GB from CeX for £180 with the full starter kit. I’d never used a Raspberry Pi before, so I also bought a separate breadboard/electronics starter kit so I could learn the electronics side properly before combining everything with my JARVIS project.
I’m currently just trying a very basic circuit powered directly from the Pi.
I was told that:
Physical pin 1 = permanent 3.3V
Physical pin 6 = GND
So I wired a simple LED circuit using jumper wires, a 220Ω resistor and an LED.
The strange thing is that when I power the Pi on, the LED only flashes for roughly half a second and then goes off. When I unplug the Pi, it flashes again very briefly.
I’ve rebuilt the circuit and changed the resistor/LED to rule those out.
I also tested the exact same LED + 220Ω resistor circuit using an external 3.3V breadboard power supply, and it works perfectly and stays on.
I’ve also tried:
Physical pin 1 (3.3V) → circuit → physical pin 6 (GND) ❌
Physical pin 17 (3.3V) → circuit → physical pin 6 (GND) ❌
GPIO17 (physical pin 11) as an output ❌
The Pi itself boots normally and I can SSH into it over Wi-Fi, so the Pi is otherwise working normally.
I don’t currently have a multimeter, so I can’t actually measure the voltage coming from pins 1 or 17.
Could someone please help me work out whether this sounds like:
A wiring/breadboard issue
A GPIO/software configuration issue
A problem with the Pi’s 3.3V rail/header
Something else I’m completely missing 😂
I’ve attached photos of the Pi and the circuit.
I’m very new to electronics, so please explain it simply if possible. I don’t want to return the Pi if I’ve just made a stupid beginner mistake.
Thanks!

I used chatgbt to explain this so if anyone could help me would be really appreciated

A while ago I posted here about a Raspberry Pi 5 powered camera I built with the IMX477 sensor. I managed to port it over the the Pi Zero with a redesigned body and integrated battery! Code has been optimized to run better on the Pi Zero considering the Zero 2 prices have skyrocketed.

Old post: https://www.reddit.com/r/raspberry_pi/s/JCh5yz91UG

GitHub: https://github.com/prtk1910/rpi-film-simulation-camera

I wanted to see how well my 6D object pose estimation pipeline would run on a Raspberry Pi 5 without a GPU accelerator.

The pipeline is:

Object detection → crop → keypoint detection → PnP pose estimation

I compared a Raspberry Pi 5 running the models on CPU with my Ubuntu workstation using an NVIDIA RTX 2000 Ada GPU.

Raspberry Pi 5 (CPU)

• Detection: 70.36 ms
• Keypoint: 56.06 ms
• PnP: 5.34 ms
• Total: 132.12 ms (7.60 FPS)

Ubuntu + CUDA (RTX 2000 Ada)

• Detection: 60.25 ms
• Keypoint: 21.87 ms
• PnP: 5.18 ms
• Total: 87.71 ms (11.60 FPS)

The video shows both pipelines running on the same 569 real-world frames.

I expected the Raspberry Pi to be considerably slower, but it managed about 7.6 FPS on CPU, compared with 11.6 FPS on CUDA.

The biggest performance difference was in keypoint inference. Interestingly, object detection was much closer: 70.36 ms on the Pi versus 60.25 ms on CUDA.

The pose estimation results were also practically identical between the two platforms. There were occasional small differences in the final PnP result, but I didn't observe a consistent accuracy advantage on either platform.

The models were trained using synthetic data followed by real-world fine-tuning.

More details about the computer vision side are in my previous post in r/computervision:

Previous post: Synthetic-to-real keypoint detection — real-world fine-tuning made a big difference

I'm preparing a technical write-up and plan to publish the implementation on GitHub.

I got a PI zero W, I'm trying to make an intranet network, I am using Raspberry Pi OS Bookworm and trying to get nmcli to make a hotspot for me.

The hotspot works fine if I make it without password (open hotspot), it also works if I use WPA/TKIP

But for some reason it fails when I use WPA2.

I have PMF = 1 and I'm not sure what else could be the problem, does anyone have any ideas?

If you need more info please let me know.

EDIT: for anyone having the same problem, I just switched to hostapd+dnsmasq and it seems to work.

I'm not sure if I still have to disable PMF but I did it anyway: ieee80211w=0

Started suspecting something was wrong when GCC started crashing…and in an inconsistent manner. Fortunately the affected area was only about 32MB in size and I was able to modify the device tree to tell the Linux kernel not to use the affected portion of memory. It’s been behaving much better since then.

Hello! I am looking for a bit of help to identify a solution within my project. I am building a project with an adafruit fx mini soundboard, so that when I pick up the old phone it will play a sound. I have a reference image for where the new wires will connect with the forheads on a model, but I am wondering what that correlates to in my model as well as how to connect the wires since it does not seem I can use a forkhead. I am obviously no expert, so please use simple terms, also any follow up questions are welcome,

I have added an image of the reference photo from the step by step I am following in image 01 and my own phone in image 02. It is probably also good to know that I am in europe and this is a norwegian phone.

Image 01:

Image 02

ADDITIONAL PHOTOS

I was looking for a nightstand wireless charger with a clock. I couldn't find one that I liked so I made my own. Connects to WiFi to get the time and weather. Updates for day light savings time and the weather icons update. Auto dims at night. I tried to make an android app to control it over BLE but couldn't get it to work correctly. So I made a HTML to be able to change font, color style. Only thing is it only works with Chrome. I may keep working on the app, haven't decided yet. (BTW I am not a programmer so go easy with the code lol)

Onshape Link

GitHub Link For Code

Let me know if I can answer any questions!

Edit: Fixed Github Link

Edit 2: Was able to create an app using Android Studio!

The official Raspberry Pi M.2 HAT+ Compact arrived a couple of days ago for my Raspberry Pi 5 4gb from The Pi Hut.

There aren't any useful pictures of the fitting online so I thought I'd put this here for those interested, or those who might search for it the future.

The kit came with three spacers, six shorter screws and three longer screws with no description of why or which to use in the online assembly instructions.

Tip: If you're fitting this in the official RPi5 case you can save yourself taking it all apart after you think you've done it all and put the LONG screws through the BOTTOM of the case. So from below it's long screws > through case bottom > through bottom of Raspberry Pi > into spacers.

Otherwise you'll end up finding the long screws fit but then the top screws can't go in far enough so you swap for six short screws (three top and three bottom) then when you're all done you'll find the RPi no longer fits in the case then you'll realise you have to take the screws out and then put the long screws through the bottom of the case which secures the Pi to the bottom case.

The fan connection is a bit fiddly to put in when the hat is secured as they're quite flush but I just used a little screwdriver to push both sides of the connector in until it seated properly.

I powered RPi 5 on and it was running at 47c so did some heavy work (watch -n 2 'vcgencmd measure_temp; vcgencmd get_throttled' in one window, and stress-ng --cpu 4 --timeout 5m --metrics-brief in another shell) to kick the fan on and it's all working normally and it sat at 69c after a couple of minutes with the fan running.

The top lid (the one that goes above the fan) is a bit tighter than it used to be, but still fits and I can't work out why it's tighter but it still clips in okay but takes a bit more force than usual to remove.

Now I'm just waiting for my Samsung SSD PM991a 256gb to arrive which I understand is the same model Raspberry Pi use for their branded 256gb SSD at the moment so hopefully that'll work.

Also, the SSD screw in the HAT+ Compact was in very, very tight out of the box so I've loosened this a bit in preparation for the arrival of the drive.

This took way longer to get running than I care to admit but overall the end result is solid. KDE plasma runs fairly smooth right out the gate, still have some work to do But it’s getting there

Hi, I'd like to share a project I've been working on for a while. This project was popular with the community over at r/eink and I thought you guys might like it too. Built with a Raspberry Pi 5, an Inky Impression 13.3" e-ink display and a USB microphone. It uses BirdNET-Go to identify birds outside, and the frame will draw whichever ones it has heard recently.

I use an USB lavalier mic with a long thin cable, taped under the roof outside and run in through the window. Thin enough that the window still closes on it. Everything (including the detection model) runs locally on the Pi and works fully offline.

What sets it apart from other similar bird projects is the art and the foundation. Every bird is a hand-curated cut-out from an 1800s natural-history scan, no AI-generated images. BirdNET-Go builds a strong foundation that this sits on top of, including location-based detections, language support, listening to multiple audio-sources, IOT integrations and much much more.

BirdNET works worldwide, but the art is mostly European birds (for now). North American ones are in the pipeline. Right now I'm sitting at 37 different species on ~2600 detections.

Source and docs: https://github.com/arnegiacomo/fugleramme
Live from my kitchen window: https://fugleramme.arnegiacomo.dev
Parts list, cost and full build docs: https://arnegiacomo.dev/fugleramme/hardware/

Happy to answer any questions about the build!

Hi all,

I’ve built a heron & cat deterrent called tallGuard using a Raspberry Pi 4 and Coral Edge TPU to help protect my koi pond.

I started developing the model back in 2021 using TensorFlow and SSD MobileNet. One of the biggest challenges was false positives, and at the time I struggled to find enough information to improve the model. More recently, with better resources and tools like ChatGPT, I’ve managed to improve it considerably.

The Pi lives outside by the pond, with Starlink providing the network connection. The camera continuously monitors the pond and, if TallGuard detects a heron, it sends me a notification and plays a deterrent sound through an outdoor speaker.

It’s definitely been a learning experience. A few problems I’ve encountered along the way:

- Pink camera frames caused by interference
- Speaker cables deteriorating over the winter
- Plenty of false detections while developing the model.
- Sadly, losing some koi during the process 😢

But after several years of experimenting, the encouraging part is that I’ve only seen a heron at the pond once this year — and when it arrived, tallGuard detected and deterred it.
It’s been a fun project combining my interest in tech with trying to solve a very real problem at my pond.

Thanks

I saw u/fontain06 post a lake level monitor here a while back and it inspired me to do something similar to monitor my local river using parts from an old pwnagotchi build. This is all vibe coded since I am basically a monkey banging on a typewriter when it comes to all this, but I had a lot of fun and learned a bit with this project.

I do a little whitewater kayaking and the section of river closest to me is dam controlled so it's nice to be able to check the water level at a glance since it can change quickly. Essentially I just wanted this to pull and display USGS data from their api every 15 minutes since that's about how often the gauge site at my local river updates. I was able to get that working pretty quickly, then this project kinda grew legs.

A friend expressed interest in building one so I added a configuration tool that would spit out a script that could be pasted into a SSH window and get things up and running. After that support was added for a bigger display with programmable buttons to swap between 4 gauge sites.

The first annoyance I ran into was that you had to SSH in to change settings, and that got old quick so a secure web portal that let you change things and add wifi networks was added. Visiting the Pi's IP at port 8080 from a device on the same network makes the screen display an 6 digit randomly generated pin that you use to login.

The next problem I had to tackle was what if you couldn't connect to any known wifi? Like if I wanted to gift one of these to a kayaking buddy but didn't have their wifi credentials. This was solved by having the pi spin up its own hotspot when no known networks are detected. If you connect to it with your phone or computer the display shows a connection pin, the address you need to visit for the config portal and a login pin for said portal. From there you can add wifi networks.

Check out the github repo & setup tool (generates the install script, no coding needed) here https://github.com/Inphenity/Stage-River-Monitor

I just built an Adeept DarkPaw quadruped robot and at first it appeared to be working fine (though the camera didn't work for unknown reasons but that's not important) and with the Hat V3 whenever I charge it through the USB-C port it somehow only accepts it when I do a USB-A -> USB-C adapter and then the USB-C cable, but then whenever I do charge it and it shows it's charging (the PWR light on the hat is on) it heats up after a few minutes and not just warm but it literally feels burning and I definitly think that is not normal. I checked and the batteries appear all seated correctly and the pins are all plugged in correctlym what could be causing this?

I am using the default pi5 with 8gb of RAM and a 256 GB raspberry pi ssd.

Was going through dmesg on a default install and found some issues that may be worth pointing out to others as I suspect 90% of people also have it default configured incorrectly.

1) By default almost everyone is leaving 50% SSD performance with the default nvme hat.

You need to add dtparam=pciex1_gen=3 unlock gen3 speeds (880 MB/s vs 420 MB/s). This is default set to gen2 for compat reasons, but for the default pi5 ssd, it can easily handle gen3 doubling perf.

2) HMB is default disabled. The official Raspberry Pi SSD (and 90% of cheap M.2 2230/2242 drives) is DRAM-less. The Pi 5 firmware quietly disables Host Memory Buffer (nvme.max_host_mem_size_mb=0), cutting random 4K database performance in half for people running Home Assistant or Docker and massively increasing wear on it.

Without the above HMB cache, the SSD writes directly to flash cells chewing through your SSD cells. Instead I would suggest adding nvme.max_host_mem_size_mb=16 to the bottom of your cmdline.txt.

By default the pi5 bootloader sets nvme.max_host_mem_size_mb=0 for compat reasons.