Friday, May 8, 2020

T19E1: Product-improving the T19 system

T19 really needed some TLC. Some had already happened, such as the new stock parts, but multiple things had stacked up that needed addressing:
  • Motor options currently extant needed multiplexing across the long and short barrel cages.
  • The now tested Racerstar BR2207S variant of the Delta (long barrel) cage and associated parts needed releasing anyway.
  • The short barrel (Gamma) cage just needed to be totally redrawn.
  • Short darts needed to be tested and natively supported, and one project to do that created a short dart breech and began evaluating Talon mags.
  • Electronics were, but eventually stopped being, in flux. The S-Core 1.5 board mounting pattern then needed to be added to the drive housing.
  • Top rails needed attention. A sourcing issue with the original part showed its ugly head and the rapidly multiplying number of cages and breeches also now required an extensible solution.
  • Everything needed to be reorganized, deprecated part versions axed, and everything concisely released.
  • STEPs needed to be generated for all old parts for which they were missing.
I started on this with the shorty breech and top rails, then the cages, and it ended up becoming a major cleanup and restructuring and a lot of small tweaks to the majority of parts.

The Gamma Major cage was totally redrawn (revision 3).



Emax RS2205S, Racerstar BR2207S and Turnigy V-Spec 2205 are now supported for all cages.

A blank version of the Gamma and Delta mains with all non-motor-relevant features in place have been created, for speedy and easy motor deployment by me, and there is a STEP of each blank for DIY motor options (You will need to design a flywheel and pick or mod the appropriate cover and associated bits).

The new Gamma features truncated groove fillers, as do all the new cages. Trimming nonfunctional regions of the groove filler, especially on the Delta variants, makes getting rotating assemblies in place less fiddly. The crown of the barrel has been radiused on all mains and covers to eliminate swelling of the corner and manual crowning of barrels. All formerly unbroken edges (mostly edges which butt up against another part to form one surface when assembled) that go on the bed when printed have been chamfered with 0.5mm to attempt to eliminate any "elephant foot" burr.

All cages have underbarrel rails as a standard feature. The Deltas have always had an accompanying rail with a nice round transition piece into the magwell front built in. The Gamma has had a rail option for a while too, but I don't think anyone has noticed its presence aside from Junior7 of CFDW who caused its creation.

As to short darts, this occurred.


This is an old school fixed speed, delay controlled, full auto only unit that was sitting around. Results were unexpectedly positive with Worker Talonmags. And what a handy sweetie little gun.


The formerly prototype short dart breech has been adopted effectively as-is as it needed no revisions. Elephant foot prevention has been added, new top rail bolt patterns have been added, and the new stronger 6 bolt breech flange pattern is also supported (note upper bolt holes). The flanges on this newly designed breech have been thickened versus the old full length part. A partial depth counterbore is provided on the lower bolt holes where the bolt head is exposed, for the primary purpose of full depth thread engagement with an off the shelf fastener and secondary purpose of having the bolt heads be less protrusive.

Uses the stock bolt. The fact that the bolt stroke of the stock 19 drivetrain with this puts the bolt tip almost into the flywheels might be a factor in reliability - the bolt occupying the space where a round just was at the top of the mag would help prevent stack tilting, and the excess motion would help to drag the rounds backward on the return stroke and keep dart tips from scrubbing on the front and sticking. So care will be taken if destroking the drivetrain is ever a factor, to see if that in itself raises issues (it is a variable in my last unsuccessful short dart evaluations not with a T19). Any case, combat trials pending, this setup blazes through mags just fine.

The caliber marking was only there originally as an experiment on the prototype short breech to see if I could get text that small and the answer was very much yes. Decided to leave it on because 12.7x36mmK is cooler than nothing or just "short" or something.


The short breech's mag release is designed to use the original mag release spring and fit the original spring seat and clearance pocket in the drive housing.

Now is a good time to talk about remaining work to be done. The original full length breech model was lost years ago along with grip baseplate and grip panels and no clean solid models of these damn things actually exist. All of them really, really just need to be binned and redrawn.

When it comes to the full length breech, that will get an angle-cut and chamfered magwell like the shorty version, and the use of feed lip tops as the overinsertion stop instead of relying on the ridge on standard full length mags, also like the shorty version.

However, I slapped a fresh coat of paint on the original style breech (de-elephant-footing, added the extra 2 breech flange bolt holes, chamfered some stuff that was sharp, added fillets to reduce stress concentration some places, added the caliber marking, the new top rail bolt pattern, shaved the uncomfortable bit of the magwell fence on the front of the magwell) and called it good for now.


With the grip base, not much reason to redraw it just to get a cleaner solid model, but the grip panels have always been a stopgap anyway and making some nicer smoother rounder grip scales for the 19 frame has always been on the list so there is that.

The drive housing now has the extra 2 breech flange bolt holes seen in the above parts.


This and the beefing of all new design breech flanges and cage flanges is a preemptive response to the unfortunate Naptown FDL-3 incident, as although T19s were already quite rugged, this particular joint was probably the weakest in the whole system. The extra bolts help spread out the load on the breech flange and give more thread strength in the drive housing.


S-Core 1.5 board mounting bosses have been added to the drive housing. A fifth nonthreaded support is in the center to prevent board flex when plugging in connectors. The S-Core board sits lower than the original boards did giving a bit more cable space, which will be welcome on the shorty setups where inverters have to be the drive housing. Elephant foot prevention has been added to the drive housing.


It has also been added to the spacer. Some corners in the spacer internal geometry are radiused. The edge in front of the limit switch has had a large ramp cut into it to address certain roller lever switches with loose levers and a protruding rivet potentially getting hung up, which has resulted in many spacers up till this having this feature ground in by hand when a certain switch was offending in this regard.


Perhaps the most visible external change of the E1 parts is that the new top cover has continued the "edge milled off at 45 degrees" chamfer motif from the Delta parts. Transitioning from the chamfered edge into stuff that cannot have a big chamfer there (for instance, cage mains, and anything to do with breeches since there are conflicting bolt holes) is inevitably either odd looking or a bit abrupt, but this above approach looks way more natural once assembled than it does just looking at the part.


New top rail patterns have been added to the cover. The top of the cover is now slightly thicker. The pocket into the cover forming the bolt rails and crank pin clearance has been smoothed out. The back part where nothing needs to be around the rail bolt holes is left solid all the way through as it is better to infill this with the slicer than cut it out of the model.

Now for the top rails. The original AIM Sports aluminum rails used on early T19 have apparently silently changed sometime between 2017 and now, which I didn't realize (it probably isn't a high velocity item so they would have lingered in the supply chain for years before selling) but in the end, I somehow ended up with a few of the same item that are clearly a slightly different part and have an incompatible bolt pattern. So... To hell with outside vendors for rails. The aluminum rail is nice, but after testing and experimenting with printing rails, that's not a problem. 5 perimeters 100% infill.

There arises a problem from the length of a full length top rail for the Delta cage setups not fitting on most printer beds, and then a further complication is that there are now 2 cages and 2 breeches, and there may be several more cages and several more breeches created in the near future.

Hence, this system. The rail is 2 piece. The front segments are associated with cages, the rear with breeches. This keeps things simple enough to deal with.


Gamma cage front.


Delta front.


Full length rear.


Shorty rear.

As a final option, there is a one-piece 3 bolt top rail for shorty breech, Gamma cage setups only. (It will also bolt up to a Delta and a shorty breech, since the same front hole is also present in the Delta cage, but isn't full length down the top of the cage, much like Deltas with full length breeches and aluminum rails.)




This rail exists because there are existing guns which may be converted to shorty, which have Gamma cages and bricktop drive covers with only the 2 10-24 threaded holes. This retrofits those setups without changing the cage main or the drive cover. The addition of one more bolt into the breech deals with the flexibility since the rail is polymer instead of aluminum. This rail is also a fine choice for these combos in new build as it removes a part and a joint and a few fasteners versus using the 2 requisite pieces from the 2-piece rail set.

The other setups are just too long to be reasonable to have one-piece top rails for.

Here's a configuration I suspect is going to be very popular among locals for comp and I already like based on my short dart testbed setup's compact size and wieldiness.



Priorities for the future are to do proper release notes for these parts, an updated build guide, and put up some electronics bundles for sale. (Don't get too excited and don't print preemptively if you know for a fact you can't or won't DIY your control gear and you aren't local to me. I really just can't build everyone a kit. I don't have time or desire to mass produce them.) Overall what this is going toward is leaving T19 in something of a final form for when the inevitable leaned-out vertical slim successor steals all the thunder and the design attention, but that isn't to say I have any intention of sunsetting T19 even then. It has a lot of stuff left to go. Lots of motors to try out, lots of local players to arm, lots of Stryfes, Caliburns and FDLs to eliminate. 2 stage .50 cal cages are coming very soon. Conversion to 20mm Mega is also a plan just for the hell of it.

Monday, May 4, 2020

S-Core 1.5 RELEASE; build notes.

The other half of my blaster management solution:



Gerbers

BOM

Firmware (Use the latest version)


The render is a good reference for component placements:

Substitutions and second-sources should be fairly obvious.

The only really notable thing is the DRV8825 being an exposed pad package. The pad must be solidly soldered down in order to thermally connect the device to the copper on the board, which is the primary heatsink. To allow that to be achieved without reflow equipment, there is an unmasked pad on the other side of the board directly under the chip. I generally do these by applying a large amount of flux on the pad and into the vias, soldering the legs down first, then using an 80 watt Weller iron with a large chisel tip to heat and apply solder from the back of the board. The solder will wick down the 20mil vias and wet the pad quickly. Flux is critical, you cannot use enough flux. A trick when doing these is to rest a finger on the top side of the chip while heating from the back. When the temperature on top the package suddenly spikes, you know that the pad has flowed and has thermal contact to the ground planes on both sides. Give it maybe one more second after you can no longer touch it to ensure the pad is wetted, but careful not to cook your DRV8825. I do use a light dimmer on my 80 watt iron - what you want is a massive thermal capacity iron with a massive tip, not a high temperature.

There is an optional TVS diode footprint which is across the DC bus. You would want to use a device with a clamping voltage of approximately 36-40V as 40V is the absolute maximum rating of the AOZ1282.

C11 is the DC link cap for the pusher motor drive and should be a 220uF or larger low-ESR cap. C15 is the filter cap for the logic power supply. It doesn't need to be and perhaps even should not be a low-ESR cap as this results in a larger inrush spike and stresses D2 more at power-up (not that D2 is not specced to handle that anyway). I have specified the appropriate varieties of caps in the BOM.

To flash these, plug in your USBasp or other AVR ISP device to the 6 pin ISP header, open the firmware in Arduino IDE, select Arduino Pro or Pro Mini (ATmega328P, 5V/16MHz), select "Burn bootloader to board" (which is just a convenient way to initially set the fuses; the bootloader itself is not used and will be clobbered by the next step) and then do an "Upload using programmer" (Shift-Upload). Thereafter for firmware updates, you can simply open the firmware in Arduino IDE, be sure that the 5V/16MHz Arduino Pro Mini target is selected, plug in and do an "Upload using programmer".

Note on setting Vref


Measure from the right testpoint with "VREF" next to it to any ground pin, DC bus ground, or a screw hole. (Do not measure between the two testpoints.) The left testpoint next to the Vref trimpot on this board is the DRV8825's onboard 3.3V regulator output.

Thursday, April 9, 2020

S-Core firmware 0.96 - fix unintended trigger trap when full auto and decelerateBoltToSwitch() (etc.)

https://drive.google.com/open?id=1cRn7ZAxHbe2abdRy1m3IFjliANBaALVl

This fixes a bug in which


  • firing full auto
  • releasing the trigger momentarily overlapping with a trigger polling event, thus initiating drivetrain deceleration in preparation for firing to end
  • pulling the trigger again during the deceleration

-would incorrectly be trapped by the disconnector and do nothing until the trigger was reset, as if it were a continuing trigger-down state after a burst or semi shot has been fired. This little death slot could be found when thrashing a blaster with "stop and go" type input on full auto. Plenty of players may make inputs like this, including me, under pressure.

Wednesday, April 8, 2020

ESC Project: ACE-LC v2.0 ("ACE 2") - RELEASE and Build Notes

Gerbers

BOM of my exact build (generated by Digikey)

Component list with most generic/second sourcing info

2oz copper is required.

Most everything is quite obvious. However, due to the packing density, the silkscreens tend to be unreadable (at least on my batch of boards) for a lot of the passives. Hence these images may be helpful for quick reference:


Front side has 2 100R gate resistors R7 and R10, the sense network comprising six 18K 0.1% resistors R17-22 and three 3.3K 0.1% resistors R23-25, and 3 MCU decoupling caps C1, C2 and C9.

Note that there is an option for decoupling capacitor C9 if you want to overengineer this by using a 1uF to have a typical wideband decoupling network with caps an order of magnitude apart. I have some 1uF 0805s sitting around so I have been using them there.

Also, watch out for which way those bootstrap diodes are pointing. The topmost one has the cathode pointing up. The other two are pointing down. Similarly when soldering, the back to back anodes are shorted together/the same pad on the top two so it is OK if that is a single solder mass right there, but the pads between the bottom two diodes are not connected, do not let them get bridged.

Another quick note. The low side DC bus where it comes up to the source pins through the vias - the solder mask has been removed here so these vias can be filled in with solder for better thermal/electrical performance. Similarly, on the backside, there is an unmasked strip on that bus trace, you can tin that or put a wire or bar there if you want. And obviously, the motor phase wires go on the 3 pads on the front side without vias. The ones with the vias are just ground.


Back side has logic power and high side gate drivers, the rest of the 100R gate resistors R5, 6, 8 and 9, 10K low side gate pulldown resistors R2-4, 10K RESET pullup resistor R1 and yet ANOTHER MCU decoupling cap C3 (0.1uF).

R11-13 are the ballast resistors in the discrete drive circuit, the ones that need some awareness of power rating. Those should be a 0.4W or other similarly rated part. R14-16 are just base resistors for Q1-3, the only reason they end up being the same part in my design is BOM reuse, the 0.4W 1.6K resistor is cheap enough that it is better/easier/faster to stick them there than add another part.

C8 (1206) in my build is a 47uF tantalum. This is not strictly necessary that it is either 47uF or tantalum as long as you use a LDO that is stable with whatever cap you place there. However, I recommend a high capacitance tant there to be sure about stable vcc. The C7 should be a fairly big ceramic to decouple the LDO such as 4.7uF.

After building, cleaning and inspecting, wire up your AVR ISP device of choice (I use a USBasp) to the ISP pads:


  • Ground is in the throttle cable pads.
  • MOSI is the tach pad in the throttle cable pads.
  • MISO is next to the MCU.
  • RESET is next to the oscillator.
  • SCK is on the backside of the board right under the MCU.
  • VCC is next to the regulator.

And program. Do not use KKMulticopterFlashTool to burn brand new boards, if you have that tool. It will set the fuses incorrectly. Always set the fuses to the recommended values stated clearly in the SimonK source comments using avrdude i.e.:


  • avrdude -p m8 -c usbasp -U lfuse:w:0x3f:m -U hfuse:w:0xca:m


Then flash the firmware (found HERE) and remove ISP connections.

You can use KKMFT to flash after setting the fuses correctly if you like. Also note that the bootloader allows using a USB toolstick such as the Afro or Turnigy ones over the throttle cable once a board has been ISP-ed the first time.

These are a bs_nfet board and any bs_nfet firmware is suitable, but I would strongly recommend you stick with the linked binary or adjust/modify it to your needs. A post about this board and evolutions of my SimonK variant is upcoming which will cover this, but there are a few things to consider:

  • Switching times on these are better than the ACE LC1.
  • The MOSFETs used in these have faster, pseudo-Schottky body diodes (i.e. copack, protection or antiparallel diodes). This seems to make a difference in reliable sensorless performance.
  • I recently realized the existence of loss-localization mechanisms of the single-sided modulation strategy and that there are operating points for any non-complementary PWM situation (low voltage command and high phase current) where diode conduction losses go through the roof and result in unevenly high temp on the high-side devices. I have never cooked anything, but it just isn't necessary. This affects ALL boards, including for instance, Afros. (In the future, I will design all boards with the potential of this occurring with certain firmwares in mind i.e. disproportionate and excessive high-side device heatsinking.)

Thus:

  • I run these at POWER_RANGE = 856 for stock (nominal 17.8kHz) PWM carrier frequency. They run cool and hold sync robustly and do NOT require the 10kHz that is recommended on commercial hobby ESCs and is default on ACE1 boards. The benefit of this higher frequency is mostly that the carrier is inaudible for most people, whereas the 10kHz can be heard as a distinct PWM whine.
  • The startup mode half-frequency drop is NOT necessary for maximally reliable startup and sync holding on this board in my experience. I have it left in place, but turning it off removes a tiny moment of 8kHz whine when starting up from 0 rpm or while locked-rotor.
  • I have implemented a crude but effective selective complementary PWM mode which enables complementary modulation during all locked-rotor and 0 rpm start cases while being governor-compatible. Doing synchronous rectification during these specific situations greatly reduces, and greatly equalizes, device temps, causing this board to run quite cool under abuse. This is recommended on this board and all previous boards such as Afro.

N.b.: This build supports FlyShot for variable speed applications. It also defaults, for safety purposes, at boot to a governor setting of ~35,000erpm, or ~5000 mechanical rpm with 14 pole motors. If you have a fixed-speed application which doesn't support FlyShot, change the value at line 3351 (high byte) and 3352 (low byte) to the speed setting you want to run at. The governor setting is in TIMING_MAX * 8 format, same as what is sent in FlyShot frames.

Then install the DC link capacitor, DC bus input and motor phase wires and a signal cable. Here is a typical assembled unit:


Shrinkwrap this, ideally with PVC or PET shrink film tube (battery pack wrap or "layflat tubing"), being sure to support the capacitor with it to prevent flexing. I think what I have been using on most Afro-sized ESCs for shrinkwrapping is 40mm flat width, for reference. Leaving the board bare is inadvisable! Insulate it with something.

Tuesday, March 3, 2020

T19: Stock assembly revision 3, inverter cover minor printability fix, randoms.


A few product-improvement variety tweaks to the same old stock design that had been deferred since the early days.

One, I bothered to make a curved buttplate for it. Fits all T19 stocks.


Two, switch fences have been added.

I have never accidentally turned my blaster off in combat, but that would not be good.

This is a traditional strategy for guarding switches to prevent them from getting bumped and moved accidentally.


Three, the front edge of the stock body has been chamfered.

And four, the stock body and base have 10-24 counterbored SHCS holes to secure the 1" PVC buffer tube. Insert tube, align stock and base, mark/drill, tap, install fastener. No more friction only nor permanently Devconned stock assemblies where you replace 3 parts if one gets broken or you want to upgrade or mod one.

These inverter covers always had some trouble printing cleanly:


Take a close look at that bottom edge - it doesn't immediately look like a problem, but the fluting comes across the edge at a low angle and the resulting geometry FDMs only slightly better than flaming garbage. These always got some attention from a razor blade afterward and still tended to look like shit and have a horrid jagged edge. Drove me up the walls for over a year, but it's sometimes difficult to bother with minor things like that that have zero bearing on function whatsoever.

Now, there could be a lot done to smooth and de-brutalize the architecture and these covers are a great example, but that's not the idea here. I will do something to that effect as part of a larger remodel that is not strictly part of Model T19 at all, but T19 is what it is, and is going to continue being brutalistic.

Don't like it? Rant time. Design your own mod bits for it or reshell it yourself. I'm not your CAD slave.

The more flak and the more barf emojis on poisonous Discard channels I get about my style from certain toxic individuals who do not design blasters of this sort themselves, attempting to demand that I change my ways for them when they have no interest in running my equipment anyway; the more I shall stick to the brutalism - especially as locals who actually handle and shoot and look at these in person and are my actual customers as a designer besides my own use do not agree given how much demand I am getting. Let's make this clear, I have no tolerance for politics, and no tolerance for assholes, and trying to "community politic" me or being an asshole to me is not going to get anything whatsoever out of me especially when it's about something totally subjective.

The level of entitlement some people have in general toward open hardware/open source designers across the community who release ridiculous amounts of work for free is astounding. I know many of the same crowd dissing the 19 also attacked FDL Jesse for the FDL-2, do not try to deny that shit, and I know he was NOT happy about that either, and you should be ashamed to be a thorn in the side of multiple designers. Rant over.

Printability fix.


Straightforward matter of stopping those two fluting "toolpaths" a bit short to not bust through the edge. Problem solved.

I also started doing printability experiments with various orientations and types of 3D text/graphics on my setup/materials. I have always thought a lot of designers went over the top with text and logos and greeblies, and so I have long resisted spewing badges all over mine. One thing I will ALWAYS do is to release a complete set of badge/text-free part files for every blaster. But I at least want to know the limits and the results of printed-in badges, for more subtle and boring things like model/serial/build date tags if nothing else. So time to do some test parts.


I had had this DIRECTDRIVE badge thingy in mind for a while and it tested both positive and negative text oriented on the side of a part ortho to the bed, and it has some big horizontal overhangs and some fine little features... Good stress test.

Then there's this one:


Tacky and OTT perhaps, but at least one of my personal Things needs a proper snipe at DC motors plastered on the side. I have fond memories of a certain rental Yale reach truck at work that was, like my blasters, fully brushless, and had (you guessed it) these big, tacky, over the top AC POWER badges. These covers make a good test case for bridged negative features facing the bed, and are the most likely place to put "nameplate" type stuff. A lot of people do it on FDL-3 sideplates, but the outside surface on those is a top layer.

Liking the results of both. Pretty much as it came off the machine, haven't even picked out any strings or blobs yet...


I'm surprised how well printing this doesn't fail. Sometimes, FDM is PFM.


And these come out nice and sharp too. Be mindful of elephant footing if you're going to do these sorts of things. Would really look nice as a multimaterial, obviously, if you wanted to do something less subtle like put your username there.


Silly stuff mostly. But the resolution is better than I expected and could easily resolve smaller text.

Wednesday, February 26, 2020

S-Core Firmware 0.95 - Home bolt with flywheels turning at low speed; more robust and snappier speed-based feed control.

Link

Changes:


  • Home bolt with flywheels turning (at default low speed)


The previous selftest routine reset the bolt at startup with the flywheels stopped. Occasionally, such as in the case where a stoppage or debris is present or the bolt is not homed but a loaded mag is present, this would mash something into stationary flywheels.

Now we wait until after the flywheel drive rotation check and run the wheels at low speed while homing to spit out anything that is accidentally fed. If something is fired inadvertently during this procedure, it is barfed out at about 36fps, so this is safe - assuming you have an ESC firmware with default minimum speed, which you should.

  • Improve speed-based feed control

A series of consecutive in-range tach readings (the number of which is still a build-time setting) are now required to initiate firing. This removes most possibility of enough randomly in-range pulses being received during the timeout window to fire when a drive is not actually at speed. This might happen during a stall condition while tach pulses may be clipped by start timeouts and/or there may be motor vibration which is capable of creating in-range tach pulses.

Offset margins and such have been revised slightly and control is a good bit snappier. Some perturbing of these settings may be called for to fine-tune velocity consistency, but it shoots pretty damn nicely with my Emax equipped primary.

03-04-20 Update: I have hotfixed some configuration parameters in this release. Posted as a Google Drive version, so should be transparent.


  • Set maximum flywheel RPM back to 25,510 since 26,000 is a deleterious overspeed for the Hy-Con and resulted in a decrease in mean velocity and an increase in velocity spread.
  • Make STC settings a bit more conservative since while it got consistent velocity at 50/25, how I had it set may have been edging toward not getting max velocity in lieu of snappiness in a few cases. This does expose the SimonK mid-speed transient response bug more as a slightly more delayed followup shot at certain speeds, but that's OK.

SimonK FlyShot (digital speed command, closed-loop) - Default to safe minimum speed on boot, etc.

Code (plus a precompiled bs_nfet.hex for ACE discrete drive and Spider boards, etc.)

Now defaults to ~35,000erpm (~5000rpm with 14 pole motors, or about 36 fps root speed on a standard Hy-Con) at boot time.

Also, the safety governor (safety here being from the ESC's perspective, meaning avoiding exceeding the frequency limit of the inverter control loop) has been set back to the stock TIMING_MAX = 0x0080 (312,500erpm) in this so this is now universal to high speed applications out of the box whereas me leaving it at 0x00e0 in the last one may have "gotcha'd" someone.

/u/matthewbregg had a good suggestion in this thread about defaulting to a low speed. I had been considering this type of feature, but this thread got me thinking about safety and failsafe control a bit more in general. Thus this, and the new velocity watchdog code on the S-Core's end.

It really makes sense just in general that a closed-loop drive doesn't try to spin to the moon if you haven't informed it of what speed it should go... Makes sense, right?

Some setups (very large wheels and high-velocity multistages in particular) could even conceivably be mechanically intolerant of overspeed. With ordinary BLDC configurations, that wouldn't happen, because the battery and motor kv would have been selected to avoid that, but with closed-loop configurations that are trying to have stiff speed regulation with a lot of available torque at some operating speed, it may very well be that there is enough bus voltage that reaching hazardous speeds and blowing shit up is possible if uncontrolled. My previous idea was that one would just set TIMING_MAX to an appropriate safety governor setting which removes the need for a default low speed in that regard, but in general, flashing ESCs to configure them is a pain in the ass and it is better to make a drive firmware be universal and live-configurable over the wire.

Bregg also implemented a version requiring identical FlyShot commands to be sent twice to apply a speed update, and this is a most excellent addition for applications that do not have speed feedback and cannot selftest their flywheel speeds, like most Ultracage setups and FDLs and whatnot. These variants are also compatible with my gear by nature, but the above code doesn't have that feature because I want a higher speed update rate and smoother speed adjustment when live-adjusting speed and it is not necessary to be that overzealous with speed feedback present. In any case, just like Dshot commands, one-time FlyShot commands should always be sent about 10 times anyway as a matter of course.

Wednesday, February 19, 2020

Hy-Con Delta Cage released - Long forend, support for Emax RS2205S.

With the Turnigy V-Spec getting scarce, it is time to option more motors. I also had some requests for longer barrels and more rail estate on the T19 platform.

Bird 1 and bird 2, let me introduce you both to this stone. Hy-Con model Delta:



All STEP and mesh files



This is equipped with a new motor option, Emax RS2205S. This, like most drone-market motors, is a threaded shaft motor.



It is widely available, torquey, not too expensive, and very axially short, which removes most of the bulges/stuff sticking out annoyingly that tend to be problems for thin-packaged horizontal cage rigs when transitioning over to threaded shaft motors from bolt-pattern motors. There are just some ~2mm tall hole plug heads on the bottom of the cover. These plugs result from keeping the old school cover dimensions, no real reason or rhyme to why I did it that way.


I do have plans to multiplex things a bit more between cage variants and motor options as I test and add more, but the Gamma Major short barrel cage really just needs a clean sheet redraw and some more polishing anyway. So for now, it's Gamma/Turnigy or Delta/Emax.


The wheel, being that this is a threaded shaft motor, has some new features.


Locating keys specific to the Emax are provided to fit into the rotor notches and allow the shaft to be held with the wheel for initial torquing of the nut.

This is a rotor OD piloted wheel and the shaft hole is a large clearance on the shaft to avoid overconstraint as usual.

A slight counterbore is provided to match a raised boss around the shaft on the rotor of the Emax motor and give full surface contact.

The ring of tiny holes is a toolpath control/selective infill feature to force the slicer to generate solid plastic in the web where the clamping load is applied.

A printable washer is used under the shaft nut to account for surplus unthreaded length. The web thickness is not increased unnecessarily (Ultracage) to this end as this has no structural purpose and adds a lot of inertia that might best be made optional. (Still, with how these run, I might slice wheels for them to add some more inertia anyway in the future.)

There are no left-hand threaded versions of this motor and they come with nylon insert locknuts, so don't go looking for a "CW and CCW pair" of them.

As per my usual design approach, this is a nonventilated wheel design. Excessive motor temperatures have not been a concern whatsoever.


I am not putting up anything except 9.5mm gap wheels with this and going forward. Closed-loop speed control completely removes the entire issue of "subcritical speed = bad" - subcritical with stiff speed regulation is actually a route to world class velocity consistency. The 9.5mm wheels turned down are easy on darts and very consistent.

Rails: Self explanatory.


Overall I am satisfied with the Emax RS2205S. It delivers a slight improvement in flywheel drive response versus the old Turnigies (which on the new control gear is automatically translated into a reduced feed delay without changing any settings! So much nicer than manual tuning) and is another, and more solid/trustworthy than the Turnigy, option but I don't quite like their "personality". They are modern, and aggressive, with N52 arc magnets, and tight airgaps. With so much field flux, the cogging torque is pretty gnarly, and they feel and sound more harsh. (They don't coast as well either - adjust your driveCoastTime down a bit if you have old world controls.) It's much like 3240s vs. XP180s in the old dark DC days. Sure, the latter has more torque and is objectively better, but the former feels... Happier. Same here, which is why for further motor options I am going to include some other motors with more Turnigy-like magnetics. The Racerstar BR2207S is one I already have on hand which is a sweet amazing sounding runner, and I will also be testing their BR2406S and perhaps BR2306S as all of these are cheap and plentiful.

Sunday, February 16, 2020

S-Core new firmware features: power-on selftest, flywheel overspeed detection.

Link up front

The source is the best documentation for the details, but selftest is very much no longer a placeholder. Overview of all checks in order:

Bolt drive system

  • Verify that the bolt can be homed as determined by the limit switch within one revolution. Issues with the limit switch fail, as do a drivetrain that has locked up/jammed with FOD or become disconnected from the motor, and inverter failure or an unplugged motor (obviously).

Trigger input

  • Verify that the state of the complementary trigger inputs is a valid high/low or low/high state corresponding to a switch up or down position, rather than a high/high or low/low state corresponding to a failed switch, a short, or a bad connection.

Flywheel drive system

  • Verify at least casually, without using interrupts, that tach lines sit at a stable logic state while motors are undriven. This avoids a race condition risk that is posed by enabling external interrupts if the tach line may have become connected or coupled to a high-frequency noise source or signal that was not anticipated.
  • Verify that each flywheel drive emits tach transitions within one timeout period when throttled. This catches drives that have become unplugged, don't have power or otherwise are totally inop or absent.
  • Verify that each flywheel drive can spin its motor past a minimum speed and keep it there for a minimum number of check cycles during the timeout. This finds seized motors, and typical single-phasings and partial inverter failures that may still move the motor but can't actually drive the motor to any speed.

Closed-loop speed control integrity

  • After setting and locking down the speed prior to entering normal operation (either by defaulting to the current tournament lock setting or by exiting the user speed configuration mode), spin up flywheels and verify that, within a timeout period:
    • No single tach periods indicative of critical overspeed events occur.
    • The noise-filtered speed of each drive falls within margins of the speed it ought to be set to for many consecutive check cycles.

Combined with an ESC firmware that defaults at its own boot to a very low speed setting, this one boot-time check renders some unforeseen signalling issue, drive reset or bug causing considerably hot velocity effectively impossible.

To report the results of these self-checks when they fail, the familiar construct of "fault codes" now shows up here. These consist of a "major" and "minor" component and are organized approximately by fault category or subsystem.

The stepper motor is conveniently useful as an audio/tactile feedback device. It is used to emit a (not too loud) alarm, then blip out the fault code responsible using "growls" (familiar to anyone who has turned on an old T19): first major, then 700ms of silence, then minor. Both values are always to be greater than 1, and I prefer that they be less than 9 for brevity.

So far there are only codes for selftest failures or drive overspeed events, codes do not persist past the current boot, and all faults are also terminal and disable operation, as all of the current ones in a strict sense render operation either impossible or potentially unsafe.

The center blaster below is running this code right now and it is effective and solid.


This image was at CFDW. The lower left-hander blaster with the rail on the cage is Junior7's unit which I updated the firmware on at the event (to 0.8) and swapped out the selector switch (more on this switch later). I haven't posted that build in detail - it's a 221 with S-Core 1.0, ACE LC1s, Turnigy Vspecs, a lefty stock base, lefty auxiliary controls, plus an underbarrel rail and one very long mag release that he wanted and filaments are Atomic marble, Atomic translucent aqua and Yoyi translucent orange.


Same blaster's print kit before assembly.

Friday, February 14, 2020

S-Core SBBM v1.5

The original S-Core did its duty as a dev mule, but it's time for a "production" board for both me and other people to use.


Changes:

  • Delete the solenoid driver - It is decided. Steppers are NOT going anywhere.
    • Solenoid-driven magfed applications are going to get their own, smaller, simpler board. If a coil driver is needed at the same time as the DRV8825, that can be something plugged into the GPIO connector.
  • Switch pusher motor DC link cap and logic power supply filter cap to through hole 10mmOD electrolytics - No more SMD lytic hassle. Also, cheaper, and many options of lower ESR which matters for the former.
  • Fix inductor footprint near AOZ1282 for easier soldering
  • Fix MCU ceramic resonator footprint for easier soldering
  • Put all components on front side - Does it matter? Not really... There's through-hole leads sticking out the back for all the headers and such so you can't whack it against a flat surface anyway without some standoff but it felt right to do this. When I do the mini version, this likely won't be the case.
  • Add mounting holes
  • Replace cheesy little Bourns TC33 trimpot for tournament lock with a Bourns 3362
  • Replace DC bus wire pads with wire holes plus 2 pin 0.1" connector footprint for options and better wire management in-blaster
  • Add TVS diode footprint (SMA package) for DC bus transient overvoltage protection (opt.)
  • Change BOLT connector to 2 pin
  • Change GPIO connector to 4 pin (adding pin formerly eaten by the solenoid driver)
  • Add ISP header pinout legends (Not shown in the above render)
  • Add motor drive pinout legends (Not shown yet as well)
  • Improve MCU decoupling
  • Via stitch front and back ground planes generously and improve ground connectivity/impedance to everything
  • Circle VREF test points in the silkscreen, if they needed to be any more obvious
30x75mm. 2 layer, 7/7mil, 1oz. Minimum drill 20mil (I use large vias by habit) Should be easy stuff to get made by any vendor.

Monday, February 10, 2020

S-Core firmware 0.8 and new feature overview.

This is the firmware these new blaster manager boards run.

All the important (um) core functionality is there and solid - the main bit left to work on, really, is just doing a proper power-on selftest now that we have the hardware capabilities to. Beyond that, it's mainly a matter of implementing alternative UI behaviors that I or anyone else wants.


So into all the new stuff.

- Implementation of FlyShot protocol; integration with adjustable-speed flywheel drives


The protocol described in this post is implemented.

Support on the motor controller's end is required. This may become a compile time option, but in general, avoiding ESC reflashing and setting speed over the wire from the blaster manager's end is easier and more flexible, even if you program your blaster manager to set a fixed speed only.

- Implementation of speed feedback-based feed control (=closed-loop single-trigger control. CLOSE ALL THE LOOPS!!)


"Blind" feed delays/delay scheduling approaches to account for motor acceleration with no awareness of actual wheel speeds are so last decade and really needed to go, just as much as open-loop voltage command flywheel drives needed to go. In particular:

  • Scheduled delays require tedious manual tuning to closely match the dynamics of a given flywheel/drive system and produce snappy shots, but consistent velocity, under a variety of conditions. Oftentimes they get just "Meh, good enough!"-ed to the generous side by a builder who can't be bothered squeaking every millisecond of latency and every fps out of the damn thing - including me.
  • Scheduled delays cannot, obviously, react whatsoever to unanticipated variances. This could be anything from a change in DC bus voltage and sag due to batteries not being ideal and varying in voltage and IR with SOC and temperature, to a barely noticeable desync event during a spinup that slows it down slightly, to some debris stuck in a cage or cold grease in a bearing causing friction on a wheel, to an outright jam or other situation where a wheel fails to turn at all.
    • Thus, delay settings must be conservative to cover the vast majority of these variances.
    • Also, thus, scheduled delays will completely fail at their job in more severely unexpected situations - by feeding ammo when it would produce a crappy shot, or by feeding ammo when it is completely inappropriate to feed and causes or worsens a stoppage!
To this end, tach signal (the format generated by SimonK MOTOR_DEBUG is what is expected here) from each motor drive channel is now used to control feeding based on actual motor speeds.

This not only greatly improves robustness against unexpected conditions, but renders the system 95% self-tuning, since the whole issue of predicting drive dynamics with math and/or multi-stage delays is fundamentally sidestepped. Plug in ANY motor, ANY controller tune, ANY flywheel inertia, ANY drag torque (cooling impellers and whatnot) - Doesn't matter one bit (well, as long as the drive is capable of reaching that speed at all). The feed delay optimizes itself on the fly for each spinup.

The main control logic is also extremely simple. Simpler than scheduled delays.

There is only one set of parameters left to adjust - a speed offset margin, which is a margin of error within which the speed is considered to have reached the setpoint. This accounts for achievable flywheel speed control loop performance, and it also provides a means of compensating for continuing wheel acceleration within the mechanical travel time of the bolt; while still reliably inhibiting feeding if the speed is out of range enough to produce a tangibly wonky shot, let alone is grossly unsafe to feed at. In this version, a linear (which is perhaps not the correct curve to apply, but whatever, works well enough) interpolation is provided between endpoints based on the current speed setpoint - for which the idea is to account for the greater torque and thus acceleration available from a real drive at lower speeds.


- Implementation of flywheel speed limit (tournament lock) with secured board-mounted potentiometer (i.e. requires tools to access)


This is self-explanatory.

- Implementation of user analog potentiometer and selector input devices


This is self-explanatory. See selective fire discussion below.

- Implementation of user speed configuration from minimum up to tournament lock setting


At boot time, if the trigger is not down, the blaster defaults to the tournament lock setting.

If the trigger is down, the blaster enters speed configuration mode. The flywheels spin continously for audible user feedback of the speed, while the analog knob varies speed between minimum speed and the tournament lock setting. Releasing the trigger enters normal operation at the current speed setpoint until the next power-up. This avoids accidental speed changes.

- Implementation of selective fire


Can you hear the crackling of ice forming? Because hell might be freezing over.

Yes, I put a selector on a T19.

This was motivated by a few factors:

  • Popular demand. T19 has started to gain traction among locals as a platform - some of them are not full auto natives.
  • Future flexibility of having the control itself - we aren't just limited to selecting burst modes! What if we want to select profiles that also contain speed, ROF, and offset margin ("snappiness level") combinations for various situations? But there is a lot more than that under software control. Maybe we could have a HvZ stealth mode that sets a low wheel speed, limits the voltage command of flywheel motors to hush the magnetostriction under high motor current on startup, sets a moderate ROF so the bolt doesn't go clack when it cycles, and sets 1/16 microstepping to quieten the bolt motor? Well that can be done now. If I have a need for something like that, I now have enough UI means available to turn it on and off. That's a way of justifying what I long saw as a superfluous control.

Straightforward - the logic is like a firearm's disconnector implemented in software and has the same behaviors as such a mechanical device. There is no paintball-style shot buffering/queuing mechanic, and I don't personally think there ought to be, although if any game organizer starts to push semi-auto-only rules I am totally open to implementing that along with 2 finger triggers!

Something to note is that I still have true full auto. Full auto is NOT a 99 or 999 shot burst (FDL, for instance). For each selector setting, there is an index in both a boolean isBursts and an integer bursts array. The first one is a mask for the disconnector and if that index is 0, the burst disconnecting logic is completely out of gear and it will fire truly ad infinitum. Does that practically matter? No, not at all.

Stock modes are full auto, 2 round burst, semi. I get a lot of demand and a lot of positive feedback on the 2 round burst.

- Implementation of live ROF adjustment


During normal operation, the analog knob sets ROF between the configured minimum and maximum at compile time.

ROF adjustment is linear, ROF adjustments take effect immediately at any time during the idle state (not firing), and ROF range endpoints are now configured in RPM rather than obtusely in microseconds per subcommutation. There is still a strict reliability limit to be set per-motor (88uS for the usual OSM 17HS16-2004S1). If you want to run it up to there, just set the maxROF a little beyond there.

ROF is a maximum bolt travel speed adjustment, and applies to all fire control modes at all times. Thus, it allows both changing the cyclic rate of fire, including for bursts, and changing the bolt speed and force (inversely related) - not that crappy ammo usually poses any problem in the field even at max ROF settings.

Sunday, February 9, 2020

S-Core 1.0, a somewhat-preliminary single-board blaster manager.

The Google Drive directory


This is my first crack at getting rid of Arduinos, perfboards, DRV8825 carrier boards, hand wiring and off the shelf 5V converter modules and replacing all that noise with a single PCB. Done around Aug-2019 and since then I have been running a couple of these.

This has an Atmel ATmega328P MCU, an AOZ1282 5V supply with the input filter from a recent post, an onboard tournament-lock (speed limit) trimpot, and inputs for a SPDT center-off selector, an analog pot knob, the bolt limit switch and the SPDT trigger like any other T19 and all of these contact input lines have the usual proven 1k pullup to vcc and 100k protection resistor going into the MCU pin. But the elephant in the room is the TI DRV8825 stepper driver and all its supporting componentry including a Vref trimpot, Vref testpoints, DC link cap, and current shunts. There is also an open-drain "single ender" solenoid driver that takes a DPAK (designed at the same time as the ACE LC1...) mosfet on this board - though I haven't used that for anything I would put this in yet. 2 layer 1oz copper, pretty undemanding stuff.

Gerbers

BOM (generated by Digikey)

Firmware v0.8

A Reddit thread about this

These are solid and do what they ought to. They have great thermal performance for the DRV8825 and run it cooler than Pololu boards do.

Misgivings are numerous!


  • I used a nonstandard motor drive signal connector pinout with 5 pins. Back when I designed this, I was not settled on where logic power supplies were even going to be physically located in a blaster - so these are: ground, NC (where BEC output is on old RC ESCs), throttle, tach, 5V (so far always NC on ESCs). Of course only 3 are necessary. I have settled on 3 pin with ground, tach, throttle as a pinout now after modding a few Spiders for tach with cables wired that way.
  • The ceramic reso and AOZ1282 inductor footprints are default ones too small and a massive pain to solder. The reso's alright, but the inductor is a bitch. Ok for reflow, but dumb layout for a hand-solderer. Needs a bit more area on the pad edge to heat from and it's OK. Lesson learned.
  • I discovered machined-pin headers: 2 pin connectors are secure if you just use good headers and not cheap ebay ones for the female side. The bolt limit switch can be a 2 pin.
  • There are no mounting holes since I opted to have a very fast cheap to print board bracket in the 19 instead. But for futurestuff that might be slimmer than a 19, I want either holes in the board or provision for slide-in mounting.
  • SMD electrolytics - again. Another pain in the ass. Lesson learned.
  • Looking back, my MCU decoupling was a bit meh (there's a via in one of them and the other has some trace length), but better than most commercial stuff and these never reset or glitch out.
  • The solenoid driver just needs to GTFO. There should be ONE OF a noid driver OR a stepper driver OR a third throttle channel on a given board. I actually put that in because I was expecting to use these in a HIR project where there would be a small noid for the feed gate (like in a Zeus or my old hopper loaded thing) and the DRV8825 would be running a feed roller motor. But that's probably best left off, and made external/piecemeal for such a very special rare case. It's deadweight in a 19 and in a solenoid-driven blaster, the 8825 is deadweight. Those apps need separate boards. Plus I think I would use a halfbridge in a dedicated hi-po solenoid drive board today instead of a single-ended powerstage so that decay mode could be fast if that is worth anything
  • Layout could be tighter.
  • Those Bourns TC33 trimpots. These are same the tiny, tiny, stamped sheetmetal/ceramic, things found on DRV8825 carrier/Stepstick boards for Vref. Small footprint, not hard to solder. Also found on Narfduino Brushless Micro (etc.). The one for Vref on the 8825 is fine - you use it once in a blue moon to set motor current just like the one on a stepstick carrier. But the one for the tournament lock - That really needs to be something larger, beefier, easier to turn with a small screwdriver and yet difficult to get accidentally turned from things brushing against it, accurate, and hard to break or contaminate. Like... a regular blue through hole Bourns trimpot.

Time for a brief component shopping session and a re-lay.

Other than that, MCU pinouts and hardware all good, works great, no problems. Running one of these in this:


"Crystal Patriot": Yoyi translucent red PETG, Yoyi clear (translucent whitish in a thick part) PETG, Yoyi translucent orange PETG for the flash hider and auxiliary controls, Inland/Esun trans. cobalt blue PETG.


Of course to go along with this there is a selector and an analog knob added as controls on the blaster. I put up the modded grip base and the knobs as well as the S-Core board bracket (glue the board in). This is the potentiometer and the rotary switch used (wire as SPDT center off). Can't beef with either, particularly the rotary switch, which gives a very solid and satisfyingly clicky selector.

Saturday, February 8, 2020

Another in process ESC project with Infineon 6EDL04 gate driver.

This is still more under construction than the LC 2, but it's in the pipe as well for the next big PCB batch. Working name ACE-NX.


LFPAK56 power stage. 25x46mm 2 layer board, same dimensions and a lot of structural similarities to the LC 2.

Infineon 6EDL04 gate driver (6EDL04N02PRXUMA1) - Datasheet. Cool, huh? The overcurrent trip will be an interesting feature to hook up and try out sometime later as well, could help to increase the bulletproofness further, but this one doesn't, the idea here is straightforward and simple.

Power supply is usual trusty ST L5150BN LDO for the 5V and AP3012 boost off the 5V rail for the +12V gate drive supply. The SOT-223 linear and then an AP3012 feeding the gate driver is a standard setup to get a stable gate drive rail, a lot of BLHeli_Whatever things with Fortior drivers have something to that effect.

I haven't seen anyone else make use of these Infineon EiceDriver chips yet. I have seen plenty of IR2101s and similar, a few FAN7888 projects on RCgroups, and a ton of Chinese drone stuff with Fortior FD6288. The 6EDL04 caught my attention for being a smallish TSSOP package and having integrated bootstrap diodes.


The Fairchild FAN7888 and Fortior FD6288 are also among the candidates leading up to me picking the Infineon, but both require external diodes, the Fortior is pure Chinesium (I literally cannot find a datasheet that isn't in Chinese) and not the easiest to get shipped quickly and reliably in the US and the Fairchild is a large SOIC package. There was a promising MPS MP6531 found by RCgroups user AlkaM which goes a step further and includes its own buck/boost gate drive supply onboard, but that one has availability issues and is also an exposed-pad package which is alright but a tad annoying.

The Infineon and AP3012 almost package better than the discrete drive setup! Killed quite a few components and traces. If I wind up liking the results of these, discrete drive may be on the way out of my designs.

Pinouts on this thing are bs_nfet except that obviously, the high side drive is NOT inverted like it is with the discrete drivers. A board definition is going to need to be created for that, probably called ace.hex. Perhaps later on it will be prudent to swap some pins around in the board def for better routing between ICs if the 6EDL04 setup works nicely.

This will obviously be able to run some extremely beefy mosfets that have larger gate charges with the added gate drive grunt. PSMN0R9 is what I have in mind.

More on discrete gate drive ESC boards; logic power filtering; a 2 channel drive project.

This is something I have cooking:


A 2 channel controller with some specific layout/wiring features. This is targeted at restoring SimonK availability to the FDL-3 (including closed loop adjustable speed developments and whatnot, if desired) and ...at least providing some insurance that they don't HAVE to get their ESCs yanked out from under them again in the future - even if most people keep using COTS BLHeli_32 stuff in their setups for the time being. This version is a discrete drive unit, with LFPAK56 devices.

You can also see the SMPS down there on the right; it's an Alpha/Omega AOZ1282 1.2A output, 36V max input buck which I have found to be a cold running, solid little setup on my S-Core boards. That ought to handle all the logic power requirements (all of which are 5V) in the blaster with some current to spare and run cool enough.

Speaking of the devil logic power supplies in blaster systems...

That has always been a point of intense worry of mine, having had some bad experiences early on (and who HASN'T had a frustrating random-reset gremlin at some point?) and although the culprits were a number of other bad things I was doing and stock ESC firmwares were doing at the time, that led me to insist on SEPIC/buck-boost regulators to power blaster managers for the longest time - the idea being that during some horrible bus sag event or negative noise spike, you have a tad more input voltage margin. What led me to reconsider was realizing a few key things:

  • Most SEPIC regulators, including ones I used with success, can't actually run down to less than 4.5V or 4.0V anyway. It's a big reg selection, footprint, and cost constraint over... what, half a volt? A volt? A volt and a half of margin gained, absolute max.
  • Holy hell, if the DC bus in something DOES ever have more than -10 volts of peak noise, there is a Very Serious Problem going on, and other things like mosfets exposed to that are probably in danger. If there is more than -10 volts of SAG on a longer timescale, that's also a battery that is completely and utterly incapable of powering the load (or maybe mistuned inverters trying to commit suicide with a kabillion amps).
  • My ESCs are running on linear LDO regulators without that filter with good success. Never a random reset.
But once burned, twice cautious. Hence this circuit has made it into a few designs, including the S-Core and the current state of the above board:


Note D7 and C16 on the input - this is a negative spike filter of the sort recommended in the datasheet for my favorite LDO linear, the ST L5150BN (which is an automotive-targeted part). The big Schottky diode prevents any negative pulses on the input from sucking charge out of the cap, and the cap caches a bit of sag ride-through energy to use during such a transient. There is a bit of forward drop on the diode but it's a Schottky so not much.

Is it necessary? No. I can say that pretty solidly - all my ESCs, including ones I designed, don't have any such filter. Good decoupling on your MCUs, big enough 5V rail bulk caps, and making sure all motor drives have the proper DC link capacitors fitted does the trick so well that not even an ancient and empty 3S pack causes any resets. But it's peace of mind if this filter fits, and it costs like $2.50. Watch out for inrush current into the cap. Beef the diode, or else do something to mitigate the surge when switching this on. That's why the diode shown is a beefy SMA part rated for Ifsm of 100A (which appears to be enough).

Something interesting is that this circuit is effectively a high-powered version of a peak detector. Could that make a DC bus overvoltage transient more dangerous? Maybe. But momentary overvoltage spikes, if they are present, can still kill a switchmode (or any) reg anyway, so input rating headroom is important (as is trying to avoid noising up your DC bus in the first place). The AOZ1282 is rated for 36V and my go-to linear is 40V. Worst-case worrying me wants to whack a TVS diode on the input of the reg. That's what I did on the Twinverter board where that filter feeds gate drive too - or at least the footprint is there if you are concerned enough to use it. Same with the main diode in fact - that can be a wire instead if you don't want it.

Back to some gate drive matters:


Obsessive me gets to wondering about stuff like...

What is the actual high-side gate voltage level?


Looks like it might be "About what you get when you charge 1uF to the DC bus voltage minus a diode drop and a Vcesat and then load that with a gate capacitance".

Indeed it CAN be that under certain circumstances - namely, if the phase is (or is being driven) low just prior to turning the high-side switch on. This might be occurring often if you are using complementary PWM in which during (assuming HIGH_SIDE_PWM = 0) the off-time, the high-side switch is on.

But in plenty of situations, the phase would be near neutral before getting driven high by turning on the high-side switch, and that case the cap might not be charged to the full voltage.

The bootstrap cap C4...6 and the ballast resistor R11...13 form a RC network. The time constant (time required for about 63% change in voltage after a sudden step) would be of the order of 2ms (2.2 for common boards, 1.6 for mine) with the usual R and C. Given that, at high motor speeds where an entire cycle of the AC waveform could take 0.3ms and thus 0.1ms between high-side drive events and 0.056ms between commutation steps, it's gonna be pretty close to DC bus voltage - but at low speeds, where a single commutation might be 8ms or more (this is one of the main V/Hz inflection points in SimonK current limiting settings), the bootstrap voltage could have time to fall a bit and become more like half DC bus voltage - since the phase is no longer fully low, it's at near neutral.

Right?

Well, not quite... The "neutral point voltage" is a concept that arises out of the AC polyphase nature of the inverter section and motor relative to the "one-sided" (one leg considered the ground reference for logic and gate driving purposes) DC bus. Neutral, and the "Zero" that the phase voltage is crossing and we're sensing (through dividers to put in safe 0-5V range) to know the rotor position, is NOT just half DC bus!! It's half the PHASE voltage. Which is half DC bus at 100% voltage command, but is MUCH less (sixth, quarter, half...) than DC bus voltage at low speed given that your V/Hz (POWER_RANGEx) settings are sane, and are not trying to do high duty cycle into a basically-stopped motor (which is distinctly bad anyway).

The RC filter effect on the bootstrap would just help to make that more true and make the voltage on the cap constantish by averaging out the PWM waveform on the phase voltage which is at 5-20+ kHz per settings.

So the voltage across the cap (bus minus neutral, roughly) is bound to be higher than half-bus in practice at low speed. And by the time a drive is at a speed range where it can safely open up at 100% duty and put the neutral to half-bus level (stock SimonK: 1ms/commutation, my tune: 0.8ms), it's already about to be less than one time constant and so perhaps 70% of bus is more appropriate a guess than 50%. That would have plenty of margin for 4.5V design mosfets.

But wait there's more


Remember when I mentioned that discrete drivers don't have UVLO? Well, they DO have UVLO assuming you keep one bit of the original "Hobbytroller" design tenets I find rather clever.

The logic power is normally derived by a ~0.5V dropout LDO or switchmode buck (not -boost) regulator from the DC bus voltage (which of course charges the bootstraps up). The AVR has its brownout detector enabled and set to hold the chip on reset at about 4.0V (as operation below here at 16MHz is out of spec and risks crashing).

Bang. There's your undervoltage lockout. For ALL the gate drivers.

Just use mosfets spec'd for 4.5V gate drive levels.

Plenty of considerations going on with these "crude" "janky" "cheapo" gate drive circuits, huh? They're clever, brutal, elegant and awesome. Dronepeople might want to bash them, but they're actually far more well thought through than I realized early on. ("Can anyone show us a discrete drive board that failed in a manner that a driver-equipped one wouldn't have?" Crickets, most likely.)

Now there's another gotcha. You don't want to do anything (such as, um, wiring it to an external 5V supply... like I did back several years in an old project) that prevents critical (<4.5 ish V) DC bus dips from disabling the AVR - because then you just disabled your UVLO. IF you want to do something to stabilize, filter or de-sag logic power, you must ALSO stabilize the gate drive rail feeding the bootstrap diodes AND there must be a BUCK regulator feeding the MCU off that so that its brownout detect trips if the gate drive collapses. See the Twinverter? Look where the gate drive rail comes from. Yep - The input filter.

Bootstrap diodes. Hmmmm....


Most ESC boards have 1N4148 or similar for the bootstraps, whether discrete or with gate drivers that require external diodes (most of them including the now popular Fortior FD6288 and the old school IR2101). Often, the 4148 is or was a distinctive glass-passivated MiniMELF style that you will see on ZTW boards. On Afros, it's a damn tiny SOD-323 or -523 or something (looks like an 0603 scale thing). On my ACE LC1, I have spec'd a 4148 as well. Is there a better choice?

Well, first off, they need to be fast enough to switch on and recharge the cap effectively at high drive frequencies, so not some slow clumsy rectifier. And they must have as little reverse leakage as possible, since there is NO supply besides the cap to support the gate voltage during an on-time. The 1N4x48 series cover those pretty well.

What the hell kind of pulsed current do these need to withstand? There's a circa 1uF ceramic capacitor that it's feeding. Seems like a potential inrush issue. That's my main worry point.

At switch-on, the phase nodes are not clamped low - the low side switches are off and the phases floating. The phases might be pinned high if the bootstraps were still charged from the last power-up, but once the MCU turns on they will shut off. At this point, there is a current path for charging the cap fully which is through the sense voltage divider resistors, which are pulling the phases down to ground. That 18k + 3.3k is a nice soft-start precharge for the caps. By the time we're trying to drive, they have long ago filled up (3 time constants are ~60ms). So startup from cold, that's OK.

While running would be a more aggressive case perhaps:
  • Phase driven high. Cap, gate and ballast node sitting above DC bus by however much. Transistor off. Diode blocking gate/cap voltage against returning to the DC bus.
  • High-side signal goes back high (=off). Transistor turns on. Gate plummets and the mosfet turns off.
  • Cap voltage does NOT plummet with the gate. The ballast resistor is between the cap and gate and is too high impedance for it to discharge during the switch-off time so it only drains a little.
  • As the phase node swings down toward neutral, one end of the cap also does, eventually as the phase is driven low the other end of the cap that had charged the gate crosses below the DC bus level and the diode starts conducting, charging the cap.
So it's however much charge bled off from the gate leakage, the diode leakage, the leakage through 1.6K resistor during the switch-off time of the fet which is pretty snappy (few hundred ns ish?) that is being "refilled" at a rate controlled by the slew rate of the phase voltage. I need myself a scope right about now to get numbers off real boards...

4148s appear to never die here and they are in many gate driver datasheets as a bootstrap diode with ~1uF bootstrap caps. But I am going to spec 1N4448 going forward. Unlike 4148s which can be EITHER 2A or 4A pulse rated per manufacturer, 4448 are always 4A. There are both SOD-123 and MiniMELF versions of 4448 to suit your preference and they are cheaper than dirt just like 4148s. This is probably a "Don't fix what ain't broken" situation. Most Schottkys are either higher leakage or have equivalent or worse pulse current ratings.