Thermal Feasibility Checker — methodology

Contents

1. What it decides, and what it does not
2. Inputs
3. The four checks
4. Verdict rule
5. Cooling classes, enclosure classes and margins
6. Vendor limit table and sources
7. Alternatives and remediation
8. Evidence classes and confidence
9. What invalidates a result
10. Method changelog

1. What it decides, and what it does not

The checker answers one design-review question: for this module, at this power, in this enclosure class, with this cooling class, at the hottest ambient the site sees — is the thermal design worth building? It returns FEASIBLE, MARGINAL, NOT FEASIBLE, REQUIRES VALIDATION or UNKNOWN.

It does not predict a junction temperature, a throttle onset or a time-to-throttle. Those depend on the actual heatsink, thermal interface, airflow path and workload, none of which a form can capture. The roadmap decision behind this engine is that a categorical answer from the vendor's own limits is honest; a predicted temperature from a form is not.

2. Inputs

Enclosure air = ambient + the enclosure class's internal rise + solar rise. A thermal-transfer-plate rating is a plate temperature the cooling has to hold, so the TTP range is checked against the site ambient; ambient and module ratings are checked against the enclosure air.

3. The four checks

Cooling capacity, the only arithmetic

required °C/W = (limit − margin − enclosure air) / power, where the limit is the maximum TTP temperature for modules with a thermal transfer plate (AGX Orin, Thor) and the SoC operating limit for modules without one (Orin NX / Nano, Raspberry Pi 5) — the vendor's number, quoted in the dataset — and the margin is 5 °C for a TTP limit (the vendor already specifies it with margin) or 10 °C for a SoC junction limit.

deliverable °C/W = band / (airflow factor × air density), where the band is the cooling class's engineering thermal resistance, the airflow factor is the enclosure class's, and air density follows altitude (1.00 at sea level, 0.78 at 2000 m). The module's own junction-to-plate resistance is inside the vendor limit and is not added again.

FAIL when deliverable ≥ required (or required ≤ 0). NEAR LIMIT when deliverable is at least 80 % of required, or when the estimated surface temperature (enclosure air + power × deliverable) is within the 5 °C marginal band of the target. PASS otherwise. UNKNOWN when the module has no published limit or no power is known. A bare module (none) FAILs above idle power.

4. Verdict rule

• UNKNOWN — the module has neither a TTP / SoC limit nor an operating range on record.
• NOT FEASIBLE — any check FAILs.
• REQUIRES VALIDATION — no FAIL, but a check is UNKNOWN because the vendor does not state the limit (for example Hailo-8 has an operating range but no plate or junction limit, so the cooling check cannot be made).
• MARGINAL — no FAIL or UNKNOWN, but the cooling check is NEAR LIMIT.
• FEASIBLE — every check PASSes.

A FEASIBLE verdict for a SoC-limited module whose datasheet defers the ambient ceiling to the thermal design guide carries LOW confidence: the ambient enters only through the cooling check.

5. Cooling classes, enclosure classes and margins

Margins: 5 °C design margin on a TTP limit, 10 °C on a SoC junction limit, 5 °C marginal band. The bands, factors, rises and margins are class E engineering figures — anchored on the reference designs and worked examples in the vendor thermal design guides, not measured per product — and are published in the dataset so they can be argued with.

6. Vendor limit table and sources

Every row in datasets/thermal-limits.json carries the document, URL, retrieval date and a verbatim quote of at most 25 words for each limit. Vendor datasheets hosted on distributor or community mirrors are class A by document with the mirror noted. The engine returns the module's sources with every result.

7. Alternatives and remediation

With a limit and a power on record the engine also reports, for the chosen enclosure and altitude, every cooling class with its deliverable °C/W and whether it passes (and whether it would be marginal), the power the chosen cooling can hold at this ambient ((limit − margin − air) / deliverable), and, for sealed enclosures, what a vented enclosure would do to the internal air. Each failing or marginal check names the remediation that flips it: a lighter cooling class that passes, a power ceiling, a vented enclosure, a wider-rated module or carrier.

8. Evidence classes and confidence

• A — vendor thermal design guides, datasheets and product pages (all limits and ranges except the Raspberry Pi 5 range).
• C — a Raspberry Pi engineer's forum statement for the Pi 5 operating range.
• D — the cooling-capacity constraint (class A limit combined with a class E band) and an ambient check carried by the SoC / TTP limit.
• E — cooling bands, enclosure factors and rises, margins, the fan-in-sealed rule, the no-heatsink rule.

Confidence: HIGH for ambient and power checks with published figures; MEDIUM for a TTP-limited cooling check; LOW for a SoC-limited cooling check, an ambient check carried by the limit, or any UNKNOWN. The overall confidence is the lowest of the four.

9. What invalidates a result

• A poor thermal interface or partial contact with the thermal transfer plate — the bands assume the guide's full-contact mounting.
• Unbalanced workloads: the Thor guide gives a higher junction-to-plate resistance for unbalanced loads; the checker uses the balanced figure inside the vendor limit.
• A power figure below the workload's real sustained draw — use the preset's watts or a measured module power, not the idle figure.
• Solar gain on an outdoor enclosure that exceeds the solar rise you entered.
• An enclosure that does not match its class (a “vented” box with blocked vents behaves as sealed).
• Altitude above 6000 m, or ambient outside −60 to 90 °C, which the engine rejects.

10. Method changelog

Method changes bump the method version; new or re-verified vendor limits bump the dataset version. Both are in every result and in the citation block.