Except these problems don't occur for most people, as evidenced by the fact that the current system works fine. Complaints like yours are relatively rare.
Do you mean the microSD cards tend to wear out, or that they’re DOA?
If the former — I’m pretty sure there’s an option to load RaspberryOS into a RAM-resident mode (like a live CD) where regular OS usage won’t hit the disk at all, and only a “Local Documents” partition is mounted writable, with nothing configured to implicitly write to it by default.
If the latter — trust me, the same is true of eMMC, or any other Flash media ordered in bulk quantities. You just have to QA them on arrival. Set up an RMAed-parts box with a shipping label in advance; you’ll need it.
> broken connectors
The microSD connector? In an educational context, that shouldn’t be end-user exposed. It’s essentially a maintenance port. Stick some tape over it.
In the computer labs of the 90s, kids would break the CD-ROM drive trays, too. MDM software was developed that would, among other things, lock out the CD-tray eject mechanism unless/until a teacher enabled it (presumably for working through some whole-class “multimedia” product that never materialized, because who’d trust kids to insert the CDs?)
> If the latter — trust me, the same is true of eMMC, or any other Flash media ordered in bulk quantities. You just have to QA them on arrival. Set up an RMAed-parts box with a shipping label in advance; you’ll need it.
SD cards and USB flash drives are manufactured with lower-grade flash memory than SATA and NVMe SSDs. The stuff that wears out in RPi usage is the stuff that was rejected for desktop usage. So having a large failure rate is not the only option, if you can expose a SATA or PCIe port. It's a little disappointing that they cannot even offer end users that upgrade path.
I'm sure your experiences are legitimate, just like mine for similar usage profiles are. My only conclusion can be that it's not the hardware itself that's the problem, unless we allow for the possibility that it's different batching. Unlikely, but not unthinkable.
But we've already established that these are meant for "the promotion of teaching basic computer science in schools and in developing countries". In these situations with young, untrained hands, durability and robustness are absolutely key criteria. It's not good value if it ends up discarded/broken due to additional complexity or a fault.
Or maybe you're using Pis in ways that aren't so hard on SD cards, etc? It seems very likely that this is the case given that these users experience these issues on Pis but not other systems.
No all GCSE so 14+ students. The issue is usually that they freeze or crash under "desktop use" all the time and people pull the power out and back in again to reset them. This flexes the HDMI and USB connectors which eventually break or the cables give out. During the reboot cycle is when the SD card gets borked, or randomly suddenly.
It's really a terrible computing experience compared to using a simple off the shelf windows box running python with full single-sign-on to GCPW. They don't crash and the cables are never yanked around because they are AIO boxes and the storage never goes wonky. Teachers prefer them because the first 30 minutes of a 80 minute slot isn't getting 30 raspberry pi's limping again.
So that raises the question: Why do they keep making Pis with USB power? One could argue that it's because USB power supplies are cheap and ubiquitous, but that's not really true if only 1% of power supplies are actually capable of properly powering a Pi.
They could use a different power connector that doesn't cause this confusion, or they could design Pis to use less power and therefore work properly with more USB power supplies.
MacBooks Pros are “USB powered”, too, but you need a 65W USB-C charger to get them past “Not Charging”.
A USB connector, at this point, is a PHY (like a serial DB-9 connector), not an inter-ecosystem compatibility promise (like a FireWire or SCSI port.) Lots of things use USB for lots of different incompatible use-cases. They just happen to share a connector.
But on the other hand, you can also think of it like a regular PSU: all motherboards connect to all PSUs, and there’s no way for a PSU and motherboard to communicate to “lock out” a mismatch. And a PSU will seem to work for a given configuration of motherboard+CPU+peripherals, until you drive that configuration hard enough to overdrive the PSU, and it shuts off.
The solution in both cases is the same: you overbuy on PSUs. A good high-wattage-rated power supply (whether a USB one or a desktop molex one) will power anything below that wattage requirement just fine. USB PSUs do negotiate power draw with the client device, so you can run a Pi off a big-brick laptop-class USB charger without damaging it.
And that’s mostly why Raspberry uses USB power, I think: if you already have a big beefy USB PSU from something else (as most early-market adopters do), you can use it to power your Pi for playing around, without having to buy the Pi its own PSU, if you’re not sure you want/need to set it up for its own standalone use-case.
(Also, the Pi will run just fine on a wimpy 5V1A iPhone charger if you don’t tax it very hard. Just like a cheap desktop PSU will power a gaming rig with a beefy GPU, if you never open a game. And most embedded use cases, e.g. PiHole, don’t tax the Pi very hard. So there’s a lot of cases where people get along just fine with the cheapest possible configuration, where forcing them to buy an actual power adapter would make things a lot more expensive for no gain.)
> or they could design Pis to use less power
You know that they stop selling old-model Pi’s, right? It’s not because they want to. It’s because those chips stop being manufactured upstream; and Raspberry doesn’t do enough volume to drive production of SoCs all on their own.
Raspberry is constrained by what parts they can put in a Pi that are both available and sufficient for the use-cases their customers have (e.g. driving monitors at native resolution.) Those chips have minimum power requirements. The power requirements never go down, because there’s no high-volume customer with exactly Raspberry’s use-case (where that use-case is “using process-shrinks to build a graphical desktop SoC of the same performance at ever-lower current draw, rather than achieving ever-higher performance at the same current draw.” An SoC process-shrink that is taken as-is with no commensurate re-layout for increased perf, is extremely rare in the industry. Not rare in microcontrollers, but an MCU can’t drive a desktop computer.)
You might suggest they undervolt the newer chips — and they do! — but there’s only so far you can undervolt a chip before it just stops functioning at all. (Especially an SoC, that contains DRAM that must get refreshed, IO controllers that must drive peripheral lines with to-spec line voltage, etc.)
> specially an SoC, that contains DRAM that must get refreshed, IO controllers that must drive peripheral lines with to-spec line voltage, etc.
I'm just nitpicking your otherwise great post here but wouldn't the IO voltages be entirely separate from the core voltage? Or do they all need to be kept within a certain range of each other?
Maybe you should do what our CCNA instructor did - if you brick one of the routers you have to fix it yourself.
Is it such a terrible "learning" Experience that yanking the power cable out is a bad idea as others have said the pi's should have better power supplies.
sounds like people simply weren't taking any care of them, that's why they broke. If they had cases and decent sd cards that probably wouldn't have happened.
I’m responsible for a fleet of a few hundred Raspberry Pis being used as home monitoring hubs - they use high grade SD cards, and are configured to write as little as possible while still fulfilling their function, yet we still see one or two a month fall of the internet because of SD card corruption. This is absolutely a problem.
I believe the compute module is somewhat better in that it uses eMMC rather than SD cards.
Same interface as an SD card, but better firmware and probably higher quality flash. SD cards are really aggressively cost-cut, often coming in than less than the price of raw flash of the same capacity.
As someone who has also worked with fleets of devices (R.Pi-based and others) working off SD-cards, I can confirm what jon-wood is saying. For some reason SD cards fail at a much higher rate than eMMC flash chips in traditional SMT packages.
I was under the impression most non-awful SD cards had some sort of wear-leveling these days but there's no standard for it so they don't advertise it on the front like SSDs. I couldn't really find any proof either-way about this, just a few instances of people looking into it:
I think every microSD and USB sticks by now has WL across the board, especially at awful grade. WL and ECC are must at current [price, BER, capacity, bit-per-cell] or something.
It does look like there are many of cards that don't claim any sort of wear leveling (doesn't mean they don't do it at all but they don't call it out). This is surprising to me, but if you want to make sure you get a card with wear leveling, look for it in the specs. These SanDisk industrial cards[1] are ones I've used in the past that specifically claim they do wear leveling in the spec sheet:
Advanced memory management FW features power immunity, auto/manual read refresh, ECC, wear leveling.
They're also only a few bucks more than a "normal" microSD card.
I think you’re confusing your lack of knowledge of the commonality of this with the assumption that it is rare. I don’t know anyone who expects a Pi with SD to last more than a year. And the “solution” is always to buy the more expensive SD cards that last longer. And that’s not a solution. It’s time for Raspberry to give up the SD card for a real form factor. I can get a 120gb nvme that’ll likely never fail in my lifetime of Pi usage, or carry two mirrored SD cards for the inevitable failure that’ll happen when I can’t re-image a machine (like in flight - https://stratux.me)
I've had all RPi versions except RPi4, running at least 1 of them 24/7 since the first one was released, and by the first year I had a cron that dd'd the card every night, and I found myself dding the backup image at least 2-3 times per year.
RPi3+ has had no problem so far, and I'm not upgrading to RPi4 out of fear of it becoming an unstable mess again.
I did run Boinc on over 20 different SBCs for 2 or 3 years. So they run 24/7 with 100% and I just had 2 broken SD cards from all those SBCs. I guess thats fine.
Schools may have a lab with 30, used 2h per day, makes it more than double my failure rate. Add kids popping the cards in and out all the time and you have a recipe for disaster.
I think that's because "most people" who buy a Raspberry PI use it once or twice then it lies in a drawer somewhere. In my experience, if you actively use it for something, you'll get into annoying problems like that, it's just a matter of time and how much you are hitting that SD card, or how many times you unplug it without shutting down the Pi properly.
I've had my Pi 3 running constantly for the last three years as a Plex server. The only thing that has gone wrong is the Western Digital hard disk drive that failed. The Pi itself and even the microSD card have been fine.
This spring, I deployed 20 PI's at work for a project and they are used every day, many many times a day. I've had 2 corrupt SD card failures so far. It's hard to know for certain what the cause is. We have spare SD cards to swap in for this application. For my application, having a spare SD image isn't a problem and I don't need five 9's of uptime, but the SD cards seem to be a point of fragility. Ultimately we're very happy with the system, but the SD cards are a point of failure that just need to be mitigated.
Many are remote and rural. Internet and network is frequently iffy. Has to work completely offline for hours at a time as needed, including after a power cycle.
As far as I am concerned, I consider SD cards the equivalent of a floppy disk. The equivalent of a hard drive would then be a CF card (unfortunately much less common than SD cards these days). Or of course any USB drive if we give up on the card format/connection style.
Yeah but RPi SoC is apparently lacking in PCIe lanes. I think they need a different SoC so they can finally have ethernet/storage/usb controller on the PCIe bus.
