Pdsink: USB Power Delivery Sink library for embedded devices | Hacker News Reader

Pdsink: USB Power Delivery Sink library for embedded devices

github.com

62 pointszdw23 comments

I looked at adding USB-PD as a replacement for a 12V barrel-plug power supply in a recent project.

One big issue that came up (and killed the idea) is that if you are not battery powered, then putting a USB-C power input on your device that will only work if you can negotiate 12V+ with adequate current will just cause confusion. In my case, I don't think I could even boot to an error message on 5V.

Phones and the like don't have this issue, since they are still usable (charging slowly) on 5V, but can make use of higher voltages and currents to charge faster.

So I guess my question for the implementer is how booting & negotiating on 5V and then accepting higher voltage is likely to work in practice.

In those cases you have to use a micro or purpose built controller chip to negotiate a higher power input while running off the 5V (bootstrap with dead battery mode). There are chips out for it including power regulation built in.

Add a small "charger error" LED which will be lit by your PD uC to indicate negotiation error or a charger unsuitable to your device due to voltage or current issues.

You could run on 5V with a boost voltage converter to 12V. For extra credit, you could run the USB-PD off 5V, negotiate 12V and only then switch it to the load.

If I need 12V/1A, then that suggests I need 5V/2.4A even with 100% efficiency. Without negotiating anything, a device shouldn't draw more than 5V/0.5A.

That's not to say that a boost converter doesn't have value, but it still leaves a gap where there could be confusion.

The confusion or complexity even multiplies if the device has additional USB-C for data transfer. In that case, you either have to mark one port as being the "power in" port, or you have to support power in and data out on all the ports, which gets complicated and expensive.

It would be a great move by the USB IF to think through this sort of thing more carefully. Right now the USB-c connector is so overloaded in terms of power, display modes, thunderbolt, speeds, etc. that it's very hard to predict whether two USB-c devices will connect and at what power or speed and with what capabilities. For power, it would be helpful to require supplies to have a standardized status LED so that e.g. green means that the supply is providing the highest power allowed by the device (not the supply), yellow means there's been a compromise, and red suggests an error condition.

Well the question is how many watts you need to display an error message. You made it sound like voltage was the main issue.

And yeah you're supposed to negotiate before pulling 2.4 amps at 5v but that's not usually a big deal in practice. Especially when you're actually supposed to stick to 100mA at first, but who does that.

A diagnostic LED sounds nice but given how most cables don't even have a speed printed on them good luck at something more invasive.

I will say that thunderbolt support isn't often an issue beyond the basic speed rating, and should be even less of one since USB4. And that power ratings are pretty simple, 60W or moreW. I really don't think the overloading of many different types of feature is a big deal, I think the single feature of unknown speed is the big issue-causer.

If you need 12V/1A, starting up and showing an error message at 12V/0.2A sounds quite feasible. Of course it depends on what's using up all your power. But at least microprocessors can usually be started at lower power levels (lower frequency) with a switch to high frequency once you've confirmed you have the power available. Display backlight can be dim until you have the power, and peripherals can be powered through a transistor so you can start delivering power after initial system checks.

But it's a bit more involved than just replacing a barrel jack with a USB-C port, and would require some design considerations early on

If you absolutely need it, use a separate uC / “trigger” chip for PD negotiation.

I think the GP's point is that this requires a 12V-capable USB power supply.

I have converted pretty much everything I have to USB-C, from toothbrushes to old laptops, and am very happy with the results. My solution is to only own high-quality power supplies with good support for PD. Having done this, the question "Why isn't this thing charging?" doesn't really arise.

The common device that this doesn’t work well for is the Raspberry Pi 5. For full power mode it needs an unusual 5V/5A power supply, and that is quite unusual.

Specifically it needs a supply that offers 5V/5A as a basic profile outside of PPS (programmable power supply), because the Pi doesn't support PPS negotiations. That is what's so rare, much more than the actual ability to do 5V/5A.

It’s more than unusual, it violates the spec. However you only need that to have full power USB

Here’s a tangent discussion from a while ago that I enjoyed, on bootstrapping PoE (Power over Ethernet) from UEFI: https://news.ycombinator.com/item?id=44111609

Looking back, funnily the top comment drew a parallel to negotiating USB-PD in u-boot, aka the bootloader. I suppose this wouldn’t have worked for your case though, since your device couldn’t boot at all on 5V.

The other issue with USB PD without a battery is that most chargers with multiple ports will drop the connection and renegotiate if any of the ports are plugged or unplugged (whether they need to in order to supply the new device or not).

(Relatedly, there's an empty niche in the market for a USB-C power bank that can act as a UPS: able to charge and discharge at the same time without interrupting the discharge port when the charge port is disconnected)

I confirm, baseus chargers really reset all ports when you change the number of consumers. But I think you usually have a choice between caring about a custom power source or using a standard one. IMHO, using a dedicated PD charge is still more convenient than alternatives.

they sell modules on AliExpress that claim to do that

https://a.aliexpress.com/_Ez4GjPQ

and some powerbanks advertise passthrough charging eg. https://amzn.eu/d/hApICf9

That one, sadly, does not have USB-C output, so it's fine for something you're wiring up custom but isn't a generic solution (which, to be fair, is the quite niche overlap of wanting to power something with USB-C without a battery and wanting battery backup).

> Relatedly, there's an empty niche in the market for a USB-C power bank that can act as a UPS: able to charge and discharge at the same time without interrupting the discharge port when the charge port is disconnected

I think there's a soft version of this already available. The term is "pass-through" charging. The power bank that I have [1] will charge itself and the devices at the same time (albeit at reduced rates suitable for overnight charging).

I agree that it would be super useful to have a device that is explicitly designed to provide maybe 5V/5A for a Raspberry Pi 5 without interruption, and perhaps double as a power bank.

[1] https://www.amazon.com/dp/B0DHRYDNXL

As far as I know, pass-through power banks will still universally drop the power on their output momentarily when they lose the connection on their input, though. That's the missing bit.

Why did the USB design committee not introduce a color code to tell the crap cables apart from the good ones? That would have solved so many issues.

Usually, devices are constructed to work at 5v without a main load, then handshake PD, select the desired profile, and turn the heavy load on.

You can also use various USB pd "decoy modules"

pdsink was done for more advanced scenarios, when a simple "trigger" is not enough or not rational.

- When you need dynamic load control - When mcu already has embedded USPD (some stm32g/WCH and others)

See the link to the reflow table protect in the readme.

In other words, when a simple "trigger" is ok for you, use it and be happy :). If something more complex required - then pdsink may be a good choice.

Reply on news.ycombinator.com