How to boost USB power delivery

Question

I have an old Raspberry Pi 3, which I believe offers 4x USB 2.0 ports with max 1.2A in total, according to documentation. I actually only use one port but for an SSD NVMe (using a USB housing) which is very power hungry. The SSD itself states 1.7A @ 3.3V which means ~5,61W, which means the USB would be trying to pull ~1,122A. Considering that the housing must contain some kind of voltage regulator from 5V to 3.3V, which generates some lost, I am assuming the USB housing is trying to pull at least 1.2A, which would be the RPi maximum. However I keep getting constant Undervoltage detection on the RPi when using the SSD. It does work, reads and writes, but often with undervoltage warnings and every once in a while it loses connection and corrupts a file during an undervoltage detection:

So I was trying a cheap solution to increase the power delivery of this port. After seeing a lot of posts here and some other sources, I decided to try the very basics first:

I see on my ext. power supply that it is indeed providing enough current and the SSD seems to be trying to be recognized by the RPi but it fails. I havent tried on windows but I assume I would get a "Device not recognized" as I also saw many people on other posts having the same trouble. After reading about, it seems to be related to some kind of VBUS sensing which is part of the whole handshaking process, but I am not really sure how this happens. So I tried to connect the Host's VBUS to the circuit as follows:

but still fails. Only thing that changed is that now the ext. power supply only provides power when the device is attached, but still not recognized. I saw that the power supply also delivers less current now with this solution, not sure why.

Reading all other discussions about the same topic seemed to be inconclusive to me. I saw different opinions but not really a final solution.

Does anybody know how can I correct the circuit so it does get recognized, without the need of buying a powered USB hub? Or at least why this is not working?

PS.: RPi power supply should be enough (official RPi PSU 5V@3A / 15.3W), not using HDMI or other peripherals. Only the SSD and Ethernet cable connected to the board.

---

EDIT: So it turns out the first solution DOES work. Problem was, I was making these wirings using those standard arduino jumper cables (about ~15cm long each) and realized that even if I connected both USB connectors directly to each other as a normal cable, it would still not work due to sensitive USB data exchange. Twisting the Data wires also did not help. Now I've soldered both connectors to each other without wires in between and it worked. Then I removed only the VUSB pin and took it from the external power supply. What kind of bothers me now is the fact that the power supply shows a current consumption varying between 150mA and 250mA. That is far away from the top limit, even when streaming a media file (which is the same situation that was causing undervoltage before). Now I do not have undervoltage warnings anymore, but I'm wondering why it was happening before, since the current doesnt seem to be that high. Only explanation would be current spikes (perhaps when fetching new data?). That means a big capacitor on the VBUS line could solve this problem without external power supply? Not sure if it is recommended, but I might give it a try. Or maybe Raspberry Pi is not providing full current capacity? Is there any kind of fuse/software limitation to be checked?

---

EDIT2: I did some measuring with the oscilloscope and it seems I have constant peaks indeed:

Unfortunately I just had 9x 10 Ohm resistors to do the shunting, then applied a bit higher voltage with the power supply (~5.3V) and it does reach peaks of 1.30V, which means roughly ~1.2A in fact. The whole peak however lasts for less than 1ms and happens every second more or less. So a big enough capacitor on the VBUS line should do the trick, correct?

Answer 1

You've done a nice job collecting clues. I suspect the root of this problem is that the wall power supply into the RPi is "not as good as you think it is", rather than the RPi's internal power routing to the USB port being inadequate for the USB-to-NVMe SSD peripheral's needs.

The original under-voltage warnings indicate that the power into the RPi on-board power supplies is dropping below the minimum operating voltage. However, a single USB device drawing 1.2A (which as you mention is the rated current available from the port) should NEVER cause the RPi internal voltage to droop much, unless the wall USB 3A PSU has poor transient response or the USB power cabling supplying the RPi has a weakness.

Confirm this by going back to unmodified USB port setup and measure with your o'scope +5V-to-GND at the RPi's 40-pin GPIO header pins during the original problem scenario. These header power pins are basically directly connected to the RPi's input (USB) power rails. Setup the O'scope for "Peak Capture" acquisition mode, 10 µs div horizontal (can vary during test), single-shot (stop after one trigger), and trigger on falling edge with threshold voltage starting at about 100mV to 200mV below the high-freq power rail noise range with trigger coupling HF reject ON -OR- (if available) set trigger to special "dropout" detect mode with duration exceeding 10 µs (which would allow the threshold voltage to be even closer to +5V nominal). Given the symptoms, I suspect you'll see voltage dropping out significantly on the RPi's +5V internal rail during SSD activity.

Then instead of connecting your nice big external 5Vdc 10A power supply as a hacked-in-feed for the downstream USB-NVMe device, try using this big 10A supply to replace the original RPi wall PSU. Disconnect the RPi wall PSU completely, and connect the external 10A supply via (short as reasonable) 20 AWG or heavier wire to the RPi +5V and GND on the 40-pin header (wrap or clip the wire directly to the pin or solder it, avoid using a small signal jumper). Now run the same SSD test again and monitor the +5V voltage again at the RPi header. If the problem goes away, you should try a different/better wall PSU to power the RPi, or if you want to try your idea adding a big capacitor with old supply, add it back at the GPIO header power pins (rather than at the downstream USB port).

Answer 2

USB has VBus sensing for plug-in detection. A separate power supply kind of messes with this. Unless you can convert the nvme to self-powered, this is not a feasable method.

Several options:

• Delay the secondary power supply until the kernel is loaded.
• Powered USB hub. The USB hub will do the PNP detection and supply extra power.
• External power HAT, several options are available to power the raspberry pi over its expansion header. This eliminates the limited troughput of the USB connector. You can even use both the HAT and the USB plug.

I think the USB hub is the easiest.

But first: ensure your primary power supply is capable and uses a proper 3-5 A rated cable.

Answer 3

So if anyone runs into similar issue, here were the findings:

• The first cheap solution (deriving just the USB power lines from external supply) DOES work. What did not work was manually creating a small cable with arduino wires. But as long as I soldered both USB connectors to each other, so not using any wires anymore (and therefore reducing the size to a few cm), it worked. The only issue is that it will be always driving power also when the host is sleeping, off, or removed. Then it comes the second solution with mosfet.

• The solution with mosfet also worked, so the host's VUSB serves only as trigger to the mosfet, allowing the USB device to only pull current when the host is on. Using a low RDS mosfet allows a negligible voltage drop and fast enough switching / transient response.

• cables are indeed VERY important, not only the quality, but also the thickness of wires. Also be aware when using USB adapters (from A to C, micro to C and so on)

• NVMe SSD DOES drain a lot of current but from what I've seen, it happens mostly in short bursts as showed above, so you dont have to worry about constant high current, but rather with good transient responses