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

Inputs (WP-01). A field that is not stated takes its documented default and is listed in provenance.defaulted; a field that is stated but invalid — a count of 0, a negative, a fraction or a non-number, true in place of a count, an unknown value of an enumerated input, or an empty string — is rejected with VALIDATION_ERROR naming the field, never replaced by a default.

Input keys (WP-02). The engine accepts one list of input keys — the inputs documented here and their declared backward-compatible aliases. Unknown input keys are rejected with VALIDATION_ERROR naming the key: an invented or misspelt key is never silently ignored, a __ test hook never reaches the engine, and an alias sent together with the key it stands for is rejected too (the engine would read only one of them). export_json.inputs echoes every input the engine honoured, so replaying it reproduces the result.

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; when the node is the developer kit (devkit: true) and no carrier is named, against the input window of the module's developer-kit carrier row in the production-carrier registry (Orin Nano and Orin Nano Super, and Orin NX 16GB and 8GB, which NVIDIA supports on the same carrier: the 9–20 V DC jack); otherwise against the module's. The requirement judged is published as detail.judged_against (carrier_input, devkit_carrier_input or module_rail), with the kit row in detail.devkit_carrier. A module with no developer-kit row keeps its own window, and the assumptions say so. The Orin Nano datasheet lists two VDD_IN windows because one 260-pin socket serves two modules: 4.75–5.25 V when MODULE_ID is low (Orin Nano) and 4.75–20 V when it is high (Orin NX). Only a window inside the module's own rated input applies to it, so with no carrier named a 12 V or 19 V rail into an Orin Nano FAILs against 4.75–5.25 V — the 4.75–20 V window is reported, marked as belonging to the other module, and never authorises the rail. Name the carrier and its input window is judged instead. The constraint's available is the applied window as {min, max} (not a single scalar voltage); detail.range repeats the bounds with the datasheet selector, quote, and the MODULE_ID / carrier prerequisite that selected it. A rail outside the window FAILs with that window named, and the verdict is NO FIT. Both carrier and module windows are reported when both exist. When neither publishes a window, or no rail was given, the check is UNKNOWN.

A board or accelerator whose vendor states a single fixed input is judged against a window around that voltage, never left UNKNOWN: the Raspberry Pi 5 against the USB Power Delivery safe 5 V range (4.75–5.5 V, class B; Raspberry Pi recommends a 5.1 V supply), the Hailo-8 and Hailo-8L against their datasheets' 3.3 V ± 5 % (3.135–3.465 V, class A), and the Coral M.2 Accelerator against its datasheet's 3.3 V ± 10 % (2.97–3.63 V, class A) or the USB Accelerator's 5 V bus. The stated voltage PASSes; a rail outside the window FAILs and the verdict is NO FIT, because 12 V or 24 V into a 5 V board is outside its rating. UNKNOWN is left for modules that state no input at all (RK3588, Thor).

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

A requested power mode is read as a power ceiling. An id that is neither a preset of the module, a wattage ceiling, MAXN nor default is a validation error naming power_mode (HTTP 400); it is never sized at the registry default. A requested mode that is not a preset of the module is sized at the module's highest preset at or below the requested ceiling, and the result publishes the ceiling, the selected preset and the resolution with an informational note; when every preset of the module exceeds the ceiling, a power_mode_ceiling FAIL makes the verdict NO FIT. For example, a 40 W request on a Jetson AGX Orin 64GB (presets 15 W, 30 W, 50 W, MAXN) is sized at its 30 W preset, and a 7 W request fails: its lowest preset is 15 W. A named mode is never sized at the vendor maximum as though no power were given.

A carrier can feed a module less than the module draws on another board. When the board the module sits on — the named carrier, or the developer-kit carrier of devkit: true — states a module-power limit in the production-carrier registry, a carrier_module_power check holds the power mode against it. NVIDIA’s carrier specification says the Orin Nano developer-kit carrier supports every Orin NX module but feeds it 5 V only, and that “Orin NX 40W (MAXN_SUPER) is NOT supported on the developer kit carrier board” (Super mode on Orin NX needs a carrier with a higher-voltage rail). So an Orin NX at the 40W or MAXN_SUPER preset on that carrier is a FAIL and the verdict is NO FIT, citing that statement (class A). A preset within the 25 W the carrier supplies (5.0 V × 5.0 A at the module connector, a class D derivation) PASSes. An uncapped preset or a figure above 25 W is UNKNOWN until validated on the board: the derived bound never eliminates. The same module on a production carrier that states no such limit is judged against its own Super envelope, as before.

The PSU check takes its status from utilization against the shared thresholds: PASS below 0.8, NEAR LIMIT from 0.8 through 1.0, FAIL above 1.0. 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.

Above 1.0 is a FAIL only on evidence that can prove the shortfall (elimination authority). The power figures are the vendor's and the arithmetic is exact, but the default 1.5 peak factor is a class E estimate. So the check FAILs when the sustained draw alone — module plus peripherals, before any peak factor — already exceeds the supply, or when you stated the peak factor yourself; when only the default factor takes the requirement over the supply, the check is REQUIRES VALIDATION with the shortfall stated and the verdict NEEDS VALIDATION, never NO FIT.

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:

Ten of the fourteen publish a usable input window (the Coral row carries two, one per variant, without a single rated range) 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. NVIDIA does not state the Orin Nano kit's adapter wattage on a reachable page, so its 45 W is taken from the kit's developer-kit carrier row in the production-carrier registry and quoted from an authorised distributor's box contents (class C). The Jetson Thor kit's adapter wattage is not on record, so a Thor developer kit's PSU check stays UNKNOWN. For the Raspberry Pi 5 the board's maximum draw and its supply rating are separate figures. The 25 W is the supply: Raspberry Pi recommends its 27 W USB-C supply, and the board gives 1.6 A to USB peripherals only on a 5 V / 5 A (25 W) supply (class A). The draw is 11.6 W, a measured board peak under a sustained Linpack stress (class C; Raspberry Pi publishes only the typical 800 mA bare-board current). USB peripherals, SSDs and HATs are extra and belong in peripherals_w.

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.
• B — a standard's range applied to a stated fixed input (the USB Power Delivery safe 5 V range for the Raspberry Pi 5 and the Coral USB Accelerator).
• C — the Orin Nano developer kit's 45 W adapter (distributor box contents), and the Raspberry Pi 5's 11.6 W maximum board draw (independent bench measurements).
• 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.