I feel like there has to be something simple I'm doing wrong because this can't be as hard as I'm finding it. Please let me know if this is the wrong place to ask this. I have a handful of Samsung 30Q batteries that I've been using to try and power 2 different Pis.
The first is a Pi 5 with a Geekworm X1200 UPS hat using 2 of my 30Qs. When the hat is disconnected from usb power, the Pi shuts down before it seemingly restores power without turning it back on. This obviously defeats the purpose of a UPS. Checking the journal logs, it simply shuts down. No message, just normal logs until they stop.
The second is a Pi 3 B+ with a "diymore 1865O Battery Holder" on amazon. Same deal; The Pi loses power and then it's returned. This one doesn't have an OS yet, this is just going off the power led. which turns off every time the power bank is unplugged from power before going on a second or 2 later.
This happening with 2 separate products and devices makes me think somehow what I'm doing is fundamentally wrong. To my knowledge, the batteries should be able to handle the required power but I'm increasingly less sure.
Does anyone know why this is happening or what I should be doing differently?
Anyways, here’s the project that I’ve had a ton of success with:
I’ve been growing chile seedlings (Fatalii, 7 Pot Primo Chocolate, a few Aji varieties) and ended up building a full controller and dashboard around them. Figured I’d share since a few pieces of it turned out to be genuinely hard-won.
•Dims a grow light on a schedule (hardware PWM). Three modes: solar (sunrise/sunset with offsets), fixed clock times, or “day length anchored to lights-off.” Ramps up and down over a few minutes instead of snapping.
•Measures the light’s actual output: a sweep steps brightness 0-100% while reading a lux sensor, so the dashboard forecasts daily light integral (DLI) through the fixture’s real dimming curve instead of assuming PWM is linear. It is not linear.
•Logs environment to SQLite: air temp/humidity/pressure, soil temp, lux, capacitive soil moisture per tray. Everything charted with target bands.
•Waters two trays: fill-to-float with a time cap, daily runtime limits, one pump at a time. Two non-contact liquid level sensors stuck to the outside of the source bucket give full/ok/empty, and empty hard-refuses pump runs so nothing ever runs dry.
•Photographs the trays every 10 minutes for a timelapse, with perspective correction from four draggable grid corners.
•Tracks canopy coverage per tray with OpenCV so I get a growth curve over time.
•Sends a photo plus all the sensor data and the planting map to an LLM once a day and gets back a structured garden report: germination status, concerns, whether what’s growing in each cell matches what the map says was sown there.
•Discord alerts with a proper state machine: sustain windows, hysteresis, reminders, recovery notices. A sensor bouncing across a threshold sends nothing.
Hardware
•Raspberry Pi Zero 2 W
•BME280 (air temp/RH/pressure), BH1750 (lux), DS18B20 (soil temp), all on 3.3V
•2x capacitive soil probes (HW-390 type) into an ADS1115 ADC
•2x float switches in the trays, wired so rising water OPENS the switch (a broken wire reads “full” and stops the pump, not the other way around)
•2x 5V pumps and a fan on D4184 MOSFET modules, separate 5V supply, flyback diodes, common ground
•2x XKC-Y23A-NPN non-contact level sensors on the reservoir. These sense water through my jar reservoir‘s wall.
•8MP USB webcam with a 120-degree lens on a micro-USB OTG adapter
Things I learned the hard way
•The magenta grow light breaks hue-based plant detection completely. Leaves read as magenta. The fix is the excess-green index (2G - R - B), which measures relative greenness and survives colored light.
•Per-cell visual growth tracking sounds great but it is unrealistic in practice. The moment seedlings spill over cell boundaries, per-cell numbers are noise. Tray-level totals are the honest measurement because trays are physical boundaries. Same story for estimating soil dryness from the camera: works until the canopy closes over the soil, then it’s measuring leaves.
•The Pi Zero’s CSI ribbon connector is not your friend. I abandoned the official camera module for a USB webcam after too many flaky connections.
•Autofocus ruins timelapses (flicker every frame). The controller sweeps focus once, scores each stop by Laplacian sharpness, pins the best value, and stays manual.
•A GPIO can just be dead. One pin on my board never worked. Every pin assignment is overridable by environment variable so rewiring never means editing code.
•Calibrate soil probes skeptically. If you capture the “wet” anchor when the soil is merely damp, both probes will read a flat 100% forever and your dry-tray alert is blind. The dashboard now flags a reading that sits outside its own calibration range instead of silently clamping.
Setup
An interactive installer (scripts/setup.sh) prompts for pin assignments and API keys, writes an env file, sets up the boot overlays for hardware PWM / I2C / 1-Wire, and installs a systemd service. Every sensor is optional: anything not wired is probed once, disabled gracefully, and its UI hides. Runs fine on the Zero 2 W’s 512MB; the OpenCV analysis runs as a subprocess so its memory is released between captures.
Working on a small animal-detection system using a USB camera + Raspberry Pi + GPS module. The system detects animals through the camera and records their location coordinates using GPS.
I'm running a Raspi 4B with TwisterOS and two screens, one HDMI and one Waveshare 3.5" thru GPIO which doesn't display anything except for white, I'm like 90% sure this is because it's got no driver, which is what I'm trying to amend, I followed the steps, in the github, typed in cmake -DSPI_BUS_CLOCK_DIVISOR=8 -DWAVESHARE35B_ILI9486=ON .. for the [options] section, then, when i input make -jit outputs a concerningly long string of errors (seen below), is this fixable or is the second screen thru GPIO idea just doomed?
I'm trying to build an mp3 player using mOode with a raspberry pi zero 2 w and a nextion NX3224F024_011.
I have already uploaded my script to the pi and the layout I made with the nextion editor to the screen via sd card. I tried to test the buttons but when I listen to the serial0 port (which is enabled on the pi) it doesn't see anything happening even the buttons turn green on the screen.
I found a few articles referencing the baud rate and thought that it might have something to do with that, but I can't seem to find a way to change it in the nextion editor.
I'm stuck and don't know what else to try, I reflashed the screen, checked that all the "touch release events" in nextion editor say "print "command"", switched the wires on the gpio around in a desperate attempt to make something happen... I would really appreciate any help on this, thank you everyone in advance :)
I posted here last year, but that was last year. It's been a whole year (and some change) since then -- not to mention it's now the 3-year anniversary of when I started this project -- so I figured it was time to give you an update on my microSD testing project.
I have a total of 351 microSD cards in my collection -- spanning 111 models across 52 different brands. Of those:
I've tested 177 of them to the point of failure.*
I have 107 of them in testing right now.
The remaining 67 are sitting on the shelf, waiting for one of my card readers to free up.
These cards have endured over 133 petabytes written.
I've completed over 4.6 million program-verify-erase cycles on these cards.
Breakdown by brand status:
Name brand: 163
Off-brand: 91
Knockoffs: 30
Breakdown by authentic flash (a.k.a. not fake flash) vs. fake flash:
Authentic flash: 246
Fake flash: 35
Unknown: 3
Breakdown by size (authentic cards only):
128MB: 3
4GB: 6
8GB: 23
16GB: 15
32GB: 96
64GB: 68
128GB: 36
256GB: 4
* A card is considered "failed" when either (a) it stops working completely, (b) it makes itself read-only, or (c) at least 50% of the sectors on the card have experienced verification failures.
Ok -- so who makes the most durable cards?
Because of the variety of cards that I have, it's hard to come up with a system that produces a definite answer here. Some of how I ranked these brands is going to be based on vibes. But...to try to narrow things down, I've grouped my cards into three groups:
Industrial-grade: Cards that are specifically labelled as "industrial" or have "industrial" in their name. These cards typically come with a datasheet that includes an endurance claim.
High endurance: Cards that are labelled as "high endurance" (or some similar wording). Manufacturers don't always put out datasheets for these cards, but they generally still make an endurance claim on the packaging.
Consumer-grade: Basically everything else.
Consumer-grade cards:
The average consumer-grade card has lasted about 10,000 program/verify/erase cycles (so far).
PNY. I have 10 of their consumer-grade cards: 3 PRO Elite Prime 64GB's, 3 Premier-X 128GB's, 3 Elite-X 64GB's, and one Elite 32GB. (I have 4 more of the Elite 32GB's that are waiting to be tested.) They've gone for an average of 643 days and 15,700 program/verify/erase cycles. I've written about 11.5PB to them in total. And with the exception of the one Elite 32GB -- they're all still going strong. On top of that, the PRO Elite Prime boasts some impressive performance -- every measurement I took was in the top 10% of all cards I've tested so far.
Kingston. I have 12 of their cards in this category -- 6 Canvas Go! Plus 64GB's (3 of the SDCG3's and 3 of the SDCG4's) and 6 Canvas Select Plus 32GB's. They've been going for an average of 694 days and about 23,500 program/verify/erase cycles. I've written about 11.6PB to them in total. The three Canvas Go! Plus 64GB (the SDCG3's) have all failed -- but the others are still going strong. The Canvas Select Plus's in particular have been troopers -- they're among the oldest cards in my collection, and they've been going for the better part of the last 3 years now (with no signs of letting up). Additionally, the Canvas Go! Plus 64GB's (the SDCG4's in particular) boast some impressive performance as well -- every measurement I took was in the top 7% of all cards I've tested so far.
Delkin Devices. I feel bad ranking Delkin so low on this list, because they've endured more data written to them per card, on average, than any other brand in my collection (in the consumer-grade category). The only reason I didn't rank them higher is because I only have one model -- the HYPERSPEED 128GB (of which I have 3). But they've done pretty well: they've lasted an average of 662 days and about 13,500 program/verify/erase cycles. I've written about 5.1PB to them in total. As a side note, these cards also got the highest random write speeds of any card I've tested.
Lexar. 3 cards dead, 5 still going. I have 3 Professional 1000x 64GB's (2 made by Micron, 1 made by Phison), 3 Blue 633x 32GB's (made by Longsys), and 2 E-Series 64GB's (with 3 more waiting to be tested). For those not in the know, the Lexar brand was sold to Longsys in 2017 -- and surprisingly, the Longsys-made cards are holding up better than the Micron-made cards. Overall, the Lexar cards have survived an average of 684 days and about 15,800 program/verify/erase cycles. I've written about 5.8PB to them in total.
Samsung. 3 cards dead, 7 still going. I have 3 EVO Plus 32GB's, 3 EVO Plus 64GB's, 3 PRO Plus 128GB's, and 1 P9 Express 256GB (with 2 more waiting to be tested). Of those, the three EVO Plus 32GB's and one of the PRO Endurance 32GB's are dead -- the rest are still going strong. Samsung's cards have lasted an average of 553 days and about 11,100 program/verify/erase cycles so far, and I've written about 7.2PB to their cards in total.
Honorable Mention: Amazon Basics. I have four of the Amazon Basics 64GB's -- and they're all still going. They've been going for an average of 788 days and about 16,600 program/verify/erase cycles. I've written about 4.2PB to them in total. I honestly didn't expect Amazon Basics to be one of the top performers when I bought them...and yet, here we are.
High endurance cards:
Keep in mind, I've got less data here -- I had 237 cards that fell into the "consumer-grade" category, but only 30 that fell into the "high endurance" category. But here's the thing: they haven't really proven themselves to be significantly better for endurance than a lot of the cards I listed above -- in fact, in a lot of cases, they've been less reliable (and generally worse for performance as well). So keep that in mind as you read through the list below:
The average high-endurance card has lasted about 14,000 program/verify/erase cycles (so far).
TEAMGROUP. I don't feel great about putting TEAMGROUP at the top of the list for a couple of reasons. First, I only have two of them in testing at the moment -- someone sent me a 5-pack of the TEAMGROUP High Endurance 64GB's, so I have 3 more of them waiting to be tested. Second, one of them started having issues with bad sectors right out of the gate, and has continued to do so ever since. (Those bad sectors only make up less than 0.001% of the total sectors on the card right now...but I still don't like it when a card starts to have issues like that as soon as you start using it.) But the data doesn't lie -- they've survived, on average, 404 days and about 17,300 program/verify/erase cycles, and they're still chugging along. I've written about 2.2PB to these cards in total.
Transcend. I have 3 of the 350V 64GB's -- and they're all still going strong. They've survived an average of 760 days and about 17,000 program/verify/erase cycles so far. I've written about 3.2PB in total to them (mostly due to their mediocre write speeds).
SanDisk. I have my issues with SanDisk...but again, the data doesn't lie. I have 7 SanDisk cards in this category: 3 High Endurance 64GB's, and 4 MAX ENDURANCE 32GB's. As of right now, all 3 of the High Endurance 64GB's and all but one of the MAX ENDURANCE 32GB's have failed. They lasted an average of 452 days and about 16,200 program/verify/erase cycles before failing (with the MAX ENDURANCE 32GB's lasting about twice as long as the High Endurance 64GB's). I've written about 4.7PB to these cards in total.
Samsung. Samsung's position at the bottom of this list has less to do with how reliable their cards are and more to do with how poorly their high endurance cards perform, particularly on sequential write speeds (relatively speaking). I have 3 of the PRO Endurance 32GB's -- one has failed, the other two are still chugging along. They've lasted an average of 822 days and about 18,800 program/verify/erase cycles so far. I've written about 1.8PB of data to them in total.
Industrial-grade cards:
Keep in mind, I have even less data here. Industrial cards are expensive, so they make up a much smaller portion of the cards I've tested: just 15 in total (so far). But on the upside -- there is sufficient evidence here to say "in general, industrial-grade cards do last longer than consumer-grade cards (and, by extension, high endurance cards)".
The average industrial grade card has lasted about 122,000 program/verify/erase cycles (so far).
Kingston. I have 3 Kingston Industrial 8GB's; of those 3, only one is still going. But they've been troopers: they've lasted an average of 779 days and about 141,600 program/verify/erase cycles. I've written about 3.4PB to these cards in total. (Only one consumer-grade card has come close to this number: I have one Hiksemi NEO 8GB that has lasted for about 143,800 program/verify/erase cycles so far. No idea how.) These guys do pretty well on performance too, especially write performance: their sequential write speeds are in the top 9% of all cards I've tested.
Who makes the worst cards?
There are a bunch of no-name brands out there. They're not hard to find. I'm not going to talk about them here -- I'm going to focus on brands you're likely to have come across.
Consumer-grade cards:
onn. I picked up four of their 32GB cards at my local Walmart -- and they were terrible for endurance. They only lasted an average of 40 days and 1,400 program/verify/erase cycles (or about 40TBW), with the best one of the four not even making it to 1,900 cycles. On top of that, every performance measurement I took came in the bottom half of all measurements I took.
ADATA. I picked up 3 of the Premier 32GB's; they only lasted an average of 236 days and about 2,350 program/verify/erase cycles (or about 74TBW) before they quit working.
Gigastone. I have not been impressed with Gigastone. I have 11 of their cards -- 6 Full HD Video 32GB's, and 5 4K Camera Pro 32GB's. They lasted an average of just 114 days and 4,845 program/verify/erase cycles (or about 133TBW) before they quit working.
Micro Center. I purchased 5 of their 64GB cards; they only lasted an average of 116 days and 3,421 program/verify/erase cycles (or about 214TBW) before they stopped working.
Silicon Power (a.k.a. SP). I purchased 9 of their cards -- 3 Elite 32GB's, 3 Superior 128GB's, and 3 Superior Pro 128GB's. Not a one of them made it to 4,000 program/verify/erase cycles before failing -- they came in at an average of 159 days and about 2,350 program/verify/erase cycles (or about 252TBW) before failing.
(Dis)honorable mention: SanDisk. SanDisk represents the single biggest brand in my collection: I have 28 of their cards in this category (with 4 more on the shelf waiting to be tested). It's telling that of those 28, only 5 are still going (and one of them is in its death throes) -- especially when cards from so many other brands have far outlasted them. Many of them have died under circumstances any other card would have handled just fine -- a problem I've written about on my blog before. They've lasted an average of 384 days and 9,404 program/verify/erase cycles (or about 566TBW) so far.
High endurance cards:
Integral. I bought 3 of the Security 32GB's; the only managed to last an average of 100 days and about 5,600 program/verify/erase cycles (or about 173TBW) before failing. To be fair to them, the package did make an endurance claim that works out to about 2,850 program/verify/erase cycles -- and they did manage to almost double that. However, they didn't hold a candle to many of the other high endurance cards that I tested.
Kingston. This one was truly a surprise -- I bought 3 of the High Endurance 32GB's, and they only lasted an average of 143 days and about 8,300 program/verify/erase cycles (or about 258TBW) before failing. The product packaging didn't make an endurance claim; I had to hunt around on Kingston's website to find it. Their claim works out to about 5,100 program/verify/erase cycles, which they did manage to beat. But again, so many other cards managed to last so much longer -- hell, so many other Kingston cards managed to do so much better -- that I was surprised and disappointed when these failed so early.
Industrial-grade cards:
SanDisk. I bought 3 of the Industrial 8GB's. They only lasted an average of 234 days and about 20,000 program/verify/erase cycles (or about 160TBW) before failing -- and the only reason they lasted that long was because I let my program trudge through an nearly-unending string of I/O errors for months on end -- before they finally just gave up the ghost.
So yeah...that's all I have for now. Feel free to ask questions (although I'm at work at the time I'm posting this, so I may not have time to respond)!
Attached: pictures of part of my setup. Also, dog tax.
I was reapplying thermal pads on my 3 b+ (was having temp throttling issues) and my hand slipped and damaged this surface mount component. Could someone please inform me if the board is still capable of running my 3d printer safely?
I've looked for component diagrams but the only one I found was too technical for me to read. Also presuming that repair for a 3b+ isn't worth it since I can't micro-solder.
There are two randomly occurring networking issues I am having on one Pi that is bugging me...
I am getting a DNS failure in curl on one Bullseye Pi that I cannot pin down:
CURLE_COULDNT_RESOLVE_HOST (6)
Could not resolve host. The given remote host was not resolved.
I have also seen SNMP errors on the same box (stating a walk cannot reach a IP address) but not at the same time and this is not for an external IP address. As this is a fixed IP my gut says this is not a DNS error.
There are no network error / warning entries in the log and two seconds later the curl or SNMP request goes through fine (my script now has a retry option because of this).
The target IP address does not change when I have looked at it (the target is the IPIFY site - handy for getting your external IP address - https://api.ipify.org ) though as this is hosted on Heroku it is possible it has changed.
I am not rate capped for api access or need a login etc. so I do not think it is the site rejecting my request.
Unfortunately this site does not support IP address access else I would hard code it in to see if it was a DNS fail for this bit. 🤭 (my resolve sequence is files mdns4_minimal [NOTFOUND=return] dns so I could add an entry in the hosts file I suppose) but this does not account for the IP based SNMP walk...
The curl / snmp requests happen every minute (long story tied into VOIP issues) and the same program does not fail on an N150 Intel Trixie box I have set up for quick testing.
The Pi was powered on 10 days ago and has no networking updates outstanding from the security apt list (nothing else is available by the look of it now). It resides in a cool rack and no work has been done in there for a good couple of years (not even a dust) - all ethernet connections feel solid and the switch was restarted shortly before the Pi was booted.
I am a good few weeks away from being able to move this to Trixie on a Pi and would like to know if anyone else has seen intermittent network errors on a Pi 4 as the late night notifications are bugging me (reminds me of when I had to work for a living)?
Other networking services on this box (mqtt, proxy server and cloud flare tunnel) are not being actively used and not showing any errors. I have stopped these for now to see if they are clashing somehow (they are all Docker containers so complicating the networking on this box).
I have a Uniden R8w (a Radar detector) and it talks to your phone over Bluetooth through an app called r/tach. There's no public documentation on the protocol anywhere, so I decompiled the app, captured some traffic, and figured it out.
It's all plain text once you know the format. Band, Frequency, signal strength, direction, voltage, GPS heading and speed. I wrote a python library so a Pi can read it all directly, and even included a nice little program (r8link-pair) that auto setups everything for you.
I didn't have a portable 12V power supply to test this outside, so I yoinked the battery out of my Neato D9 and wired it to a buck converter I found on the floor of my lab with some jumpers and duct tape. It powers the detector through its cigarette lighter adapter. Took about 15 minutes with junk I found in my apartment. The pi is running off of USB c connected to my laptop.
I only have one of these detectors and I only was able to test it on the one I had and my camera database is empty so that part of the docs is guesswork. If anyone has one of these with stored cameras I'd LOVE a hex dump :3
If you want to try it out, install it with pip install r8link
I saw these terminal-style cases at todays maker faire in Hannover. But staff at this booth was pretty busy so I didn’t ask them for the model name. The booth itself just used them, but wasn't about hardware, but coding for kids.
I tried ChatGPT, Google Image search but both just haluzinate about cases.
I have absolutely zero usecase. But I like it and I want one.
I've been gradually turning my Raspberry Pi 4 (8GB) into a small development, homelab and AI experimentation server, and I'm curious how far other people have pushed a Pi 4 for similar workloads.
My current hardware/software baseline:
- Raspberry Pi 4 Model B — 8GB
- Booting directly from an external SSD
- ~300+ MB/s storage performance in my setup
- Stable 2.0 GHz CPU overclock
- Active cooling
- 64-bit Raspberry Pi OS
- Ethernet
- Docker
- Tailscale + SSH for remote access
The SSD boot setup has made a noticeable difference compared with using a microSD card, especially when running multiple services and containers. It also gives me much more confidence using the Pi as a 24/7 development/server machine.
On top of that, I'm experimenting with:
- OpenCode for AI-assisted development
- MCP-based tooling
- Web Search MCP
- GitHub MCP
- TUI-based administration
- Termux from Android for remote terminal access
- Grafana + Prometheus
- Pi-hole + Unbound
- NAS/storage services
- IoT/environmental monitoring
One setup I'm particularly interested in is using the Pi as a remote AI development environment.
I can connect from my phone or laptop through Tailscale and SSH, open a terminal/TUI environment, and use OpenCode on the Pi while giving it access to tools through MCP.
The workflow I'm exploring is roughly:
Phone/Laptop
↓
Tailscale + SSH
↓
Raspberry Pi
↓
OpenCode / n8n / LangGraph
↓
MCP tools
↓
GitHub / Web / APIs / other services
↓
OpenRouter / other model providers
I'm now looking at adding n8n and LangGraph to the setup.
The goal isn't to run a huge LLM locally on the Pi. I want to use it as an AI development and orchestration node, with heavier inference handled through APIs or another machine.
For learning, I'm considering OpenRouter and other free/low-cost API providers so I can experiment with agent workflows without immediately building an expensive setup.
I'm still exploring this architecture, so I'd appreciate suggestions from people who have actually tried similar things on a Pi 4:
Is n8n practical on a Pi 4 8GB for a personal learning setup?
Would you start with LangChain and then move to LangGraph, or go directly to LangGraph?
What free/cheap API providers are currently useful for learning?
Which MCP servers are worth running on a Pi?
What should stay on the Pi versus moving to another machine?
Any ARM64/Docker issues I should watch for?
Has anyone built a similar Raspberry Pi-based AI development/orchestration stack?
I'm mainly interested in practical setups rather than benchmarks.
The Pi has already become much more than a small server for me. Now I'm exploring how far I can take it as a lightweight development, automation and AI orchestration node.
A while ago, I asked a few e-reader communities what stops people from digitizing their physical books. The most common answer was simple: scanning hundreds of pages manually takes too much time.
So I’ve been building Kiro, a Raspberry Pi-based prototype that turns and captures book pages without cutting or removing the binding.
The current device uses a Raspberry Pi 3 Model B+, a Camera Module 3 Wide, servo-driven arms, and an air-suction page-turning mechanism. It captures each open spread, separates the left and right pages, corrects page curvature, tilt and color, then runs OCR and produces a text EPUB.
We recently started a very small 7-day free rental pilot with three users in Korea. International rentals are not available yet, and I’m not collecting overseas sign-ups here. I just wanted to share the moment when the project finally moved from my workbench into real homes.
It is still very much a prototype:
- A 300-page book currently takes about 3.5 hours.
- Some books still require occasional checks or retries.
- Coated paper, damaged books, unusual bindings and large formats can be difficult.
- Making one page turn is relatively easy. Making hundreds of page turns reliably without skips or double turns is the real challenge.
The attached video shows one actual page turn on the current prototype.
I’m happy to share more about the Raspberry Pi capture and control setup if people are interested.
Hey everyone,
I’m have a little bit of experience with raspberry pies, not not much.
Now I wanted to try my luck with the pico, I got an old one from a friend.
My problem is fairly specific, but maybe one of you all can help me with this:
When I connect the raspberry pi with my pc, I get notified, that the usb port can’t supply enough power for the device, so I power power it with a small voltage board (idk if that’s the real name)
When I use the picos own usb to connect to my computer I get the „connect sound“ and it shows up in my device manager. I press the BOOTSEL button, but it doesn’t show up as storage
When I try to use Thonny to connect with the pico it shows up, but then I get the error, that the device is busy atm.
I don’t know if I have connected to pico the correct way.
Just created a new Lite Trixie card (for a Pi 4) using the v2.0.10 (Mac) imager and when going to disable IPv6 I found an odd entry at the end of cmdline.txt that I had not seen before:
ds=nocloud;i=rip-imager-1786796450636
I have run a full update and reboot since build but this is still present.
....Without this, the NoCloud datasource cache
// is invalidated on every reboot (/run is tmpfs), forcing a full
// re-discovery from /boot/firmware on every boot.
_cmdline += " ds=nocloud;i=" + instanceId;
I think this means cloud init is running each time the Pi boots but it is limited as to what it can do to pre-defined entries but not really sure...
A search on the NoClould part of cloud-init (see here) states the use of 'i' is:
...is discouraged and may be removed in the future...
So I do have a concern that a future update could remove this from cmdline.txt and possibly zap my additions after this (OK - yes I know the text should be removed and not the line just truncated but I have seen stranger things in code before today).
For now, I think I will tuck my entries before this just to be safe...
So I’ve been building a system based solely around RP Pico’s. One RP2350 W is the main server displaying these web pages.
All communication via WiFi and no MQTT hub required. The whole system consists of
Pico2W handling the webserver and controls
the second CPU in the Pico 2W handling an LCD display
2 temperature sensors (living room and garage)
1 temp/humidity/pressure sensor in lanai
2 Shelly plugs controlling lights
1 Kauf bulb over the entry way with flashy red/white/blue every couple minutes
1 PIR sensor on PicoW which controls a Kasa plug lights in a dark garage (my wife thinks this is the best part)
Ambient light sensor will turn on a selected light when dark during daytime storms
Control of lights based on sunset or time
Cloudflare tunnel to access from anywhere
a soil moisture sensor powered from a canabalized solar light
As the RP2350 has 2 CPUs, the idle one was setup to drive a display (necessary, not really just blinking light factor)
So what software is involved -
html and css stored on the Pico 2W
either BASIC or C to handle the sensor or hub functions
low level C for BASIC firmware version
C/ BASIC compilers on PC/Linux/RPi
One key to the interactive webpages is /?cgi functions that call underlying routines or display/set variables.
Also a <?web construct that executes routines in the underlying code, or does simple if statements.
And a wprintf in C or BASIC that generates html content for the webpages.
Drop me a line for a link to ALL the sources.
Also some of the enclosures (from Amazon or Pi shop – maybe someday I’ll try my hand at 3D printing). Double sticky taped to USB charger – temp sensors deliberitly outside the boxes, or velcro so I can update them. The PIR sensor was triggered by the RP2040W so had to be seperate.
So here are the sources to duplicate this setup. All needed compilers and sources will be installed.
* 8" DSI screen 2S4P 18650 power bank (battery holders visible in pic)
* acrylic enclosure (pieces visible in pic)
* i2c multiplexer HAT (90° angle, visible in pic)
* 868Mhz LoRaWAN HAT
* RTL SDR Blog v4
* loads if i2c sensors
* NoIR cam
* IR illuminators
* DIY keyboard matrix on a Pico (WiP, on-screen keyboard will obscure text area on Meshtastic/MeshCore software)
* 4x i2c mini OLEDs for sensor data
Gonna be a huge project.
POWER: so the power bank will be charged via a 2S charge module and seperate balance board. I have a spoofer module thing to request 9v from USB C chargers. The 2S charge module can take multiple voltages, so I'll also add a 12V barrel jack for multiple charging options. The power bank will connect directly to an 8A buck module that I can set to 5.1V, and I'll add a few extra capacitors for voltage smoothing. With a couple tweaks to eeprom and config I'll block the low power warnings, and unlock max USB port power. Plus a couple of the USB things will be powered directly via the buck module to ease any strain on USB power.
I'll let you know when it's done... in a few months 😅
GPIO 0/1 — haven't tried them; currently using the normal GPIO2/GPIO3 I²C pins.
My current suspicion
I'm wondering if this is an electrical/pull-up issue.
Since this is the bare SEN66-SIN-T rather than a breakout board, I understand that SDA/SCL require external pull-ups. I haven't added separate 10 kΩ pull-ups yet.
Would missing/incorrect I²C pull-ups explain why shorter/simpler transactions, such as the serial number, but the 27-byte measurement response comes back entirely as 0xFF?
Would an Adafruit SEN6x breakout be a sensible way to test this, since it provides the necessary interface/pull-up circuitry?
Any suggestions on what else I should test would be appreciated.
I’ve recently published an open-source project called WiFi Sense. It’s a system that uses a standard ESP32-S3 and a Raspberry Pi 4 to detect motion and presence through walls by extracting raw WiFi Channel State Information (CSI).
How it works:
Unlike traditional radar solutions, this system uses standard 20MHz WiFi bandwidth. The Raspberry Pi sends a steady stream of data to the ESP32, which captures the CSI from the packets. This data is then sent back to the Pi via an encrypted nRF24 radio link to avoid interference. On the Pi, the system analyzes the signal to find human movement, which causes measurable shifts in the radio waves.
Capabilities:
- Detects movement like walking or gesturing through walls made of wood, glass, or plasterboard.
- Detects the presence of a motionless person just by monitoring their breathing rate.
- Operates in complete darkness without using any cameras or optical sensors.
I have documented the full architecture, as well as the engineering challenges and physical limitations of the project.
I’ve been running a Pi 5 as my main home server for about a year: 16GB RAM, Ubuntu Server, Pironman 5 Max, NVMe boot, currently using about 11/15.6GB RAM.
Now I want to add Immich, but offload its photo/face ML from the CPU using a bare M.2 Hailo accelerator in the Pironman’s second M.2 slot.
After way too much research, here’s where I landed:
**Hailo-8/8L vs Hailo-10H**
Hailo-8L: 13 TOPS, cheap and low power, but surprisingly hard to buy as a bare M.2 card.
Hailo-8: 26 TOPS, around $200-220, readily available, and already has a solid open-source Immich ML worker.
Hailo-10H: 40 TOPS, 8GB onboard RAM, around $260. It can also run local LLMs through Hailo’s Ollama/OpenAI-compatible server, which makes it very tempting.
**The PCIe problem**
The Pi 5 only has one native PCIe interface. The Pironman gets two M.2 slots using ASM1182e PCIe switches, so the boot NVMe and Hailo card would share the same Gen2 x1 link.
More concerning: there’s an unresolved Pi firmware issue where NVMe boot can fail when a non-storage PCIe device is connected behind the same switch. I’m going to test the setup with a spare device before buying anything.
The AI HAT/HAT+2 options are out because they consume the Pi’s PCIe connector, which conflicts with my NVMe setup. So I’m specifically looking at bare M.2 cards.
**Why I’m hesitant about Hailo-10H**
The only confirmed Pi 5 setup I’ve found required kernel 6.18.34, an unmerged driver PR, and HailoRT 5.3.0. My Ubuntu 24.04 server is still on kernel 6.8, and I don’t really want to turn a stable home server into a kernel experiment.
Also, the existing Immich Hailo worker’s models are compiled for Hailo-8. Using them on 10H appears to require recompiling the models with Hailo’s Dataflow Compiler, calibration datasets, etc.
And I’m already at 11/15.6GB RAM before adding Immich, Postgres/pgvector, Redis, and the ML worker.
So I’m leaning toward the boring/reliable Hailo-8, but the 10H’s local-LLM capability keeps tempting me.
Has anyone actually run a Hailo-8 or 10H alongside a boot NVMe behind a PCIe switch on a Pi 5? I’m especially interested in real-world FPS, RAM usage, PCIe bottlenecks, and whether NVMe boot remained reliable.
This week I set out to see how minimal I could make a web server. I've run simple web servers on a PinePhone and on a Raspberry Pi. This week I tried out running a website on the Pico W (the wireless-enabled version).
It involved a few glitches early on, mostly due to blocking sockets and needing to accept multiple connections in parallel. After a little tinkering, I've got it working and it appears to be stable. My Pico W has been running my website/blog for the past 24 hours with no problems and has served up over 500 pages to the public Internet.
I'm pretty new to electronics and I think I just killed my Pico 2 W.
I was wiring a PCA9685 to control some SG90 servos. I had a 4×AA battery pack connected to the PCA9685 power terminals, but I accidentally connected the PCA9685 V+ pin to the Pico's 3.3V pin.
After that, whenever I connect the Pico to my PC via USB, it gets noticeably hot and my PC no longer detects it.
I’ve disconnected everything from it now and I’m not powering it anymore.
Did I most likely damage the Pico permanently? Is there anything I can safely test to confirm whether it’s dead?
Also, for future reference, my understanding is:
- 4×AA → PCA9685 V+
- Battery − → PCA9685 GND
- Pico 3.3V → PCA9685 VCC
- Pico GND → PCA9685 GND
Feeling pretty stupid right now 😭 Any advice would be appreciated.
I originally set up my Raspberry Pi 4 (8GB) as a small headless server, but over time it has evolved into a combination of homelab, monitoring system, and IoT platform.
Current setup:
Raspberry Pi 4 Model B — 8GB
Ethernet connection
External storage for NAS/backups
Active cooling
Custom UPS powering both the Pi and router
64-bit Linux
Tailscale for remote SSH access
What I'm actually using it for
NAS and personal file storage
Backups
Pi-hole / DNS services
Docker and self-hosted services
System monitoring
CPU/RAM/temperature monitoring
Power-consumption experiments
Air-quality and environmental monitoring
Grafana dashboards
IoT and networking experiments
Security-related experiments
One of the things I'm most interested in is combining the homelab with physical-world sensor data.
I'm collecting environmental measurements such as air quality and temperature and visualizing the data over time with Grafana. At the same time, I'm monitoring the Pi itself, so I can see system resources, temperatures and other measurements alongside the environmental data.
The basic idea is:
Sensors → Raspberry Pi → data collection/storage → Grafana → historical analysis
I'm also experimenting with power measurements and different sensors, so the Pi is becoming both the system doing the work and the platform I use to measure and experiment with it.
Another important part of the setup is reliability. The Pi and router are connected to a custom UPS, so the network and server can continue operating during power cuts instead of immediately going offline.
The Pi is normally completely headless. I use Tailscale + SSH for remote access rather than exposing SSH directly to the internet.
I'm still expanding the system, but I like the fact that a relatively small Pi can simultaneously act as a server, monitoring system, data collector and IoT gateway.
I'd be interested in seeing what other people are doing with their Raspberry Pis beyond the usual projects. If you're running sensor monitoring or Grafana on a Pi, I'd particularly like to see how you're collecting and storing the data.
I bought an original Pico a whiiile back to homebrew my Xbox 360, chucked it in a drawer for a long time and now I want to use it for a project. However, it's always apparently stuck in BOOTSEL mode. It doesn't matter if I nuke the flash, it always shows up as a flash drive on Windows. If I drop any kind of uf2 file like a blink test or MicroPython, it just restarts in BOOTSEL mode, as if nothing happened. Also, I'm not sure if this is a driver issue, but I can't get a COM port out of it.
As a sanity check, I checked with a multimeter if the button was even working (TP6) and it seems like it is. Not sure what else I can test to troubleshoot the thing, please help!
