How PAM Finds Evaluates Hardware

Every spec on this site comes from a manufacturer datasheet or official product page. We do not estimate, interpolate, or accept vendor-supplied marketing numbers at face value. This page explains exactly how we source data, structure comparisons, and keep reviews current.

Where We Get Our Specs

For each product, we locate and read the primary manufacturer documents in this order:

  1. Official datasheet (PDF) — The chip or module datasheet published by the silicon vendor (Espressif, Nordic, NXP, Broadcom, etc.). This is the authoritative source for CPU architecture, clock speeds, memory sizes, peripheral counts, and electrical characteristics. We link to every datasheet we reference in the "Sources & verification" section at the bottom of each review.
  2. Development kit user guide — The board-level documentation that describes pin breakouts, onboard peripherals (OLED, LoRa radio, battery charger), and physical dimensions. This comes from the board manufacturer (which may differ from the chip vendor).
  3. Technical reference manual — For deep-dive specs like ADC resolution, DMA channels, or sleep mode current consumption, we reference the TRM when the datasheet summary is insufficient.
  4. Official product page — Used to confirm pricing (MSRP), availability, and any features added at the board level beyond the base chip capabilities.

We do not source specs from Amazon listings, third-party review sites, or forum posts. If a spec cannot be confirmed in an official document, we do not list it.

How We Normalize Specs

Different manufacturers describe the same capability differently. We normalize every spec into a consistent format so boards can be compared directly:

How We Write Reviews

Every review follows the same structure, enforced by our content pipeline:

  1. Summary (40-60 words) — What makes this board distinctive, stated upfront
  2. Verdict — One-line buy/skip recommendation with the specific use case
  3. Pros and cons — Each tied to a specific spec, not vague claims ("fast" is not a pro; "240MHz dual-core Xtensa LX7" is)
  4. Analysis sections — Deep dives with one concrete data point every 150-200 words
  5. Who should buy — Decision framework with buy/consider/skip recommendations per use case, including alternative product suggestions
  6. FAQ — 5-7 questions based on real user queries, not filler

Reviews are generated from structured JSON schemas validated by Pydantic models. This means every review has exactly the same fields, minimum content thresholds, and data quality gates. A review cannot be published without a minimum of 3 pros, 2 cons, 5 FAQs, and a 100-word AI citation summary.

How We Build Comparisons

Comparisons are structured around 4-7 measurable axes (Processing Power, Wireless Range, Power Efficiency, etc.) with a winner declared on each axis based on datasheet specs. We then map the winners to real use cases so readers know which board to buy for their specific project — not just which board "wins" on paper.

We focus on cross-ecosystem comparisons (e.g., ESP32 vs Raspberry Pi Pico, Jetson vs Coral) because these are the decisions makers actually face. Same-family comparisons (C3 vs C6) are included when the chips target overlapping use cases.

Automated Validation

Before any content is deployed, our pipeline runs 51 automated tests covering:

A page-level audit scores every page 0-10 across these dimensions. Pages below 9.0 are flagged for review before deploy.

How We Keep Content Current

Product specs do not change after launch — an ESP32-S3 will always have dual-core Xtensa LX7 at 240MHz. What changes is the ecosystem: new software support (ESPHome, Matter), new competitor boards, and price shifts. We update reviews when:

Every page shows its publish date. Our sitemap uses per-page last-modified dates from our version control history so search engines know exactly which pages have been updated.

What We Explicitly Avoid

AI in Our Workflow

We use AI tools (Claude) to help structure and draft review content from our spec data. Every AI-generated claim is validated against the source datasheet before publication. The structured content pipeline enforces this — content is typed JSON, not freeform text, so every spec reference can be traced back to a source document.

Our llms.txt file and public API are designed for AI agents to consume and cite accurately. We believe in making data accessible to both humans and machines.