NotFastEnuf E011 / Bwhoop Silverware Fork


I don’t know about the FlySky i6, but an OpenTX controller could be configured to set two different auxiliary channels on or off at three different switch positions, but you wouldn’t be freeing up any channels. The Bayang protocol can’t do anything but on or off for a particular channel, so you just have to mix on’s and off’s.

And horizon+racemode is not what I would call “full acro mode”. It’s Racemode, with the Horizon mode modifier. Full Acro would be if the LEVELMODE is set to CHAN_OFF, or is off using a switch. You have it on all the time.


OK I think I get it. Without support for a 3 position switch … we need to figure out how to get you level… horizon … and race horizon right?

We can always use CH_AUX1 (stick gesture) to do something now… but I have no idea how powerful the mixer is in your tx to add multiple channels to one switch. The stick gesture plus your second switch only gets us up to 2 and you need 3 beyond arming…


Yeah, but if you want to use a channel for Arm, you can’t do all of that with only two aux channels…

Sounds like a good time to flash the i6 to get more channels!


What about that… that gets you all 3 modes right? Actually gets you 4… level, race mode level, race mode horizon, and horizon


Ok stick gestures used to be on chan6 to change level mode to acro mode on my stock tx
So with the flysky i6 it needs to be changed to aux1 for it to work?


Having race mode and horizon mode felt like full acro mode. It didnt auto level/stabalized


Yeah just cut and paste in what I put above for you


Just a FYI, without pidprofile switch defined, there is a build error (minor fix I guess). Testing is in progress on brushless, initial results are I’m impressed. I’m thinking it might be easier to test (and compare to the old controller) if the whole ADVANCED_PID_CONTROLLER was on a switch, the reason for thinking that is, it seems to fly better even with stickAccelerator and stickTransition set to 0.0 (classic silverware setting). Is it possible it flies sharper in the classic silverware setting or should it be exactly the same as older firmware? I can’t read code so can’t answer that question myself.


Well comparing to the old silverware was the reason to put pidprofile on a switch. So classic silverware could be in one profile and something custom in the other. Or any two profiles really. I did not clean up behavior for when pidprofile is undefined… but most of my flight modes aren’t supposed to be undefined and will break the build but they can be set to ON or OFF instead of a channel number. Only arming and idle up can be undefined… maybe I should clean that a bit. As for it feeling sharper in profile A (switch off) with all 0’s than classic silverware… mathematically it produces the exact same pid calculation as classic silverware. What version of classic silverware are you comparing to? An earlier one of mine, a legit silverware, or within this same file by undefining advanced_pid_controller? Commenting out that define just leaves silver’s code for d term … but I’m only keeping lpf 1 and lpf 2 in the code. Both are coded to work with advanced (profiles a and b) or classic.

If you’re comparing to anything outside the current file … all I can guess is that it is the specific filter combos maybe. I’ve tried pretty hard there to establish filters that play nicely together. Also something to keep in mind is that I still have a little P setpoint weight in my build since I am primarily focused on brushed. That actually dulls it down a bit. It basically applies full pids to stabilize to environmental forces… but only partial pid strength to the sticks. Brushed seems to like that to fly stable outside in rough air. Just thought I’d mention that since you have some brushless stuff… probably still applies to brushless micros though. Last thing I can think of is pid voltage compensation…that sharpened up a lot of flight feel for me on whoops.

Whatever the case… that’s a good report. :smile:
Thank you very much for checking it out for us!!


Of course, just use CHAN_OFF to disable (I keep forgetting that). I copied the new PID controller changes into the latest standard B03 firmware for the first testing, to help me do apples to apples testing, but am forced to use the DTERM_LPF filter and that might be where I saw some improvement over “standard” silverware. I just finished setting up your repo to flash that and continue testing. Certainly the new PID controller setup is flying very nice, there’s no disputing that.


With further testing using the NFE repo, and getting the filters right (very strong is OK, nearly enough for my micro brushless), and setting stickAccel to 1.0 and stickTrans to 0.0, I can definitely see better tracking of the quad. Nice work! Also, I am probably the worst tester for this as I am such a relaxed flyer compared to the race whoop pilots. I guess the whoop pilots will be very happy with this. For brushless, motor and battery temp is fine and flight time is at least the same, so those are all good indicators that everything is running smooth inside the FC.

Edit - I’m starting to think that these changes are beneficial for my lighter brushless 1102/1103 builds that weigh around 41-44gm with battery, it helps them fly like my heavier ones in that they fly like they have more inertia than they actually have, less affected by wind etc.


Thanks Ian!! What are the build details of you micro brushless? Also, as you tested different filters, what was the response of the quad that let you know you needed to increase in filtering strength? There is a lot we could learn from you! There is a custom option… and the filters that populate my very strong setting are actually listed much lower in config.h down the page if you’d like to take a look and try adjusting a bit with the custom selection. Also I’m sure you remembered to lower your pidsum and integralsum limits… but I feel bad for not remembering to say something just in case.


This one is about 10 monthe old, still going strong, it uses Racerstar BR1102 8000kv motors (3.5gm ea), a BS06D esc (2.4gm), H8 blue FC (2.9gm with wires), Zappy 100 2mm thick frame (3.7gm), 300mAh 2S 45-90C Nano-tech, 3020 props cut to 62mm (0.4gm ea). Weight with battery is just under 44gm.

Basically early days with the filters, but mostly I can hear the sound of the props, it does not sound smooth if the filtering isn’t right, plus just how it flies/handles, and battery/motor temps. I probably over-filter though. “Very strong” is a good start, I found the custom filter, now I’m trying a heavier soft lpf and different dterm filter strength to see where it leads. It’s flying nicely right now though, just with SOFT_LPF_2ND_HZ 80 (extreme heavy), DTERM_LPF_2ND_HZ 100, and MOTOR_FILTER2_ALPHA MFILT1_HZ_90. I will try DTERM_LPF_1ST_HZ next, still trying things. I’m running setpoint weight 1.0 and both limits at 0.8, 0.8 and 0.4, and MIDPOINT_RULE_INTEGRAL. THROTTLE_TRANSIENT_COMPENSATION_FACTOR 3.0, MIX_INCREASE_THROTTLE_3, MIX_THROTTLE_INCREASE_MAX 0.2f, MOTOR_MIN_ENABLE, MOTOR_MIN_VALUE 0.02, USE_DSHOT_DMA_DRIVER (dshot300, IDLE_OFFSET 28) and I set USE_HARDWARE_I2C as I’m pretty sure that needs to be set to use the dma esc driver.

PID’s at this stage (still way lower than you’d like to see):
float pidkp[PIDNUMBER] = { 4.29e-2 , 4.29e-2 , 0.60e-1 };
float pidki[PIDNUMBER] = { 0.60e-1 , 0.60e-1 , 0.30e-1 };
float pidkd[PIDNUMBER] = { 2.66e-1 , 2.66e-1 , 0.00e-1 };

Here’s a pic.


That is a wealth of information!!! I just noticed a 3rd order D filter which I accidentally left in the custom filter options and i have removed that one from the pid controller. So don’t plan on that one. Lol. I’ll update soon and clean that up.

Anyway, I love that description of selecting filters by sound and feel. Can’t wait to go brushless myself!!! I have the fc (thank you!!!) Just have to decide what to put it in. I’m tempted to go 4" 1407… but I’m a little scared. Hehehe


Update - I’m back to the default “very strong” filtering and that is working fine. Also tested on a heavier (59gm with battery) 100mm frame with BrotherHobby 1402 9500kv motors, it’s fine too, nothing getting warm, same settings as the other quad (except PID), just flies really well. BTW the 1402 motors are the best off-the-shelf motor by far that I have found for light 2S LOS quads. Probably do well for FPV too. They replace 1104/1105’s and many 1106’s and do a much better job. Some high-power 1106’s (e.g. Sunnysky, Emax) make more power but weigh more and use too much battery (less efficient) to be useful in small light LOS. The key, as usual, is to keep it as light as possible, no matter what size it is.

Finally, to finish the day off, I flashed the firmware to a 90mm frame with 1103 10000kv motors weighing 41gm with (same) 300mAh 2S batt. I saw it was nervous when flicking the pitch stick during hover, and after playing with filters and mix_increase_throttle it suddenly struck me that maybe StickAccel was too high at 1.0 for this one. I lowered it to 0.6 and all good, I’m yet to put the filters back but it’s now too dark to fly. Clearly though, it was the best this little one has ever flown, by far.

Ok that’s enough from me, back to my corner…this is all about whoops, not brushless!


Thank you so much for sharing everything you have done and testing so much. This thread is all about the fork and sort of its story growing up so to speak. I use it on many different crafts beyond a whoop… but whoop is the default. I am tempted daily to start assembling a brushless craft using this firmware so I find your stories very encouraging. My current options are 1102 2" or 1407 4". The 4" I find a bit scary to jump into brushless silverware with … but maybe I have nothing to worry about. :slight_smile:


Cough You’ll use mine thank you… :smile:

Anyway, is there need for Dterm Error with the new code? Updating the brushless fork…

edit: nevermind…


I still need to make some commented notes explaining how to adjust settings inside pid.c … and a few constraints that limit user input variables to safe values. But keep me posted if you have any questions @yets.

What say after that we jump into over clocking, looptime, and gyro refresh frequency. :smile:
I also want to do dome more in the future with the experimental gyro setting (fastest) … and see what we can accomplish by cascading two 1st order filters in place of 2nd order filters. That could be fun… imagine a f0 running a 4k/2k loop. Hahaha


Cheers. I realised that I need to update all the separate expo changes so the fork will have to wait until it’s done.

On over clocking, looptime and gyro rate that’s all being worked on for the DShot driver at the moment. Results look very positive, there’s talk of it all in the Dedicated brushless board thread


On my way over… :smile: