How do multi-port USB C devices prevent one port from supplying power to another - Page 1
Forum section: electronics / beginners

author: oneil
author_rank: Newbie
timestamp: October 23, 2024, 02:35:35 am
content: Hi all, first time posting hereI’m working on a design that is essentially a USB battery pack. It will have a USB port for charging the battery, and a USB port for that battery to charge some other device.This got me thinking… what if someone plugs the output port into the input port? This could conceivably happen on something like a MacBook, which has multiple USB-C ports. How does Apple prevent one port from charging the other?My understanding of USB PD is that, in my battery pack scenario, I should configure my input port as an “Upstream Facing Port” by placing pull-downs on the CC lines and I should configure my output port as an “Downstream Facing Port” by placing pull-ups on the CC lines. That’s all well and good, but none of that prevents my DFP from giving power to my UFP!Is this something that the USB-IF has already thought about (I’m guessing yes), or will I have to get clever with this?And no, I can’t use the simple solution of only allowing one of my two ports to be active at a time: my pack must be able to be charged while at the same time provide power to a secondary device over the DFP.Any advice would be greatly appreciated

author: Jeroen3
author_rank: Super Contributor
timestamp: October 23, 2024, 05:51:50 am
content: Good question, I should try this on the battery bank I have.

author: oneil
author_rank: Newbie
timestamp: October 23, 2024, 08:43:33 pm
content: I have an old Anker pack. When I try this it does nothing. It also won't charge anything while the pack is being charged, so it must just disable the output port while the input port is connected.

author: radiolistener
author_rank: Super Contributor
timestamp: October 23, 2024, 10:49:23 pm
content: That's interesting question...I just tried to connect USB-A output of my 100W PD power bank to it's USB-C in/out and... it started self charging at 12V/1.5ABut when I trying to connect it's USB-C in/out with a second USB-C in/out nothing happens.It looks like self-charging happens because USB-A and USB-C ports are connected to a different PD controllers.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 25, 2024, 03:51:39 pm
content: Okay, I tried it. My ugreen powerbank supplies power a split second and then it goes to 0. Not sure how it knows...My laptop says "usb device needs more power".I am unable to charge the powerbank from my laptop using type C, so I cannot create infinite power. (the powerbank can charge the laptop)

author: jc101
author_rank: Frequent Contributor
timestamp: October 26, 2024, 09:34:22 pm
content: If you have the time ->https://www.usb.org/document-library/usb-power-deliveryMany, many USB-PD controller IC's out there pre-programmed ready to go.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 26, 2024, 10:59:48 pm
content: (Ideal diodes likeMAX40200can be used. It has 0.043V drop at 5V 500mA, and an enable pin that when pulled low, stops current flow (in either direction): basically a near-ideal diode with an enable/tristate/high-Z pin. They're pretty expensive, though, at or over 0.40€ apiece in a full reel, and you'd need two per USB port – one to control power to the USB device, and one to control power from the USB to the charging circuit.)

author: oneil
author_rank: Newbie
timestamp: October 30, 2024, 01:11:40 am
content: Quote from: Nominal Animal on October 26, 2024, 10:59:48 pmCan you explain a little more how this would work? I see how you could use those to “gate” the VBUS voltage between the supplies and the two connectors. But, in my eyes, the crux of this problem is how do you distinguish between the device being plugged into itself vs. the input and output ports both being used simultaneously, but are connected to an external device.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 30, 2024, 02:18:49 am
content: Quote from: oneil on October 30, 2024, 01:11:40 amThe best answer in my opinion isyou don't. That's why my answer was in parentheses: you can use ideal diode ICs for the standard cases, but your case sounds like something you neither can nor should guard against, or deal as a specific case at all.What matters is that if the device is plugged to itself, no damage will occur. Saving power when the device is plugged into itself is not a good enough reason to specifically detect and guard against it, beyond making sure the battery pack is not harmed/damaged doing so, because of the fundamental technological issues/problems in trying to do so. Wasting power, but causing no other ill effects, is absolutely acceptable.Consider the case where someone plugs an USB isolator (of any kind) to your battery pack. The pack has absolutely no way to reliably detect that it is receiving power from itself, because there is an external power device in the loop. I argue that the pack should not even try to do so, and instead do what the user intended: waste stored power in the internal converters and circuits. (Logically, you can consider such an isolator as a pair of devices: one USB-powered motor, and another a generator with an USB output.) Any kind of shenanigans with the USB power rail (like detection pulses or some high-frequency component on top of the DC) can/will negatively impact ordinary devices, so please don't go that way.Anything with a switchmode converter is essentially the same thing. That includes USB PD voltage conversion.The one possible solution is to have a USB PD controller, that can detect (via timing) when it is communicating with itself, plus handling and the no-communication 5V rail with (ideal) diodes. That is, for the base 5 volt non-negotiated rail, you have asinglerail for both charging and output, so that the direction of the current is determined by the voltage. Yes, it does mean that if someone connects a 5.1V wall wart to your battery pack, it will try to source enough power to handle all 5V outputs in your pack.I don't like that myself, and would instead prefer each USB port to go through a DC converter when charging the pack, and accept the ensuing losses; including the losses (but no other negative effects) if someone plugs the battery pack to itself, trying to use the pack to charge itself.

author: oneil
author_rank: Newbie
timestamp: October 30, 2024, 11:45:52 am
content: Thanks for your two-cents Nominal Animal. You’ve got me convinced. I guess burning up a little power isn’t the end of the world, and you’d have to be dumb to try to plug the device into itself anyways. I usually try to take away the opportunity for the user to do something dumb with my designs, but seems like in this case it isn’t worth the effort since any “solution” I come up with would potentially compromise the rest of the design (as you noted).Thanks!

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 30, 2024, 03:06:13 pm
content: Quote from: oneil on October 30, 2024, 11:45:52 amI can definitely appreciate that. One of my forever projects is adding small displays to Linux-based appliances like routers and NAS boxes and such, that displays the internal status to nontechnical users in a way they can act on, without any way to actually misconfigure the appliance. Sounds easy, but the practical implementation is all about human perception and nontechnical cognition, and thus closer toartthan science.I'm just a hobbyist on the electronics side, but a related issue affects almost all of software, and specifically security and error checking. Most software developers are "in a hurry", so they leave that stuff "to be added in later" (since that is what they did all through when they learned to program in the first place) –– which A) never happens, and B) can never happen properly, because that stuff has to be designed in, and cannot be added on top later on.When writing robust, secure code, a very similar problem to what you're trying to solve appears: What is enough? When you implement say something as simple as copying a file, what level of checking is sufficient? Should you just pass it to a helper, and hope for the best? Or should you read back the file and compare to the original, to verify the copy is correct?There, too, the correct answer is somewhat dull: No, you don't "reinvent the wheel". It suffices that unexpected input and errors are noted and the human user notified, but in 99.9% of cases –– even in secure programming –– there is no need tonotuse the standard interfaces and instead write your own "secure/safe" ones. Youdodo your best to note any errors you can detect using the standard interfaces, and pass those that cannot be internally handled to the human user; and this is what most software libraries (like libusb) fail to do, fully. (I could also tell you pages about the C11-C23 standardAnnex Kstuff that adds "safe" interfaces to the standard C library, but is just a silly variant interface to the standard ones changing the parameters slightly and adding a_ssuffix to function names, that actually doesn't make the situation any better; basically a perfect example of how even talented, experienced people can get this stuff utterly wrong if they don't look at the issue from several different complexity levels and their real-world effects. Hubris, really.)My own electronics questions you can find here, for example myLED backlight thread, shows I too tend to "over-engineer" my designs (seereply #92in that thread for the "final" design), but this is to ensure I can do all the tweaking needed to get it to work the way I like. It is sort of long-term cost minimization, by ensuring even prototypes can be tweaked modularily.Finally, my intent was not to try and convince you in any way. I'm only a hobbyist in electronics myself, and my writing style sometimes leads others to trust me more than I'm worth. I'm alsoexcessivelyverbose, and trying to do better on that front. Working with nontechnical users (in software development and workflows involving multiple applications) is something I've done sporadically for almost three decades, and have had both fun and exasperation doing so; so I've developed my own "golden path in the middle" that has worked well for me. I just don't know for sure how well it generalizes across cultures for example, so please don't be convinced by my arguments alone!