Supported media & health data

Because wear data comes from the card’s controller, not from the flash or the marketing. Some controllers publish their counters through a vendor command; many retail controllers publish nothing, or answer with an empty block. An endurance label tells you what the maker rates the flash for; it does not put a health interface on the card. ASTRID reports what the controller can prove and says plainly when that is only identity, capacity and behaviour.

Confirmed: the figure was validated on real cards against the maker’s own tooling or specification. Observed: the reading is coherent and passes our plausibility checks but the maker has not yet confirmed it. Behaviour: identity, verified capacity and a read test only, with no vendor figure shown. Documented: the maker publishes the interface and ASTRID implements it, but no card of theirs has yet been through our bench.

It can be flagged, and we designed for it. Some retail cards ship with an unprogrammed maker ID, which is also a tell some counterfeits carry. ASTRID resolves that by recognising the part from its other identity fields and by verifying the capacity on the silicon. A known part with a blank maker ID is graded on behaviour; an unknown card with one, or any card whose real capacity does not match its claim, fails.

No. Identity, health and the read test are read-only. The two things that write are opt-in and clearly labelled: the capacity test writes small markers at test points to prove the space exists, and erasure writes or hardware-erases the whole card and then reads it back to verify.

Vendor health commands travel on the SD bus itself. A USB reader converts the card into a generic disk and drops those commands on the floor. ASTRID and our line hosts talk to cards natively, which is why they can read what a reader cannot.

A permanent record for one card: its identity, every health reading we have taken, and every job it has been through. The QR label on a processed card opens the card’s own passport without naming anyone. Signed-in customers see the full record for cards they own in the portal.

Yes. CompactFlash, CFast, SATA drives and DOMs use the industry-standard SMART interface. eMMC on Compute Modules and embedded boards reports its life through JEDEC-standard registers, read on the host device by ASTRID or a POD. USB flash drives have no health interface and are graded on behaviour.

ASTRID grades any card on measured behaviour and reports it honestly as unrecognised, then queues its identity for us to validate. Send us the part you rely on and we will tell you what can be read from it, add it to the knowledge base every ASTRID receives, and put it on this page at the confidence level it earns.

A grade is a statement about remaining life, so it depends on the card making that data available. Where the controller publishes its wear counters and the maker has confirmed how to read them, the card is graded A to D on measured life. Where a route is observed but not yet confirmed, ASTRID reports what it read without a percentage or a grade. Where the controller publishes nothing, the card gets its identity, capacity and behaviour checked and the certificate says so; we do not invent a wear figure from a brand name or a label. The tiers on this page tell you in advance which of those your card will get.

We go to the maker. Most controllers expose their wear counters through a vendor command (CMD56 on SD cards) whose format the manufacturer holds, and we ask for it, under NDA where they prefer. ATP, Delkin, Kingston and Swissbit have supplied specifications or samples this way, and the confidence tiers above are the result. If you rely on a card we cannot read yet, tell us who makes it: a customer asking is often what opens the door.