Jetson Power & PSU — methodology

Contents

1. What it decides, and what it does not
2. Inputs
3. Which board the rail is judged against
4. The four checks
5. Verdict rule
6. Class E engineering defaults
7. The module registry and its sources
8. Evidence classes and confidence
9. What invalidates a result
10. Method changelog

1. What it decides, and what it does not

The engine answers one bring-up question: for this module at this power mode, on this carrier, from this DC rail — is the supply inside the window the datasheet specifies, is the module inside its power ceiling, is the PSU big enough with a peak factor, and is powering it over PoE something the vendor actually documents? It returns FIT, FIT WITH RISKS, NEEDS VALIDATION or NO FIT, with the PSU wattage to buy.

It does not model supply efficiency curves, inrush waveforms, rail sequencing, transient response or brown-out behaviour. Those depend on the actual supply, cable and capacitance, none of which a form can capture. What it does instead is hold the design against the vendor's own printed limits and say plainly when the vendor prints nothing.

It is also not the Power Budget engine, which sizes a whole deployment's electrical envelope including UPS runtime and cooling. This one is about one node's rail and its supply.

2. Inputs

3. Which board the rail is judged against

A supply plugs into the outermost board, not into the module. An Orin Nano module's VDD_IN is a 4.75–5.25 V rail; the developer kit's carrier board takes 9–20 V at its DC jack and regulates it down. Judging a 12 V bench supply against the module's 5 V window would fail a configuration NVIDIA ships in a box.

So the rule is: when a carrier is named, the rail is judged against the carrier's published input window; otherwise against the module's. Both windows are always reported, and the applied one is flagged, so the reader can see the rail the carrier has to deliver as well as the rail they are supplying. When neither publishes a window, or no rail was given, the check is UNKNOWN.

One implementation note: a published window written as “9-19V DC” can be parsed with the hyphen read as a minus sign, giving a nonsensical −19 V lower bound. A window whose lower bound is negative while its upper bound is positive and smaller is read back as the range the vendor printed rather than being used as-is.

4. The four checks

The PSU check takes its status from utilization against the shared thresholds: PASS below 0.8, NEAR LIMIT from 0.8, FAIL at 1.0 and above. recommended_psu_w is the required watts rounded up, and it is reported whether or not a supply was given — so an UNKNOWN check still ends in a purchase order rather than a shrug.

5. Verdict rule

• Any check FAILs → NO FIT.
• Else any check is UNKNOWN or REQUIRES VALIDATION → NEEDS VALIDATION.
• Else any check is NEAR LIMIT → FIT WITH RISKS.
• Else FIT.

Every non-PASS check that has a fix lists it in remediations: a supply inside the window or a DC-DC converter to reach it, a lower power mode, a bigger PSU, or a PoE splitter whose output sits inside the module's input window. The result also carries the module's power presets from the power-mode registry, so the power mode that would fit the supply is one glance away.

6. Class E engineering defaults

It is a class E engineering figure, named as such in the assumptions of every result and overridable from the Advanced panel and the API. Nothing else in the engine is an estimate: every voltage window, power ceiling, adapter wattage and PoE statement comes from a vendor document.

7. The module registry and its sources

Fourteen modules and accelerators, every row carrying the vendor datasheet, design guide or product page it was read from, with a verbatim quote and a link:

Seven of the fourteen publish a usable input window and twelve publish a power ceiling; the rest report UNKNOWN rather than a guess. Some records were read from local PDF mirrors whose download URL the research pass did not record: those are kept only where the same document is reachable at a URL the site already cites (the Thor thermal design guide, the RK3588 datasheet, the Raspberry Pi 5 product brief, the Hailo accelerator page), and are otherwise dropped and counted in the dataset's gaps. Two conflicts were resolved in favour of the datasheet: AGX Orin 32GB uses the datasheet's 40 W rather than the product page's 15–60 W band, and Thor T4000 uses the product page's 70 W rather than the thermal design guide's MAXN figure. Developer-kit adapter wattage is published for the AGX Orin kit (inferred from the port's maximum USB PD rating, and flagged as such) and the Raspberry Pi 5; the Orin Nano kit's is not published, so it is null.

8. Evidence classes and confidence

• A — every module figure: input voltage window, nominal rail, maximum module power, developer-kit adapter, PoE documentation; and the carrier windows and power ratings from the production-carrier registry.
• D — the PSU sizing check, which combines class A power figures with a class E peak factor.
• E — the peak factor, and any check whose vendor figure is missing (reported UNKNOWN).

Confidence: HIGH for the voltage and power-ceiling checks when the vendor publishes the figure; MEDIUM for the derived PSU check and the PoE check; LOW for any UNKNOWN. The overall confidence is the lowest of the four.

9. What invalidates a result

• A supply whose rated wattage is a peak rather than a continuous figure, or one that derates at temperature.
• Voltage drop along a long or thin DC cable: the rail at the jack is what the check assumes, not the rail at the bench supply.
• Peripherals that draw more than entered, or that are hot-plugged and add inrush of their own.
• A real peak above the 1.5 factor — a heavy camera pipeline plus a boot storm can exceed it.
• A carrier that has its own regulator losses or a lower continuous rating than its connector implies.
• Any figure the vendor does not publish — the check reports UNKNOWN and the verdict becomes NEEDS VALIDATION rather than a number. This is why both Thor modules come back NEEDS VALIDATION on the voltage check.
• A PoE splitter whose output voltage sits outside the module's window: the PoE check answers documentation, not the splitter's specification.

10. Method changelog

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