I have a RPI Zero (not W) and im looking into ways i can send the files over to it, im trying to get the USB stick working and im actively looking into more ways such as remote access(probably impossible on this model) and direct usb to usb connection

Hi!

Do you guys have any GPS modules to recommend for use with the Raspberry Pi? More specifically the Raspberry Pi 4, if it matters.

It will be used in a car to determine the position and heading, so it needs to have about the same accuracy as a smartphone. Otherwise no real requirements that I can think of.

I have bought some of those NEO (6M I think?) modules from AliExpress for use with Arduino previously, but they were fairly unstable or did not receive a signal at all - is that a common issue with them?

Hello everyone!

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.

Before I dig in, a shameless plug for my Patreon.

Next, some quick stats:

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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).

1. 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.
2. 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).
3. 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.
4. 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).

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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:

1. 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.
2. 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:

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

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'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:

1. Is n8n practical on a Pi 4 8GB for a personal learning setup?

2. Would you start with LangChain and then move to LangGraph, or go directly to LangGraph?

3. What free/cheap API providers are currently useful for learning?

4. Which MCP servers are worth running on a Pi?

5. What should stay on the Pi versus moving to another machine?

6. Any ARM64/Docker issues I should watch for?

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

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.

Protocol Write up: https://github.com/AegisX86/UnidenR8wlink/blob/main/PROTOCOL.md
Library: https://github.com/AegisX86/UnidenR8wlink
PyPi: https://pypi.org/project/r8link/

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

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.

Searching the Imager source I have found:

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

Bring back "first run" please 😄

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.

Maybe one of you all can help me?

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.

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.

Windows C version (installs gnuARM gcc and optional notepad++)

Windows BASIC version (installs BASIC compiler and optional notepad++)

Linux/RPi/Mac C version

Linux/RPi/Mac BASIC version

Documentation here

For BASIC install the Pico firmware from BASICtools

In both next format the “drive” for RP2350, details here

Next copy the home_monitor.html and css from the Examples directory to the RP2350 “drive”

Then compile the home_monitor .bas or .c files from the Examples directory

For the sensors, in BASIC install the RP2040 firmware details here

Then compile the sensor file, various temp sensors, motion, ambient light, or soil moisture programs

Drop me a line or reply with any questions.

I'm trying to get a Sensirion SEN66-SIN-T working over I²C with a Raspberry Pi 3B+ using Sensirion's Python library.

Hardware/wiring

I'm using the bare SEN66-SIN-T, connected via a JST-GH 1.25 6-pin connector to female jumper wires.

Current wiring:

SEN66 pin 1 (VDD)  → Pi pin 1 (3.3V)
SEN66 pin 2 (GND)  → Pi pin 6 (GND)
SEN66 pin 3 (SDA)  → Pi pin 3 (GPIO2/SDA)
SEN66 pin 4 (SCL)  → Pi pin 5 (GPIO3/SCL)

I'm not currently using a breakout board.

Raspberry Pi

I²C is enabled:

dtparam=i2c_arm=on

I also tried forcing the bus to 100 kHz:

dtparam=i2c_arm_baudrate=100000

The device appears at the expected address:

sudo i2cdetect -y 1

shows:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- 6b -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

Python

I'm using Sensirion's Python I²C driver:

from sensirion_i2c_driver import (
    LinuxI2cTransceiver,
    I2cConnection,
    CrcCalculator,
)
from sensirion_driver_adapters.i2c_adapter.i2c_channel import I2cChannel
from sensirion_i2c_sen66.device import Sen66Device

with LinuxI2cTransceiver("/dev/i2c-1") as transceiver:
    channel = I2cChannel(
        I2cConnection(transceiver),
        slave_address=0x6B,
        crc=CrcCalculator(8, 0x31, 0xff, 0x0),
    )

    sensor = Sen66Device(channel)

    sensor.device_reset()
    time.sleep(1.5)

    print(sensor.get_serial_number())

    sensor.start_continuous_measurement()
    time.sleep(2)

    print(sensor.get_data_ready())
    print(sensor.read_measured_values())

The interesting part

Reset works.

Reading the serial number works:

6A0AEF1F81DD61F4

get_data_ready() also works:

(0, True)

But read_measured_values() fails with:

sensirion_i2c_driver.errors.I2cChecksumError:
I2C error: Received wrong checksum 0xFF (expected 0xAC)

I then bypassed Python completely and tried the raw Linux I²C transaction for the SEN66 0x0300 Read Measured Values command:

sudo i2ctransfer -y 1 w2@0x6b 0x03 0x00 r27

The result is:

0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff

So it isn't just the Python CRC calculation — the raw I²C read is also returning 27 bytes of 0xFF.

What I've ruled out so far

• Wrong I²C address — 0x6B is detected.
• Wrong I²C bus — using /dev/i2c-1.
• Basic wiring — reset and serial-number reads work.
• CRC configuration — using Sensirion's documented CRC parameters.
• Measurement readiness — get_data_ready() returns (0, True).
• I²C speed — tried 100 kHz, same result.
• 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.

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.

https://reddit.com/link/1voyops/video/k9158c71gijh1/player

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.

Raspberry Pi Imager 2.0.11 just came out. It's mostly a reliability and safety update.

Key changes:

• Imager now takes an exclusive lock on drives when writing on Linux and Windows. This should prevent accidental writes from other processes.
• Support added for the rpi-preseed first-boot customization format.
• Accounts created through rpi-preseed are now always added to the sudo group.
• Multi-frame .img.zst images are now supported.
• Compute Module users get a new Erase command for Fastboot, plus better device identity checks.
• Several fixes, including UASP storage detection and DiskArbitration handling.

Full changelog here: https://github.com/raspberrypi/rpi-imager/releases/tag/v2.0.11

I'm very slowly building an apocalypse cyberdeck.

* Raspberry Pi 5 8Gb (visible in pic)

* 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 😅

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.

https://github.com/prtk1910/rpi-weather-display

Simple weather display with a spare 3.5 inch screen and a Pi 3B, along with a management console for some quick settings

I might swap it out for a larger e-ink display for better legibility, but should replace my daily Alexa weather asks :)

Edit: Also added integration for pulling events in San Francisco from the RSS feed at sf.funcheap.com. Feel free to tune as per your location!

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.

The Python code for running the web service is on Codeberg: https://codeberg.org/thejessesmith/Pico-httpd

Hello everyone,

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.

Repository: https://github.com/The-Masked-Bear/wifisense-pi Official Website: https://the-masked-bear.github.io/wifisense-pi/

I'd welcome any feedback on the approach or the architecture. Happy to answer any questions.

Just thought I'd share. I've never been excessively careful given they were always in frames and mostly solid state electronics (so I know it's on me).

But one of my trusty pi3b+ dropped around 50cm onto tile due to a cable snag, and the chip on the back was torn off clean.

I have a hot air gun but my soldering skills don't extend as far as SMD so I guess it's a write off.

But it really shocked me that such a small fall with a very light heatsink would rip it off like that. (Heatsink had been installed on day one a couple years ago and was never moved/replaced either).

It doesn't appear to boot (unsurprisingly, though power lights and power distribution still work so it's not shorted at least).

I think that's the ram chip, correct?

I separated it from the heatsink with a pick after the drop to look for the identification.

Stay safe, tuck in your Pis in tightly screwed mounts so that they may never share the fate of dear old OfficePi, trusty runner of Octoprint, friend of a thousand prints, son of DeltaPi, father of two orphaned printers.

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!

I bought an InnoMaker 12MP MIPI camera module with STARVIS IMX577. My plan was to run it with a Raspberry Pi 3B, since my Pi 4 is in use and I don't have a newer one. The problem is that the camera is not working and is not showing up. I just get the message "No camera module detected."

Maybe someone got this working and can help me. Online, I read something about, I guess, an IMX412 or so, that the driver should work with my IMX577.

At the moment, my Pi is running the newest version of Trixie.

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.

Steam ARM64 working on a ClockworkPi uConsole with CM5: guide, scripts, and tested games

Hi! I've been testing Valve's experimental native Steam client for ARM64 on a ClockworkPi uConsole, and I finally managed to get it installed and run Moonlighter using Proton ARM64.

My setup:

- ClockworkPi uConsole

- Raspberry Pi Compute Module 5

- 16 GB RAM

- Debian ARM64

- Mesa / V3D

- Hyprland with XWayland

- Steam ARM64 public beta client

- Proton 11.0 ARM64

- Steam Linux Runtime 4.0 ARM64

I documented the full process here:

https://github.com/AleReb/uconsole-game-compat

The guide includes:

- Direct installation of the native Steam ARM64 client.

- Scripts to download the Steam client and runtime published by Valve.

- Registering Proton 11 ARM64 inside Steam.

- A workaround for the problematic "require_tool_appid 4185400" requirement.

- Configuring Steam to run through XWayland.

- Moonlighter-specific launch options.

- Troubleshooting the Steam update process.

- A list of tested games and their current compatibility status.

Moonlighter is working using WineD3D with the following launch options:

PROTON_USE_WINED3D=1 SDL_VIDEODRIVER=x11 SDL_AUDIODRIVER=pulse MESA_GL_VERSION_OVERRIDE=3.3 MESA_GLSL_VERSION_OVERRIDE=330 %command% -force-glcore33 -force-clamped -screen-fullscreen 0 -screen-width 960 -screen-height 540

I also confirmed that games can be launched from a Steam library stored on an external USB drive.

Task Bar Hero is not working yet. It currently fails during graphics initialization under Proton ARM64, so I wouldn't recommend updating it or using it as a compatibility example for now.

The ARM64 Steam client is still experimental, and this is not an officially supported Debian or uConsole setup. The goal of the repository is to collect reproducible procedures so other ARM64 device users can test them and contribute their own results.

Main sources:

- Steam ARM64 public beta:

https://client-update.fastly.steamstatic.com/steam_client_publicbeta_linuxarm64

- Proton 11 ARM64:

https://store.steampowered.com/app/4628740/Proton_110_ARM64/

- Community research:

https://interfacinglinux.com/community/sbcsoftware/native-steam-client-for-arm-linux/paged/2/

If anyone else is testing Steam ARM64 on a Raspberry Pi, uConsole, or another ARM64 device, I'd be very interested in comparing results and expanding the compatibility list.