USB PD sink testing for Wi-Fi gateways and routers

2026 April 22

Many Wi-Fi router and residential gateway makers are moving from dedicated DC wall warts to USB-C Power Delivery (PD) power supplies to increase interoperability and reduce e-waste. In the wall wart model, each device ships with its own power supply, usually with a captive cable. When the plug or cable fails, the whole adapter needs to be replaced, and when a device reaches end of life, the adapter often goes in the e-waste bin.

New EU rules for external power supplies (EPS), including those used with wireless routers, generally require covered external power supplies to meet Common Charger requirements with USB-C / USB-PD interoperability and detachable cables, unless an exemption applies. The impact for manufacturers is that a device can no longer just be validated against the EPS it ships with. It also needs to work, or fail gracefully, across a range of USB-C sources and cables. 

How USB-PD Differs from a Fixed-Voltage DC Adapter

DC wall warts provide a fixed output voltage up to a maximum current. Because voltage, current capability, and connector type vary from one adapter to another, devices are generally expected to be powered from the supply they shipped with.

With USB-C PD, the source and sink negotiate power. The source advertises a set of Power Data Objects (PDOs), each describing an available voltage and current. The sink then requests a suitable PDO from that offered set if one is available.

The cable can also affect that exchange. A source can change the set of PDOs it offers based on whether the cable’s e-marker chip indicates support for higher current.

In theory, a USB-PD source that offers a sufficient PDO should be able to power a compliant sink. In practice, that interoperability has to be validated. It is not enough to test only the bundled power supply. The device also needs to behave correctly across the USB-C sources and cables it might encounter, including non-PD sources such as a random phone charger. If the source can't provide enough power, the device should fail cleanly and indicate the problem to the user through LEDs or other visible status signal.

What manufacturers need to validate

Manufacturers need to validate the following:

Nominal operation

  • successful negotiation and boot
  • stable operation at intended power levels
  • operation across alternate PDO sets
  • operation with different supported cable capabilities

Edge cases

  • lower-power source offers
  • delivered voltage or current not matching the negotiated contract
  • out-of-spec or malformed PD messaging
  • non-PD sources
  • controlled failure under brownout conditions

Why USBHub3c fits this problem

USBHub3c

USBHub3c can act as a programmable USB-C PD source or sink, advertise different source capabilities, and provide monitoring and control over VBUS and PD behavior. Here, USBHub3c is used to emulate the source side of the PD link so the gateway’s sink behavior can be validated. Instead of physically swapping through a large set of adapters, USBHub3c can step through source profiles by changing advertised PDOs and available power. This allows engineers to emulate different charger capability sets and test how the DUT responds to lower-power offers, out-of-spec conditions, and brownout scenarios.  With six independent ports, USBHub3c is a good fit when multiple devices need to be tested in parallel. If only a single DUT connection is needed, USBExt3c can also be used in standalone mode as a managed one-port USB-C test hub.

Using HubTool first, then automating with the BrainStem API

USBHub3c is built for both interactive control through HubTool and automated workflows through the BrainStem API. A practical way to develop these tests is to start in HubTool. Step through the source profiles, power changes, and fault cases manually while watching PD negotiation and VBUS behavior. Once the expected DUT behavior and command sequence are clear, move that logic into a BrainStem API script so the same test can be repeated across more devices and source conditions.

Example USBHub3c-Based Workflow

A typical workflow might look like this:

  • Connect the gateway DUT as a USB-PD sink to a USBHub3c port configured as a source
  • Enable PD logging and relevant voltage/current monitoring
  • Emulate the intended bundled-adapter power profile
  • Verify successful negotiation, boot, and stable idle operation
  • Place the DUT in a representative high-power operating mode
  • Cycle between lower and higher load states while monitoring behavior
  • Repeat under alternate PDO sets
  • Repeat for common non-PD USB source settings
  • Repeat with representative cable variation
  • Reduce available power to test lower-power cases
  • Override voltage or current to test fault handling

Because logging is enabled from the start, PD events can be correlated with DUT behavior and VBUS / CC signals.

What good sink behavior looks like

A well-behaved DUT should:

  • negotiate an appropriate power contract
  • boot reliably from supported source profiles
  • remain stable in idle and higher-power load states and across transitions
  • work with supported alternate PDO sets
  • behave correctly with supported cables
  • Indicate when there is insufficient power advertised or provided.  
  • fail cleanly and understandably under brownout or other marginal-power conditions

With USB-C, customers may power a gateway from adapters and cables other than the ones in the box. That could mean a source with different PDOs, a lower-power non-PD adapter, or a cable that limits what the source is willing to offer. Validating those cases helps engineering teams catch negotiation problems, instability under load, and brownout behavior before they become issues for customers. USBHub3c makes those conditions easier to emulate and automate.

Add New Comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
We are bots. Are you?