NotFastEnuf E011 / Bwhoop Silverware Fork


Update for the evening… big changes tonight throughout the evening.
Final results are the new updated pid controller is in. I will explain a bit more about how to use it after getting some rest but the gist is I have added setpoint weight and transition similar to betaflight in the pid.c page. I call setpoint weight something different though - stick accelerator. Cause that is basically what this particular setpoint weight is doing inside of the pid sum. Anyway, where I differ from betaflight aside from naming - is that I have broken out separate adjustablility on all three axis. So you can change them individually. And as if that were not enough … I have added a second profile that is selectible on an aux switch (currently set to CHAN_9). So if you just can’t decide what to do with the numbers to change the feel… or you like two different setups - you can have 2. :wink:

Range of safe values for stick accelerator is 0 to 1, but I have tested to about 2 and it seems ok (mega crisp). A value of 1 equates to the old test mode for error D term. Value of zero equates to classic silverware.

Range of safe values for stick transition is 0 to 1 where zero indicates no transition will take place and your stick acceleration will remain constant across the stick throw range… and a value of one indicates that a 100% transition will take place which will reduce your stick acceleration to zero at center stick.

I have actually coded transition to be safe for negative values as well which would equate to more stick acceleration at center stick than you have set by the stick acceleration variable that then fades down to your set acceleration value at 100% throw … but that gets pretty confusing to follow and goes totally against the grain of every other flight controller firmware so just ignore that for now unless you are into pid controller theory. I happen to like it… and that’s what having your own fork is all about. I put in some fun defaults for you to try out… classic silverware on profile A, and a basic blend of classic silverware and error D term on profile B. As I test more, I will probably update profile B to whatever my favorite is, but leave profile A as classic silverware.

Happy flying.

I do still need to update commented notes inside the firmware… but this has all been tested across 3 different targets and in every flight mode. It is all 100% working.

Last thing… with these changes the fork is going to settle down for a bit. I’ve got just about everything i want in there feature wise so there will not be anything new to get used to for a while probably. I am going to focus next on DSMX support and maybe telemetry for sbus, and start cleaning out code that I consider bloat for the purpose of this fork. IE… old filters that I don’t use or support, the auto flip sequencer that flips for you like a toy quad… stuff like that. I probably need to go back and re-tune all my boss series in light of the new features since I’ve just been focused on whoops, and will continue to make minor tweaks to my preferred settings. My goal with this fork is to create the most ripping out of the box micro brushed experience that exists! :sunny:


I just flashed a completely new quad, Furibee H801 (Bwhoop-B03) and I’m experiencing the exact same problems. I’m convinced its either the firmware or my QX7S is failing. Any other Bwhoop pilots out there?

Happen to have any versions from a month ago or so?


Ok, it definitely appears to be the firmware. I found an old H801 with NFE from a month or two ago and it flys great. Is it possible for me to upload the firmware from this quad to flash to others? I’d like to flash it to the two FCs that were failing on racemode to see what happens.


NFE firmware May 8
NFE firmware April 10

Might be easier to dl older versions (examples above). You can find them by going to the main NFE firmware page and clicking on commits, top left. Have you double-checked your tx selection, as it changed recently.


Yep, I’m going with this being the problem as well. I recently changed the default aux channel map to use_multi instead of use_devo. I don’t think you are getting into racemode. You should really try selecting use_devo @DonnieH801. That change seems to line up with your issues.

Thanks for the after hours support relative to my time zone @Ian444. Very curious what your take will be on the new pid controller options to tweak feel. Do you think I explained how to use it clearly enough?


I’ve been using multi since I’m using an IRX4+ module. I tried DEVO as part of troubleshooting but it didn’t work at all. Next, I’ll flash the Pro and the new H801 with an older version to see if that fixes it. Any other suggestions? I appreciate all of your help.


Yes it seems well explained, no problems there. I’ll give it a go hopefully tomorrow morning, looking forward to it for sure. Now that you have broken the tuning up into weak/strong/very strong, I’d like to try that again on the brushless, I’ll start with very strong and see what happens.


I’m seriously loving error D-Term - Did you change anything on this? ATM I hardwired the setting. I was able to fly yesterday because of good weather. I had 2 0615 BOSS builds - one with an older tune without D-term Error method and one with the latest settings using D-term error. Difference = Night and Day… I can’t go back to the old way - hahaha

Also Good job - 2 pid profiles!

I’d only wish there was a way to save some sort of ‘ini’ file with all my preferences saved and have both pid.c and config.h use variables referenced from this ‘settings’ file.
Config.c has significant bloat and it’s getting cumbersome scrolling up and down, looking and trying to remember every change I made in the past.
I tried to make essentially a “spartan” version of this code but it’s too cumbersome to merge, so back to the old way of hunting and pecking for settings.


Yes, I took it away and gave you a new pid controller based on this with full adjustability.
The error method you’ve been flying is a stick acceleration of 1 with 0 stick transition. So input that for profile A. I also added some yaw d to our tune so yaw accelerates too. It did not before on old error cause yaw d was 0.

I can use you for a cutting edge experiment if you’d like… on profile B, put in a accelerator value of .5 in and a transition of -1.0 … then go toggle channel 9 and tell me which one you like better. You might see the value of the adjustability then. Also remember these pid profiles don’t change the actual pids… just the accelerator and transition values. A good tune is a good tune and doesn’t need to change… but these feel settings can give you juicy or sharp, or whatever you want, and is worth changing depending on your mood.

Unfortunately everything left in config.c top section is not bloat… it’s all necessary. The bloat is everything I already removed from config that still has code elsewhere which is sitting around no longer being turned on by anything in config. The good news is that it’s gonna be a whIle before I code anything worth updating so you aren’t gonna need to keep downloading stuff. Just run your current files. I’m happy with where we are at now. Just go cut and paste your config to move the things to the top that you like to change.

Also if there is something you’re not using in config and you dont know what it does… ask. Most of those unused features are cutting edge.


I appreciate your feedback… you may just be the first person finding a big problem… not sure yet. We need more people to flash and fly to see. Keep posting as much as you can about test procedures we can follow to replicate your issues. Also, flash the old builds that @Ian444 linked and report.


I’ll check it out. Also, is Channel 9 hardwired, or can I use another channel.

My thoughts exactly!

Maybe 'Bloat" is too harsh a term.
I’d love to see an INI.c or an INI.h file in which we define all of our defaults, then in theory, this would mean editing a single file on the user end, without having to update several files, which can lead to unexpected results.

For example - and since I’m not a programmer - it’s pseudo code - hehehe
The code could be updated and maintained by the programmer without the user having to worry about rearranged code as long as the variables remain constant.

so, in config.c
#define E011
#define MAX_RATE 1200.0
#define MAX_RATEYAW 1000.0

I’d define it as
#define (user value referenced from User.ini file)
#define MAX_RATE (user value referenced from User.ini file)
#define MAX_RATEYAW (user value referenced from User.ini file)

In my User.ini file (or anything it’s named) it would contain something like

craft = E011
MAX_RATE = 1200.0
MAX_RATEYAW = 1000.0

Just a thought…


Just keep stick acceleration low (close to 0) on brushless for now till we know more about how it plays with brushless. We don’t smooth our rc inputs so I did filter the derivative of setpoint which is the accelerator to be on the safe side… normally with a smoothed input you wouldn’t do that but I think it will buy us a safe adjustable range. I think it will be totally safe up to 1… but at some point there exists a value that will cook brushless motors from active braking.


Not hardwired… change it around just like the rest of them where you pick your auxiliary switch features


I think that’s the idea for config.h, really, to keep all of the customization settings in one place!

Sure, there are some customization settings in config.h that I don’t personally use, but those aren’t the same ones that you or someone else ignores. If we moved all of the settings that people like to tweak into a User.ini file, I think it would eventually just become a duplicate of config.h as everyone asked for their personal preferences to be in the easy .ini file :- )

On your own copy of config.h, though, you could move all of the settings you use up to the top of the file and push down the ones you don’t so you don’t see them. That would make it more difficult to merge future changes, though…

Or I guess we could complicate config.h a bit with #ifdef’s surrounding every setting and have a config_user.h that overrides any setting in config.h, if defined, but if not in config_user.h, the default would be used.


I think it would simplify things from the user’s point of view and yes, complicate it for the programmer.
That said, IMVHO, I think that user configuration files should only have values and not contain any actual code. I then would “include” this file in config.c, pid.c, etc… All your magic should stay behind the scenes without concern for user corruption - and in addition, makes merging code much simpler for all…

Now I’d be able to save and keep different file with build customizations without having to touch your code.

Currently, the moment I personalize the code on my end, I risk not being able to merge automatically with updates.


I have not forgotten about this… as soon as we sort out if I have broken race mode for you guys … we will visit your request.

One of the biggest challenges in development is keeping a test rig flying. On any given night of development I will edit, flash, and fly like 50 times. Batteries are puffed and sagging inside of a week, motors are spent every few days, I’ve even broken a flight controller this week. I need to rebuild my whole fleet right now so I can make sure I eliminate mechanical issues from software issues… and my whole fleet was just rebuilt last weekend. Lol. The struggle is real.


i finally got it to work with the flysky i6 with multi protocol module

define devo

#define ARMING CHAN_5
#define IDLE_THR 0.05f
#define HORIZON CHAN_6

but one thing im missing is gesture mode… it blinks the lights but dosnt change the flight mode… thats the reason why i had race/horizon on chan 6 switch. also how do you guys make a channel work on 3 way switch?


@DonnieH801, @Whoopingtits … here is what I’d suggest moving forward to sort this out.

First flash the old file that Ian linked. Pay attention to the use_devo use_multi selection
Report how it flies…

Then download and flash the latest… report
Then disable levelmode_pid_attenuation … report
Then disable pid_voltage_compensation… report
Then disable transient_windup_compensation… report

These are the only things I can think of involved in where your behaviors exist.


OK so now you are in racemode_horizon all the time. Currently nothing is mapped to the stick gesture channel by default. I’m sort of saving for testing future experimental feafures. Just let me know what switch channels you want to do what… and I will tell you how to fill all that in.

Super stoked I didn’t ruin my firmware. … hehe


i only have 2 available channels to use which is 5 and 6… i havnt flashted the flysky i6 tx for use all channel 10 yet.
i have race and horizon combined to start acro mode once i flip the switch. but i really wanted the 3way switch to work like level mode then horizon then horizon/racemode = full acro mode.