Hy-Con/T19 Part 7: Aesthetics experiments, Model Pandora's new wire covers, power system change overview.

I had a USF HvZ game coming up, so something greatly needed to be done about the motor phase wires strung across the sides of this blaster before they got snagged and ripped out. I took the opportunity with these wire covers to try out this fluted surface finish, which will definitely make it into many Production T19 parts.

As a final tweak, I drew up a flash hider for it as well:

There is a considerable practical purpose to this device aside from making my blaster look more tacticool and less truncated. Namely, a bit of barrel length (including any muzzle-thingies) is desirable for working past bunkers and cover. I had a habit of shooting darts into my bunker. Furthermore, with a bare Hy-Con cage, firing pointblank into an obstruction, such as a cover item or a charging zombie crashing into you, would lock the flywheels up and completely pulverize the back half of the dart. The flash hider gives somewhere for that dart to go and avoids unnecessary drive abuse and unnecessary dart vaporization.

It's also the first official piece of Production T19. I'm working my way back from the front of the blaster. Things are gonna get modelled and tested quite fast in the coming month or so.

The power system also got a considerable revamp. Gone is the 3S battery. I now run on 4S with the closed-loop control discussed in the last post. This greatly enhances performance of the flywheel drives with much better speed regulation during firing, better startups, and consistent full speed and critical velocity throughout the battery charge cycle. It also buffs up the stepper bolt drive's torque curve and allows running higher ROF. I currently run at 11rps and have fewer skipped steps than I did running 9-ish rps on 3S, which were not many to begin with.

A change to support the use of 4S is that the backplane's 5V logic power buck/boost module needed to change, since the S9V11F5 is rated to maximum 16V input, which can be exceeded with a fully charged 4 cell battery (though for a while I was feeding it straight 4S and there was never any failure). I have purchased a few different alternative buck/boosts with higher input voltage ratings to try out, but what got me through all the recent combat and will probably remain in the Model Pandora for good was in fact a S9V11F5 with two 1N5551 diodes in front of it to waste a volt or so. Yes, it's janky as fuck, but sometimes janky works! if anything goes wrong with the alternative modules, that may very well be a backup plan.

motor tech - Intro to closed-loop speed control with SimonK.

Shifting gears a bit. Closed-loop control, specifically speed control, has been a wanted and discussed feature in flywheel drives for years now. What I didn't realize was that it has been right in front of my face all this time and I was, in fact, using it. Not optimally yet, mind you - but it was there.

SimonK has a simple "governor" feedback loop to duty cycle, configured with the parameter TIMING_MAX. This is to prevent motors from overspeeding and exceeding the frequency limit of the firmware, which follows from the calculation used to generate the next commutation timing on each cycle. In pre-2015 SimonK, this timing calculation was 24-bit only, and TIMING_MAX was set stock to 0x00e0, giving a commutation period of 56us which equates to 178,571 electrical RPM. With a 14-pole machine (7 pole pairs), this becomes 25,510 mechanical RPM. It turns out my old Hy-Con drives have been governing at this speed all along! The oscillation I mentioned earlier is a minor control instability which occurs under certain conditions because the governor loop is a fairly crude controller, more or less just meant as a safety rev limiter. However, keep the bus voltage*Kv product well away from the governed speed (i.e. not my old 3S hycon!) and it works damn well, giving rock-solid speed regulation. Not like the faint rumble affects flywheelers anyway, I had it all along with T19.

By contrast, 2015+ SimonK has a more agile timing calculation methodology and can safely be governed at up to 312,500eRPM (TIMING_MAX = 0x0080).

Followings from all this:

TIMING_MAX/4 = commutation period.

This is a six-step drive scheme, so 6 commutations = one full AC cycle, and the period of the AC is (6 * TIMING_MAX / 4) microseconds. Divide that period by 10^6, and invert that, and you get frequency in Hz. Divide that by the number of pole pairs in the motor, and multiply by 60 and you get mechanical RPM.

There's your governor setting crib sheet. Back out a TIMING_MAX, punch it in, set all your other parameters how you want them, build and flash.

There is at this time no way to adjust the speed setpoint post-build. You cannot, for instance, have a throttle command interpreted as a speed setpoint, or send the speed setpoint over some protocol from your blaster controller, or anything of the like - you need to recompile and reflash to change governor setting. This ought to be fine, since motor speeds normally pair with physical flywheel and cage parts - and if you are intentionally turning down velocity by slowing your flywheels down, the difficulty of changing the governor settings only makes it more legitimate as a means of safety compliance.

Going closed-loop of course has some very good ramifications for subcritical operation - no longer do startup times and torque curves need to suffer as they do when speed is reduced by commanding less duty a la FDL.

If you need to go faster than 178,571eRPM you need to use 2015+ SimonK and build with your specified TIMING_MAX value. If you want to govern at 178,571eRPM (25,510 mechanical RPM with a 14-pole motor), it is very convenient to simply use stock SimonK version 2014-09-30. For Hy-Con 9.5mm wheels, 25,510 is, or nearly is, critical speed, and a perfect governor setting (I tested while free-spinning my motors on 4S with 2015 SimonK to annoying-sounding 30K+ speeds and didn't get more velocity from that). SimonK 2014-09-30, and indeed every version of SimonK I have ever run, operate perfectly with the Turnigy V-Spec 2205 motors without any sync issues or the like and I have been running 2014-09-30 in combat as of late with zero problems.

Disclaimer

More testing is required with various TIMING_MAX settings and motors before I call this anything other than beta, so if you are using these findings for something different than where I have explored so far, recall the warning in SimonK: "If it breaks, you get to keep both pieces!"

motor tech - Brownout reset issues and proven workaround on 20A Opto Afro with SimonK

Up to this point everything I have tested and used under the Hy-Con umbrella has been run on the same trusty pair of Afro 20A controllers (BEC version, though I don't use the BEC in my system) on their stock flash of whatever version of SimonK. They have served up thousands and thousands of rounds without a single fault and weathered numerous violent stalls and shredded darts during the cage's evolution. They're rated a bit lower than my overbuilding mind would like, but hell, they have proven themselves.

I went to buy more controllers, and the old trusties were sold out. So I bagged a bunch of the "opto" (really just non-BEC... with no real optocoupler anywhere to be found... like most "opto" ESCs...) version instead. Putting my lucky pair of controllers safely aside, I began using them for firmware experiments, starting with stock latest release SimonK.

First discovery: These Opto Afros die and reboot every single time if you send them a hard throttle step while the motors are spinning down and reach low enough speed. Oh, not this again!

Preliminary poking around revealed absolutely zero difference in the logic power supply arrangement between the two versions. Firmware was also cloned from my old lucky 20A Afros to the test pair of new resetting ones with no change, so it doesn't seem to be a SimonK version or parameter difference. I tried a wide range of SimonK versions, with both low-speed/startup duty cycle management strategies (the old variant that did discrete hard shifts in duty at set speeds, and the newer smooth-ramping one) without improvement.

That leaves two hardware and one low-level software possibilities to explain the different behavior between these two nearly identical drives that ought to behave identically:

* The inverter MOSFETs are different components between the two models. The BEC one has Toshiba TPCA8087 (rated for 56Adc and 168A transient, incidentally). The "Opto" one has a visibly different, so-far unreadably labeled, device. So this could be a lower Rds(on) or other different properties, and maybe make the startup current transients nastier.

* The stock DC link capacitors are different. Both are Haicap brand, 35V, 220uF (IIRC, but both are the same ratings) but the one on the "Opto" has a longer can. We would expect longer = lower ESR = better; but perhaps not. Insufficient buscap can cause all kinds of hell with motor drives, and seriously, who is "Haicap" anyway?? Replacing these with something BIG and GOOD as a test is on the list.

* The ATMega fuse bytes may be set differently, resulting in a lower brownout detection voltage on the working drives. In this case, the resetting ones may be behaving properly, while the "working" drives may be running the ATMega8 out of spec for Vcc at 16MHz. This is bad. Recommended BOD settings exist for reasons. The microcontroller could crash from the Vcc sags. If it crashed with the motor underway, very bad things could happen! That will be investigated once I have the right ISP socket to read the fuses on them.

Anyway though, what I noticed while testing was that the brownouts corresponded with what looks like a MASSIVE current transient. My phase wires were jumping around from the magnetic fields, like the leads on my battery welder! This gives pause. It is entirely possible that the usual fix - throw an increasingly mahoosive battery at it until it stops rebooting - will cover the issue up, and changing to stabilized logic power WILL cover it up, but if there is actually an unexpected gigantic current excursion going on here, that really needs to be addressed. That's not supposed to happen and especially with a 0.077 ohm phase-to-phase motor and a tightly sized drive here, the inverter mosfets may get blown sky high if it's getting hammered with 100% duty at low speed and that isn't mitigated - it certainly isn't nice to any of the equipment including the battery.

Duty at very low speed should be limited to POWER_RANGE/4. Should. I suspect a bug - especially because hard throttle steps from 0 rpm never cause any symptoms, only hard throttle steps from low but nonzero speed while the rotor angle is still being tracked.

A solid workaround found was to enable SLOW_THROTTLE. This is something that sounds wrong after the history in this hobby of chasing more and more current and torque and the most aggressive possible responses from every component, but it doesn't seem to affect startups.

Per my understanding, enabling SLOW_THROTTLE won't even affect the duty (hence current and torque) profile of a 0 rpm startup with an inertial load attached (like a flywheel) as:

* the minimum duty SLOW_THROTTLE permits is POWER_MIN_START anyway;

* the TIMING_RANGE (frequency-based) duty scheduling strategy used in the startup process should always result in lower duty slew rates when accelerating an inertial load than SLOW_THROTTLE's restriction that the duty may only double in a single cycle and no more... at least from what I can tell.

Now, SLOW_THROTTLE really ought to not affect a start from such a low speed with a turning motor, either, because the TIMING_RANGE based duty schedule ought to still be enforced as part of the update_timing* routines. So why DOES turning SLOW_THROTTLE on matter? Hell, how does such a fast duty ramp (as doubling per-cycle from a starting minimum of POWER_RANGE/6, thus going to 100% in 4 commutations... I think) even help our issue by itself? Yes, this warrants further investigation and dissection of SimonK. SLOW_THROTTLE has given flawless operation and great results so far on 3S and 4S and will be part of my official SimonK variant for the Hy-Con/Production T19 for now, but it's a kludge fix.