Your USB-C Charger Is Having a Conversation. Dr. PD Lets You Read It.

A charger says 100 watts. A laptop charges slowly. Swap the cable and it behaves differently. Nothing is visibly broken, and the plug still fits. Where do you start?

Dr. PD, developed by Marco Tabini and T76, is aimed at the missing evidence between a USB-C connection and the power it actually delivers. The open-source project captures USB Power Delivery messages and correlates them with voltage and current. It can also act as a programmable sink, asking a source for particular behavior instead of waiting for an attached device to do it.

The project is under active development, with repository work inside this October research window. Its public materials describe validation testing and a Crowd Supply prelaunch, not an already completed crowdfunding campaign. Treat this as a look at an emerging instrument, not a purchase recommendation based on independent testing. Project source and status.

Read the Agreement Before Blaming the Charger

USB-C describes a connector ecosystem. USB Power Delivery describes a negotiation. The two should not be collapsed into a single assumption that any compatible-looking cable will deliver the number on the box.

An instrument that only shows current power answers one question: what is happening now? Protocol capture can help answer another: what did the devices agree should happen?

Those are different observations. A source may offer a set of capabilities, a sink may request one, and later events may change the connection. The eventual electrical state can be perfectly consistent with a request that was not the request you expected.

For a troubleshooting session, begin with a concrete symptom. Does the connection start normally and then reset? Does the sink request a lower-power contract? Does current remain low even when the contract is suitable? Each question points toward a different explanation. A long packet log is not useful until you know what you are trying to distinguish.

Three Observations to Keep Together

The practical attraction is correlation. A message, an electrical change, and a device symptom can be placed on the same sequence rather than remembered as three separate events.

For example, a reported disconnect followed by a new negotiation is different from a stable connection whose load simply falls. A voltage change aligned with a request is different from a drop that happens before any obvious renegotiation. These are hypothetical diagnostic patterns, not results from a test we performed with Dr. PD.

Good capture habits are uncomplicated:

• Record the charger, cable, sink, and software or firmware versions.
• Start capture before the behavior occurs.
• Change one part of the setup at a time.
• Keep both the protocol trace and the measurement context.
• Separate an observation from the explanation you think it supports.

A cable swap that fixes a problem is useful evidence. It is not automatically proof of precisely which cable property was responsible. A trace can narrow the question without pretending to answer every part of it.

A Message Is More Than a Label

The published interface includes a detailed message view, filters, and trigger controls. That matters when the interesting event is brief or buried among routine traffic. The project's documentation also describes host libraries and automation interfaces, making repeatable capture a design goal rather than an afterthought. Dr. PD documentation.

Filtering is helpful, but it introduces its own discipline. If a view hides ordinary traffic, preserve the original capture. A narrow view can make an event easier to read while concealing the sequence that explains it. The same warning applies to triggers: a trigger defines what qualifies for attention, not what qualifies as relevant physics.

For a repeatable test, the pass condition should describe behavior. "No unexpected resets during this capture interval" is more useful than "the graph looked clean." So is an explicit record of what would count as an unexpected reset.

Asking the Charger a Different Question

Programmable sink mode changes the workflow. Rather than relying entirely on a laptop or accessory's choices, the instrument can request profiles and exercise selected cases. The project describes support for SPR, EPR, PPS, and AVS, with a stated design envelope up to 48 volts, 5 amps, and 240 watts. Those are published specifications, not performance numbers verified by Meteor Makers.

A maximum supported envelope should not be read as permission to improvise a high-power test fixture. Leads, cables, connectors, loads, thermal behavior, and instrumentation all need to be suitable for the actual experiment. Begin within the documented operating limits, and consult the current hardware documentation before connecting a source.

It is also worth distinguishing a request from a sustained load test. Negotiating a contract does not by itself demonstrate that a charger can maintain its rated output under every condition. That requires an appropriate load, defined conditions, and measurements over time. One useful tool does not replace the rest of the bench.

Why the Open Design Matters

For an instrument, open hardware and software provide more than an invitation to modify the interface. They let a technically capable reader inspect what the device measures, where timing comes from, and how messages are decoded.

That transparency does not guarantee accuracy. It gives the accuracy question somewhere concrete to go. A firmware revision can change interpretation; a hardware revision can change a measurement path. Keep those revisions with a test record, especially if the point is to compare results across months or between benches.

The useful next milestones are documented validation, clear limits, stable release information, and examples that make captures reproducible. Crowdfunding availability is a separate milestone from those technical questions.

Dr. PD is interesting because it connects the agreement to the electricity. USB-C faults often become arguments about which box or cable to blame. A protocol trace tied to a measurement offers a better starting point: something you can inspect, repeat, and discuss.

What is your most stubborn USB-C problem: negotiation, resets, cables, or unexplained power limits? Leave the setup and symptom in the comments below.

Sources: repository, documentation, and Crowd Supply prelaunch.