Schools don't want to be debugging microSD and USB issues.

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.

Rubbish. They do. My daughter's school has a pile of knackered Pi's that the teachers don't have the time and budget to fix.

Broken connectors, duff microSDs, bricks.

They don't use them now, preferring python on windows.

> duff microSDs

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.

I did mention "similar usage profiles"

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.

Tell them to give them to me. I'll pay for S&H

Probably as the pi was designed for 6th formers to use - letting 8-10 year olds lose on them :-)

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.

These are classic symptoms of underpowered PIs. 99% of USB power supplies are not fit for a PI :(

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?

Yeah see my original comment about USB power problems :)

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.

Correct me if I’m mistaken, but isn’t eMMC literally just an embedded SD card?

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.

It is, and it is better because it probably has better chips, but it will die, and brick RPi in the future.

School computers take a beating. That's why the two are incompatible.

That's one of the reasons the Apple II was so popular with schools.

It was built like a tank.

The Bell & Howell version came in Darth Vader black too: http://www.digibarn.com/collections/systems/appleII-bell-and...

Interesting it was painted and not a differently colored plastic.

SD cards with wear leveling and error correction are hard to find and can easily be more expensive than similar SSDs.

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:

- https://electronics.stackexchange.com/questions/27619/is-it-... - https://www.reddit.com/r/raspberry_pi/comments/ex7dvo/quick_...

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.

With USB sticks it's a different story. There are some manufacturers like Sandisk who claim they use wear leveling in all of their current USB sticks.

microSD is a mess in this regard. Wear leveling is less common there and only present in very specific and expensive niche models.

[citation needed]. I can’t believe any but the cheapest no-name SD cards would have absolutely no form of wear leveling.

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.

[1]https://www.amazon.com/SanDisk-Industrial-MicroSD-UHS-I-SDSD...

Too many kids, that's the problem with schools these days.

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 are not running 24/7 servers from them.

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.

Schools are, however, probably power-cycling the Pi daily, and power-cycling can be just as detrimental to an SD card.

There is a sticky thread in the forums and such threads are always just the tip of the iceberg: https://www.raspberrypi.org/forums/viewtopic.php?t=245931

My guess: The VL805 USB 3.0 UAS is broken.

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.

Is your use-case not perfect for the network boot feature?

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.

> Complaints like yours are relatively rare.

I've stopped complaining because I already know how the issue manifests and how to solve it.

A SD-card is not a proper replacement for a drive, it's a fine storage medium.

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.

Modern day CF replacement is CFexpress. PCIe 3.0 x1 NVMe, forward compatible with XQD.

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.

How do you know that complaints about the storage system are rare?

you're right, they want to not debug anything at all, they want to have a drawer full of microSD cards with the OS pre-installed. When a kid says "I have a problem" you say "ok here's a fresh install" and swap the SD card.

The RPi4 SoC already has PCIe support; it's used for the USB controller, but it wouldn't be impossible to have a version that has an M.2 PCIe slot. It could be used for NVMe, WWAN or faster Ethernet.

USB could remain available through USB OTG and it would sit in the middle between the RPi4 and the Compute Module 4. Using the USB power socket for OTG is doable already on the Pi4, but to do it in a fully supported way would need some extra components to properly handle USB-C configuration. Still cheaper than an H2plus

It's enabled in the Pi 4 compute module; the carrier board has a PCIe slot.

If would make sense to be able to attach a $25 32GB SSD to the bottom of a RPI. Then add some kind of a U-shaped connector to connect the RPI to the SSD and a place for the screws, so that they are fixed back to back.

If only there were some kind of bus that were universally available so we wouldn't need such an awful, hacky solution. Something capable of transferring all that data serially.

I was going to say the same thing. The RPi was introduced at a time when cheap SATA SSDs weren't a thing, nor were beefy ARM CPUs. It's starting to feel like an Edward Scissorhands situation.

This is misleading. You have removed the first part of that sentence "Early on, the Raspberry Pi project leaned towards..."

Whilst education is still important, particularly on the charity side, these days the RPi Trading division explicitly targets multiple markets, for instance, the compute boards specifically targeted at industrial usage. This product is described in their own press release as targeting the christmas toy market amongst others.

Or you know there's this thing called eMMC that's mostly pin compatible with SD cards and yet provide fast, resilient and cheap storage.

I had devices with eMMC and can't remember any of them being "fast" and "reliable".

Fast and reliable can be relative, but most SBC systems with emmc get 2-3x the IO performance of an SD card.

I believe the reason they are “eMMC” than “eSD” is because they can’t be certified for SD specs.

MMC and TransFlash at this point is a synonym for SD Card when someone cannot refer to them for license/certification reasons.

> There are alternatives to RPi

The alternatives to RPi don't have nearly as rich selection of polished software, vibrant community and ecosystem as Raspberry Pi has. The best parts (besides hacker-orientedness) of RPi are its uniformness and popularity.

Also, the CM4 does work with native NVMe or SATA storage (at the expense of USB 3.0 ports).

What percentage of raspberry pis do you think actually go to that "target audience"? 20%?

eMMC storage are comparatively very fast, and I believe they have a comparatively little or negligible impact on the end price (competitors like Hardkernel put it in the directly competing products).

The RPI compute modules already use eMMC flash. RPi Compute Module 1 was released in 2014 and uses eMMc flash.