Adventure Force Sportsman internals, measurements, predictions

The Sportman has caught my attention. As I've said before, it's nifty - it does something that conventional wisdom has held to be impossible, and what's more does it well - and I'm looking for ways that it could be put to good use. 

So, today I'm doing a detailed teardown of the blaster. I'm doing this to get a good look at what's in there and what it can do, but this post should also serve well as an internals reference.

Extensive Adventure Force Sportsman reliability testing

This has previously been posted on reddit, here. I'm resposting on this blog primarily for the sake of having an archive with all of my work with this blaster in one easily-searchable place.

The Adventure Force Sportsman does something that conventional wisdom has held for years to be impossible: it feeds darts into a chamber through a hopper. Naturally, this raises concerns about whether this blaster can do so reliably. As a hopper-fed blaster, the Sportsman should be great for scavenging and for lightweight loadouts that avoid the use of magazines - if it is sufficiently reliable. That's a big "if," and that's what I set out to test here.

This is going to be a long, drawn-out post on a single blaster. There's a summary of the results near the start, after the jump.

Thoughts on MLCC as inverter DC link capacitor

In quadcopter/drone ESCs post-BLHeli, it has bcome common to use arrays of multilayer ceramic capacitors (MLCC) as the DC link capacitance. A MLCC farm like this has become a familiar sight.

There is some considerable merit behind this. MLCCs have extremely low ESR and ESL, comparable to plastic film caps and any other type of non-electrolytic capacitor, and could do the job with much less capacitance than an electrolytic, which actually really suck at being DC link caps, despite always being used historically for DC link caps. More reading on the subject. Beyond that, an array of MLCCs on a board packages flat and thin and avoids dangly bits, and in terms of overall package length, the length of an existing lytic can added to the PCB is enough area to fit plenty of MLCCs.

On the cost front, it isn't too bad. A 10uF 50V X7R 1206 part, likely similar to the 18 parts on the above nerfish-scale board, from the vendor I usually use for MLCCs (Samsung Electro-Mechanics) can be had for 10 to 15 cents at this point in moderate quantity. If the Salcone-Bond whitepaper example cases are taken to frame a rule of thumb, certainly 18 to 20 such parts totalling 180 to 200 uF should suffice in most cases to replace the lytic(s) outright, at least in the current handling and bus ripple sense.

There are a couple of reasons I have been very reluctant about adopting either this strategy or a hybrid one with a smaller lytic and a handful of MLCC though, instead favoring the tried and true, dirty great big electrolytic, solution.

One is that MLCCs are brittle and sensitive to stress, whether mechanically induced (external forces or flexing applied to boards) or due to thermal expansion. And when these things crack, they often become shorted. High-current, deeply parallel MLCC farms directly across a lipo and immediately next to a heat source (FETs) give me pause for this reason - there are a lot of parts there to multiply the failure probability, they are attached to beefy, heavy (inflexible) copper planes, they get heated a whole lot at installation to solder them down to said planes, and they and the differentially expanding PCB are being constantly thermal cycled by FET heat in operation. If one dies, it likely causes a rather high-energy smokey unconfined failure, destroying the PCB and possibly resulting in combustion. I worry enough about the single big MLCCs that are across the battery on my ESCs and S-Core boards already. Is it really worth such fear? It is paranoia? I don't know, drones don't seem to be nuking ESCs all that frequently, I guess. Meh.

Another is that a pure MLCC solution has no "damping" the way lytics do. Small motor controllers normally don't have precharge setups for the caps at startup, and just get switched up with a huge inrush into the caps (and the familiar spark). Between the source inductance and the several hundred uF of basically-zero ESR caps, there could be spiking when powering up with just ceramic caps. It's like setting a car suspension spring vertically on the ground and hitting it with a sledgehammer. Pololu warns about this with their DRV8825 carrier boards, and their answer is to always have a lytic nearby on the same bus (as the 4.7uF 1206 input cap on the board). Advice to do similar things is common. So perhaps it is apt to use a hybrid solution at most, not purely MLCCs. Or perhaps a TVS on the bus could guard the FETs and logic power supply against overvoltage spikes sufficiently.

The third is that a MLCC farm to replace lytics turns 1 or 2 parts into 15-20 or more for a larger board, and a hybrid solution adds 4-6 parts and still doesn't completely remove the lytic cans that have to stick out somewhere, only make them smaller.

The fourth is that often, a huge surplus of capacitance is beneficial. The Salcone-Bond view of DC link caps assumes that they are solely there to source ripple current and stabilize the bus voltage at the input. In the real world, big lytics are often doing something else. In VFDs and appliance motor drives, they are much more a bulk energy store, since the input is rectified 50/60Hz mains and there are big valleys in the voltage that need filling in. In blasters, that's irrelevant, but they sometimes are doing the same thing to cache some local charge and prevent marginal battery and wiring conditions from causing the floor to fall out of the bus voltage as easily during a motor current transient (possibly to the extent of causing MCU resets and other woes). It's all the more important when batteries are NOT lipos (lipos are much more non-inductive than usual due to the stacked construction) and/or there is a long cable between the battery and the inverter, which appears multiple places in blaster design. Blasters can have much less optimal battery situations than RC stuff - just the matter that people play HvZ where/when there is snow on the ground and they are NOT going to be keeping a pack warm, for instance.

On the flip side, I do suspect my layouts with just the lytic at the end of the board are suboptimally decoupled and could benefit from a few MLCCs very, very near the actual devices in addition. And I kinda want to do a lytic-less board sometimes just for variety and to have an option that can be as thin as possible.

Edit/footnotes: https://www.rcgroups.com/forums/showpost.php?p=38006136&postcount=1220 https://www.reddit.com/r/Multicopter/comments/7nb2zs https://www.rcgroups.com/forums/showpost.php?p=41652761&postcount=16 https://www.rcgroups.com/forums/showpost.php?p=41660297&postcount=17 More interesting accounts of electrolytics and MLCCs and I wasn't surprised to see the exploded rail of MLCCs with a 1000uF lytic bodged in its place!

ACE-NX inline final tweaks, test boards on the way.

Last revisions: Fixed some potential shortcomings with grounding. Added a little copper island on the other side behind the phase wire pads on the edge. Stitched to the pad with 3 vias.

 

 

The idea here is to make the phase wire pad more rugged against lifting, this is common to use vias for this purpose in drone ESC boards. It also adds a small extra thermal area and mass to the lowside device.

I decided to mothball the LC Mini for now and focus on getting this beastie spooled up first. It will also be my potential dev board for the 6EDL04/ace.hex target before doing the mountable version.

ACE ESC: ACE-NX (inline wiring version) 1.0

Progress on the ACE-NX project has involved mostly ditching the bs_nfet_noninverting pinout and rethinking all the MCU pin assignments.

• Gate, enable and nFault signals for the driver are all moved together and in order with the 6EDL04 driver pinout.
• Throttle input uses ICP like Afro, not INT0 like bs_nfet. This kills some jitter and half the interrupt overhead associated with INT0. Also makes the throttle routing much better.
• Phase voltage sense lines moved together.

However:

 

I also designed another board that was not what I was and am eventually intending (the mountable one), rather it's another ESC style unit. It's a combination of there probably being market demand for inline-wired boards like this, and me needing them for the T19 which I am not going to simply be replacing entirely anytime soon, and the fact that regardless of anything, since I DO want to start selling ESCs, I am either going to sell a modern driver-equipped board OR I am going to sell LC2s. So, it was time for the discrete drive to go and the LC2's beef shortages to be beefed, with the future of bigger motors and higher voltage DC busses in mind.

 

Which they have. The NX Inline is 1mm wider than the LC2 (26mm, same as Afro FS20), has beefier source connections on the lowside than the LC2, is busbar ready (use solid wire) and has significantly more highside device copper area/heatsinking even before adding a busbar.

Other improvements on the LC2 include revised FET footprints, all ISP pads in one place, plus the usual SimonK ready and warning LEDs, because blinkenlights. Also, the sense network may have finally received some due consideration. I tried to shove it to the opposite side of the board from all the noise sources like the DC bus path to the caps, and the SMPS. Something about sense networks is that the phase node, since it is directly connected to the motor, is mega low impedance, that's likely not what is going to receive noise. It's the node after the first resistor in the divider and of course the neutral. Those in my past boards had some long convoluted traces mixed in with the rest of the MCU-related traces and that is not good. With this one the resistors are right next to the associated MCU pin, the other ground resistor is directly underneath on the other side, neutral routing is very direct and the trace lengths are minimal. Will be seen whether these are cleaner starter-uppers than LC2s, it may just turn out to not matter.

Gate drive supply is from an AP3012. This uses a linear logic supply due to area and the lack of more good places away from sensitive stuff like the MCU oscillator and sense network to put a switching noise source without this board either getting bigger or being a pain in the ass. It is minimum 0805, as this is going to be the new general-purpose "not mini" ESC board and it is important that it not be a pain in the ass for either me or other people to make. Bootstrap caps, LDO input cap, boost input and output caps and driver 12V decoupling cap are all 1206. Also, it uses 40x20mil vias (mainly, for power stage reasons) which should eliminate fab issues as well with drill size.

Voltage rating depends on LDO and FETs. This can take a few different 40V devices and there are several 42 and 45V SOT-223 LDOs (the one I normally use is 40V) to correspond.

A bit of an erratum is that I post-schematic'd 3 0805 resistor footprints into this for pulldowns to ground on the lowside gates. Granted, every single FET/IGBT driver datasheet, board design and application note I have ever seen says nothing of the need for them, but to me, it just stands to reason that since the driver datasheets often don't give any indication that the output stage is NOT high-impedance with NO power to the chip, OR that there are any internal pulldowns on those gates, something bad could potentially happen at startup where the DC bus comes up a tad before the power rails to the chip do. So, I figure putting 100K or so (so as not to load the driver with much extra current) on the low sides to source will be a good safety measure against the chance that somehow, some gates are charged up when power is applied and cause a brief shoot-through. Probably just total design overkill.

S-Core firmware 0.97: Add nonvolatile user flywheel speed profiles

In the past I envisioned most blasters being run by default at full permitted velocity. If the game mandated less than the flywheel system's critical velocity for safety, that would normally be set with the tournament lock. Of course it would - if you can change it on the field, how could it ever be legal? However, by numbers, most games are quite casual and their playerbases quite mature, and they do not impose the use of the tournament lock, hence the typical usage pattern of adjustable-speed T19 in the wild is that players leave their tournament locks maxxed out and dial their blaster up on the chrono in user speed mode before playing.

This usage of the user speed adjustment mode with no means to save the resulting setting presents a number of problems. One, you have to dial the thing on the chrono every time. Two, if you shut down your blaster for any reason, you just lost your velocity setting. Three, you can't switch between canned velocity settings.

https://drive.google.com/file/d/1czPJ6wRAeR365x6zpS-CtlbzdjfZ84LU/view?usp=sharing

So I made a quick tweak that uses the selector position at boot time to choose a user-defined speed setting in EEPROM to either load (normal boot) or save to (speed config mode). As such, you can dial each in once and next time you want to use that setting, just put the selector in the requisite position before powering up.

Attempting to load a speed setting that is invalid or above the current tournament lock setting will throw a non-terminal Code 53, then save the current tournament lock setting to that profile, and begin normal operation. This will happen if you try to use a setting that has never been saved to (such as just after flashing), or if you try to use an old setting that is now higher than the tournament lock after lowering the tournament lock setting.