Friday, February 7, 2020

WIP: ACE LC 2.0 - A more refined discrete drive ESC. Plus an elaboration on discrete gate drive.

The LC 1.0 is fine, but I don't think it is quite the Afro 20FS/30 replacement that we need. The wire routing is not the easy and tidy affair it should be, the mosfets are old tech, the long skinny form factor is not the most universal and there are many layout lessons learned and so forth. Before I get sidetracked, I want to make sure what I started is finished here.

Goals were:
  • Use more modern mosfets with lower Rds(on) and higher ratings.
  • Improve all high current buswork and general beef level.
  • Have an Afro 20A FS/Afro 30A FS/ZTW Spider 30 like form factor.
  • Have motor phase pads at one end. DC bus and signal pads at other.
  • Fix resonator footprint for easier soldering.
  • Keep everything that worked well - sense network, gate drive, logic power, etc.

After several revisions, this is the result:



Specs:

  • ATmega8 MCU
  • Discrete drive (of course)
  • 18k/3.3k/18k sense network
  • LFPAK56 power stage. This can take any number of Nexperia devices, but the prime candidates for these discrete driven boards are PSMN1R4 and PSMNR70.
  • 25x46mm
  • 2 layer 2oz 10/10mil
  • Hand solderable


If you have been following this project when I was posting updates on reddit (before realizing that, you know, I should use my blog and not blog on forums) this is one more revision yet from the one posted last. Changes:

  • Improve MCU decoupling
    • Some decoupling caps had been elbowed out of the way from their rightful place adjacent to the MCU Vcc/Gnd pins at the layout stage. The other stuff in the way was moved, and the caps relocated to the proper position, removing some trace length and loop area.
    • Whack one more decoupling cap (C9) on there for good measure, for a total of 4.
  • Add polarity markings to the C8 footprint. This is the tantalum 5V rail bulk capacitor.
  • Increase the number of vias in the low-side DC bus going up to the sources of mosfets up top, and revise the via pattern a bit.
  • Put soldermask cutouts over those same via farms on both sides. The vias can optionally be solder-filled for better thermal and electrical performance.
  • Run a soldermask cutout down the outside edge of the low-side DC bus. This can be solder tinned or even have a wire or bar soldered on to decrease bus resistance further. Low side is where any voltage drop really counts and is a risk.
  • Move some traces to avoid risky low clearance to the board edge.
It's pretty much ready to go, next update will likely be boards in hand, hopefully soon.



So, this is a good opportunity to demystify discrete gate drive. Time for a schematic excerpt:

AH, BH and CH are (active-low) gate signal inputs from the MCU, PHASE_A through _C are obvious, GATE_AH through _CH are obvious, and DC_BUS is obvious.

This is the very same high-side gate drive arrangement used in every good old lower-voltage hobby ESC way back to the dawn of time and, more or less, right up until dronestuff started using Silabs EFM8 and ARM MCUs. The only difference is that generally R11, R12, R13 is 2.2K - the 1.6K (1.54K as shown) is my optimization, taking into account the power ratings of resistors.

This is a bootstrap circuit similar to what most halfbridge or three-phase gate driver ICs also use to do the same thing i.e. generate the offset voltage above the DC bus to turn on high-side N-channel mosfets or IGBTs. The capacitors (C4...6) are charged through the bootstrap diodes (D1...3) whenever the phase node is low. The voltage across this cap, referenced to the phase node, stays in the same place relative to the phase node when the phase node later swings up, and it is this voltage that lifts the gate above the source (phase node) on the high side device. Of course most gate driver ICs use a totem pole/push-pull power stage (similar to a tiny inverter phase leg, or an AVR pin driver) to more stiffly drive the gate in either direction instead of the single NPN transistor and ballast resistor, but it is largely similar.

How this works is that in the off-state (xH logic HIGH and thus driving the transistor at saturation through the base resistor) the node with the mosfet gate on the left end of the ballast resistor (R11...13) is pulled down to very near ground (actually Vcesat of the transistor) keeping the gate locked off. The bootstrap capacitor C4...6 is charged through the bootstrap diode D1...3. It is the ballast resistor that drops the full DC bus voltage minus the diode drop and Vcesat and establishes that voltage across the cap. To turn the gate on, the input is driven low or removed, the transistor turns off, and suddenly you have: phase node (high side source), charged cap, ballast resistor, gate resistor and gate. The voltage on that node with the left end of the ballast resistor, and the gate, now flies up to whatever is on the cap and feeds the gate.

Big obvious shortcoming of this simple circuit surrounds the ballast resistor. It is in the current path for charging the gate, so for a high drive current and fast switching time, you want to minimize it - but the lower it is, the more idle current it draws off the DC bus and the more power it must be rated to dissipate. Usually this ends up with fairly weak drive strength, which is why this circuit is not the greatest idea outside of relatively low gate charge mosfets, say <90nC.

Other, possibly major, shortcomings:

* There is no explicit undervoltage lockout for the voltage on the caps to prevent operation with critically low gate drive level. "Desaturation" events where a switch is partially-on and thus dropping a ton of power and violating its SOA due to insufficient gate drive are a major cause of inverters going bang, whatever the cause of the low voltage.

* The DC bus voltage is limited by the use of up to raw DC bus voltage minus a tad, to drive gates. This is why putting 6S on one of these makes me very nervous.

* There is no hardware-enforced minimum dead time or shoot-through prevention.

Gate driver ICs offer these features and rectify these failure modes/risks along with generally achieving better switching times and/or driving large gate charges with more drive current. But discrete drive boards are not often trouble sources if operated correctly. I have never had one blow up due to motor abuse or any apparent gate drive fault. I have only ever popped one board, and that was by straight 14.8V into a MCU.

The low-side driver in these arrangements is just the AVR pin driver (with a pulldown resistor for safety). The AVR pin driver is pretty beefy and can source/sink ~40mA and is 5V of course. But this does identify a factor in the prevalence of gate driver ICs in modern drone motor controllers - because these are by chance all using 3.3V chips that don't have the voltage to drive even logic-level mosfets competently and often don't have the current either.

3 comments:

  1. Always good to see more progress on these ESCs, I'll have to start a blaster soon so I have an excuse to mod them!
    Especially for explaining the hardware mechanics, you explained the high side driver before on reddit, but to see it again blogified!


    Any chance we'll get a blog post on the details of the signal which is replacing feed delay for these?

    As always, thanks for sharing your awesome work!

    ReplyDelete
    Replies
    1. Thanks! The tach signal is the standard SimonK MOTOR_DEBUG signal.

      I do plan to post about speed-based single trigger control once I finish fixing the S-Core firmware which is currently a construction site, but each wheel's tach channel gets an external interrupt pin on the AVR and a pulse capture ISR. The speed command being sent to the drives is also converted to a target tach period to be used in the fire control. From there, the control logic is extremely simple, just wait to be receiving tach signals from both drives, then for the speed to become in-range on both drives, and then fire. There is a timeout, normally set to about a second after which the shot is aborted if the speed cannot be reached. There is a margin for considering the tach in range as the only real user setting and the means of compensation for the bolt cycle time, which currently is linearly interpolated between endpoints based on speed setting sort of like the FDL Min...MaxSpin for feed delay. I stuck an alpha of the whole thing up in a post here today but it's godawful. Nevertheless it works - "hold onto one flywheel and pull the trigger" is the usual demonstration. If you let go of it within the timeout, it spins up and then fires a full velocity normal shot. If you don't, nothing is fed, and no jam is caused.

      Delete
    2. Update about that firmware if you wanted to see: https://drive.google.com/drive/folders/1OArnckT9l61k8u-qP2vKwLdozlNQnKL-

      Delete