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.

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.

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.

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

Files added

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.

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.

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.

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.

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.

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.