How to Choose a TF / microSD Card for IoT and Data-Logging Devices

TL;DR

For IoT sensors and data loggers, the card is doing small, frequent, append-style writes over years — not recording video. Size capacity from your logging rate × retention, not from a shelf number. For most logging, an SDHC card (≤ 32 GB, FAT32) is the correct ceiling, not the biggest card you can buy. Confirm your MCU reaches the card over SDIO/SD bus or SPI, and put your endurance target (TBW) and operating-temperature range in the RFQ.

The failure mode here is different from a dashcam: a card that benchmarks perfectly on day one can wear out in eight months if the write volume was underestimated. The question is total bytes written over time, not peak speed.

---

1. What “data logging” actually asks of a card

A logger and a video recorder stress flash in opposite ways:

• Video (dashcam, surveillance) writes a high, fairly constant bandwidth — the card must sustain a minimum write speed or it drops frames.
• Logging writes a low bandwidth but a high cycle count over the product’s life — thousands of tiny appends, often with periodic full-file rotation.

Endurance for logging is therefore about total bytes written across years (TBW), not about a speed class. The trap is that a card which passes a day-one reader benchmark tells you nothing about whether it survives your actual write pattern for the warranty period.

This is also why the classic “buy the biggest card” instinct backfires for logging: extra capacity you never fill mostly buys endurance headroom, not storage you need.

---

2. Capacity: size from the workload, not the shelf

Start from what the device actually writes:

daily_bytes      = records_per_day × avg_bytes_per_record
required_capacity ≈ daily_bytes × retention_days × safety_margin   (use 1.2–1.5×)

Account for filesystem overhead and the spare area flash controllers keep for wear leveling; the safety margin covers both.

Worked example (illustrative, not a WINTEL order): a sensor logging 1,200 records/day at ~256 bytes each writes about 307 KB/day. Over 365 days with a 1.4× margin that is roughly 157 MB — a modest 4–8 GB card is plenty. Stepping up to 16–32 GB mainly buys endurance headroom (more spare cells to spread writes across), not capacity you will fill. Contrast this with a dashcam, where bitrate dominates and 32–256 GB is the normal range.

Two design patterns change the math:

• Ring / loop buffering — old data is overwritten, so required capacity stays near “one retention window” and never grows.
• Archival logging — data is kept and offloaded later, so capacity scales with total lifetime writes.

If you are not sure of the rate yet, record a prototype unit for a week at the real cadence and divide total bytes written by the days. That measured number beats any estimate.

---

3. SDHC vs SDXC: which ceiling for logging?

Per the SD Association, the capacity families map to file systems as follows:

Family	Capacity	Default file system
SD (SDSC)	up to 2 GB	FAT12 / FAT16
SDHC	over 2 GB – 32 GB	FAT32
SDXC	over 32 GB – 2 TB	exFAT
SDUC	over 2 TB – 128 TB	exFAT

For logging, SDHC (≤ 32 GB, FAT32) is usually the right answer, because:

• Log files are small and you rotate them, so FAT32’s limits are rarely a problem. Microsoft documents FAT32 at a 32 GB maximum volume and a 4 GB maximum file size — both comfortably above a logger’s needs.
• SDXC/exFAT only earns its place if you need more than 32 GB on one volume or a single file larger than 4 GB (common for video, rare for logs).
• Many embedded MCU SD stacks and older readers are SDHC-class. An SDXC card may simply not mount on an SDHC-only host. Match the card family to what your firmware actually supports, not to the largest card the slot physically accepts.

---

4. Interface: SDIO/SD bus vs SPI

SD cards support an SD bus (1-bit or 4-bit data) and an SPI mode. The SD Physical Layer Specification describes SPI mode as being “designed to communicate with a SPI channel, commonly found in various microcontrollers” — it uses four signals (CS, CLK, DI, DO) and lets you wire the card to almost any MCU’s SPI peripheral, or even bit-bang it on four GPIOs. The trade-off is throughput: SPI mode gives up the wide-bus option of the SD bus.

Practical checks before you commit:

• Confirm the mode your firmware uses. Most cards support both, but verify on the target MCU — a PC reader only proves the card works in SD bus mode.
• Voltage. The SD spec defines VCC as 2.7–3.6 V. A 5 V MCU needs a level shifter on the signal lines; modern 3.3 V MCUs can usually connect directly.
• Peak current. Writes can draw meaningful current briefly; size the local regulator and bulk capacitance at the socket so the card does not brown out mid-write.

---

5. Filesystem: FAT32, exFAT, or an embedded FS

On a device running Linux or a capable RTOS with an SD driver, you have options:

• FAT32 — universally readable, but capped at 32 GB volume / 4 GB file (Microsoft). Fine for rotated logs on an SDHC card.
• exFAT — required for volumes over 32 GB or files over 4 GB; SDXC ships formatted exFAT. Note that exFAT is Microsoft intellectual property and adopted by the SDXC/SDUC standards; older Linux kernels (before 5.4) lack native support, so confirm your OS handles it.
• A flash-friendly embedded filesystem (for example littlefs) can handle power-loss and wear better than FAT-family formats, at the cost of PC readability.

One thing FAT and exFAT do not give you: crash safety. An interrupted write can corrupt the file allocation table. For critical logs, either write append-only with per-record checksums, or use a filesystem designed for power-loss. WINTEL can preformat and preload a card to your filesystem on request — state that requirement in the RFQ rather than assuming a default.

---

6. Endurance: the number that predicts field life

The industry frames endurance with terms standardised in JEDEC JESD218:

• P/E cycle — one program/erase cycle of a flash block.
• TBW (terabytes written) — total bytes the device can write over its rated life.
• Write amplification — NAND bytes written ÷ host bytes written; small, frequent updates can multiply internal writes.
• Wear leveling — spreading those cycles across all cells so no block wears out early.

A rough life estimate:

life_years ≈ rated_TBW ÷ (bytes_written_per_day × 365)

Illustrative only (not WINTEL data): a 16 GB card rated, say, ~100 TBW at a logging rate of 300 KB/day would last far longer than the device itself; at 1 GB/day it still runs for years. The point is to match TBW to your write rate and not assume a consumer card’s endurance covers an always-on logger.

Two cautions:

• There is no universal P/E count — it depends on NAND type and workload, so a vendor’s TBW is a rating under a defined workload, not a guarantee for your access pattern.
• Speed class (the U1/U3/V30 marks) tells you sustained write speed, not endurance. A fast card is not automatically a long-lived one.

---

7. Environment and power

Consumer cards are typically rated for 0–70 °C. If your device runs outside that — outdoor sensors, automotive, industrial enclosures — state the operating-temperature range in the RFQ rather than assuming the card covers it.

Power matters too: an unexpected loss during a write can corrupt the FAT or metadata. Design for a graceful shutdown, or journal the data so a partial write is recoverable. These are firmware and hardware decisions first; the card choice supports them, it does not replace them.

---

8. Qualify the sample on the real device

A PC reader benchmark is not a field test. Before you approve production:

1. Run your actual logging firmware on the target MCU for a meaningful duration.
2. Verify the real capacity is present (not just the labelled number).
3. Exercise your real write pattern — periodic appends, not a sequential copy — and confirm it sustains without errors.
4. Cycle power repeatedly to check the filesystem survives interruption.
5. Record the controller, NAND configuration and batch so repeat orders can be matched.

Use a structured checklist rather than an ad-hoc pass; the sample acceptance checklist and the capacity verification guide cover what to record.

---

9. What to put in the RFQ

Give WINTEL the minimum needed to build the right sample — you do not need every parameter on day one, but the more specific you are, the less iteration:

• Interface mode: SPI or SDIO (1-bit / 4-bit)
• Capacity and filesystem (FAT32 / exFAT / other)
• Endurance target: daily write volume × expected years, or a TBW figure
• Operating-temperature range
• Write pattern: periodic logging vs continuous stream
• Logo, preload and packaging requirements
• Quantity and target delivery date

WINTEL supplies TF cards from 4 GB to 256 GB using A+ grade NAND, and for an OEM device we match capacity, controller (Alcor / ITE / Xinbang / Micov), NAND grade, filesystem preload, logo and packaging to your specification. MOQ and lead time are confirmed against the project, not quoted as a flat number.

---

Next steps

• Estimate your capacity with the TF card capacity estimator.
• Compare card families in SDHC vs SDXC and FAT32 vs exFAT.
• Build a complete enquiry with the TF card RFQ checklist, then request a quote.
• For continuous video instead of logging, see the dashcam selection guide.