Will this module survive this enclosure?
Pick a module, its power, the enclosure class, the cooling class and the hottest ambient the site sees. The checker holds them against the vendor's own limits — thermal transfer plate or SoC temperature, operating range, maximum module power — and returns FEASIBLE, MARGINAL, NOT FEASIBLE or REQUIRES VALIDATION, with the thermal resistance the limit demands, the cooling classes that would pass, and the power the chosen cooling can hold. It predicts no junction temperature; it tells you whether the design is worth building and qualifying.
01 · Define the thermal design
Advanced
03 · How this works
Four checks, one arithmetic step
Ambient rating holds the site ambient (plus the enclosure class's internal rise) against the module's and the carrier's published operating ranges. Power ceiling holds the module power against the vendor's maximum. Cooling capacity is the only arithmetic: the vendor limit — thermal transfer plate temperature for AGX Orin and Thor, SoC operating temperature for Orin NX / Nano, Raspberry Pi 5 and RK3588 — minus a design margin, less the enclosure air, divided by the power, is the thermal resistance the cooling must deliver; each cooling class has an engineering band for what it delivers, derated by the enclosure's airflow and the site altitude. Fan in sealed flags a fan heatsink inside a sealed box.
Categorical on purpose
The result is FEASIBLE, MARGINAL, NOT FEASIBLE or REQUIRES VALIDATION — never a predicted junction temperature. The limits are class A (vendor documents, quoted); the cooling and enclosure bands are class E engineering figures anchored on the thermal design guides' worked examples, which is why a passing design still goes to the bench with tegrastats at the maximum site ambient.
Full rules, bands, source list and what invalidates a result: methodology. Raw dataset: datasets/thermal-limits.json. Carriers and systems with rated temperature ranges: production carriers. Power presets: Jetson power modes.