Excessive battery voltage when back-feeding the Raspberry Pi?

GoPiGo
,
1

@cleoqc
@cyclicalobsessive

There have been repeated reports, including some by me, that mentioned that the indicated battery voltage rises to exceptional values, (considerably in excess of the rated voltage), when the Raspberry Pi is being supplied with power from an external source - like via its power connector - while also being supplied with power via the GoPiGo’s battery.

There is at least one case where a user reported that overpowering the controller via the Raspberry Pi caused “something” on the controller board to overheat.

I remember being told that this was an artifact of unknown origin, was related to the way voltage was measured by the controller, and wasn’t a problem.

The other day I finished working on a repair/upgrade to both Charlie and Charlene:

  • I replaced all the soldered wire connections on Charlie with pluggable connections, since part of the problem with Charlie resulted from repeated soldering and unsoldering connections when removing the controller board.

  • I also removed the two terminal posts from Charlie as they were no longer needed.

  • I added a voltmeter to Charlene using the same pluggable connections I used on Charlie.

  • I arranged to be able to monitor either the +5 or +12 circuit voltages.

    • On both robots I attached a wire to the output side of the power-switch MOSFET, measuring the VCC, (+12v) voltage as it exists on the controller, as well as a wire to the internal +5 buss on the Raspberry Pi of each robot.

Powering up the robots after the upgrades disclosed the following:

  1. Charlene’s +5v rail did not experience as much droop as Charlie’s did.
    • I don’t know if this is due to inadequate contact pressure on the GoPiGo’s connector or a peculiar difference between the power consumption of an earlier version of the Pi-4 and a later one.
       
  2. Any time the +5v supplied by the Raspberry Pi exceeded the +5v supplied by the GoPiGo controller, the +12v VCC buss on the controller jumped almost immediately to somewhere around +19/+20 volts.
    • Note that this was true for both robots.

Examination of the schematics for both early and later version GoPiGo3 controller boards disclosed:

  1. Both +5v pins from the GoPiGo controller board are NOT being used, sending all the required power through only one contact.

  2. There is no isolation diode to prevent the attached board from overpowering the GoPiGo’s controller board.

  3. The large electrolytic capacitor has a maximum rated voltage of 16v.&nbsp: 19v is right at the edge of 20% overvoltage - which isn’t good.

  4. Several circuits, including the motor driver’s dual H-bridge chip, are driven direct from VCC.  I haven’t looked at the datasheets for these chips, so I don’t know what the maximum VCC rating might be.

Likewise, examining the buck converter’s datasheet[1] disclosed:

  1. The datasheet for the buck-converter used to create the +5v rail on the controller, (a BD9D320EFJ synchronous voltage buck-converter), has no mention of overpowering the output or the effects thereof.  Therefore I’m have no idea what should, or should not happen.

  2. One side of the voltage generating inductor is connected directly to the output of the converter chip, and the converter chip’s output is a N/P-type MOSFET pair switching the output inductor’s input between VCC, (+12v), and ground.

  3. Overpowering the output inductor with a higher voltage should force the overpowering voltage to VCC through the “upper” MOSFET in the driver pair.

  4. The current that’s being back-fed into the buck converter will also have an inductive reactance component, with a possible increase in voltage across VCC, though I have not confirmed it.

Conclusions:

  1. Since the buck-converter’s data sheet doesn’t mention overpowering the output, I have to assume that the result of overpowering the converter chip is undefined.

  2. This creates an approximately 60% overvoltage on the VCC buss.  I am forced to assume that a 60% overvoltage is potentially destructive to the controller board, and ultimately to the Raspberry Pi connected to it if the upper MOSFET of the converter’s driver fails and shorts VCC to the Raspberry Pi’s unprotected +5v rail.

  3. This will need additional research to determine the actual failure modality and appropriate mitigation strategies.

Immediate mitigation suggestions:

  1. Tie the two +5v Raspberry Pi power source pins on the controller together to reduce possible voltage drop.

  2. Add a Schottky isolation diode between the +5v power pins on the controller and the source of the +5v voltage itself to prevent overpowering the controller’s +5v buck converter.

========== Footnotes ==========

  1. https://www.rohm.com/products/power-management/switching-regulators/buck-step-down/integrated-fet-synchronous/bd9d320efj-product
1 Like
2

Wow - I’m glad I have never had need to “dual power” my robots.

I do worry about a Raspberry Pi power “back flow” using powered USB sensors (LIDAR, Oak-D camera). I bought some USB-A power blockers but have not actually installed them, but I don’t believe the power would backflow all the way to the GoPiGo3.

1 Like
3

You can verify this by plugging in the USB connection without the external +5 supply and see if it lights.  If it does, the Pi is back-feeding the camera.  Though, that might be by design - so that you can configure the device w/o having to go full-bore with the power.

You can verify if the camera is back-feeding the Raspberry Pi by attaching the camera’s USB port to the power input of the Pi, (or plugging in a USB light or fan, etc.).

I would also assume that the people who do things like the Oak-D understand that it’s going to be plugged into a host device that can supply power, and would take that into account when designing it.  Though testing that assumption isn’t a bad idea either.

The problem isn’t “back-feeding” per se, it’s overpowering the controller’s +5v rail.

I notice that the GPG’s battery input has an isolation diode to protect against some poor clod connecting the battery backwards - all the “goodies” are on the other side of that diode.

I also strongly suspect that the folks at DI didn’t even imagine a potential need for supplemental voltage to the Pi itself requiring back-feeding - and didn’t include a diode for just that reason.

1 Like