NotFastEnuf E011 / Bwhoop Silverware Fork


It’s not far off, in fact, you’re right - I can’t tell a noticeable difference between the two.


what’s it for ? #define FPV_ON CHAN_ON


You can control the FPV camera (on and off) with the use of a FET through your TX


cool, thanks


Hi everyone

I’ve having a problem with the quad kinda resetting when doing some acro moves. As you can see from the video upon exiting the building dive, the quad seems to reset and drop abit before I’m able to recover. This has happen with my B03 Whoop as well as my latest build with BetaFPV Lite and fresh 17,500kv motors. They both are flashed with the latest NFE fork. Most things are standard and I’ve selected Super Strong Filtering. What can be wrong?


You have flown into your prop wash and the props have no clean air to grip so it drops a bit without control. Change the way you exit the dive, full throttle while still facing straight down then pull back on the stick to level out, that way you should be moving through cleaner air.


Nailed it. It’s so deceptive how well silverware flies that it’s easy to forget it’s just a tiny whoop. You have what … an overhead of 30 or 40 grams of thrust to play with beyond the weight of the craft… divided out over 4 motors is only 10g of thrust per corner. Now factor in thrust imbalances that need to be corrected and you lose even more … now your down to 8 that you can actually use. Each motor has to fight the moment of inertia of the whole whoop before it can make an orientation correction. So there goes even more headroom. Now to make it worse we take that prop and put it behind a giant windscreen (duct) and send it towards the ground in a dive … and ask it to grab air from outside of the windscreen. It has to overcome the low pressure within the duct to create thrust leaving the duct. But it’s worse yet… the duct itself has its own leveling effect crated as soon as we start moving air into it that is proportional to the amount of air we suck into the duct. We don’t want to level out unless we command that control … so now we are fighting another thrust imbalance and losing more available power. Finally at the end of our dive we turn our entire propeller system into a parachute suddenly exposing the props that were hidden behind the windscreen to an onrush of air blowing into them in a direction that wants to stop them from spinning as we suddenly change our orientation to pull out. WHAT A DISASTER! Our expectation on less than 10 grams of useable thrust headroom per corner to handle all these forces and influence a 30 gram craft is somewhat unreasonable. So it requires a bit of piloting :wink: As @Chaotix said… always dive at beyond 90 degrees to the ground … so air is always blowing into the prop and not against it. Then smoothly apply close to full throttle while still facing down. This gets the props spinning nicely with good bite … then slowly pull out … trying to gradually introduce our thrust efflux to the inrush of air towards the underside of the duct as we cross back over that 90 degree mark and windscreen is “removed”.

Here is a more practical example… one day while playing around I added a line of code to blink the led any time a motor hit 100% command. Cause if it does … there’s nothing left right … Then I flew. When do you think it started blinking?

Answer: The moment I leaned forward on the sticks to leave a static hover and it just kept blinking as I flew around. So in reality EVERYTHING we do other than hover standing still is exceeding the physical limitations of the system. I was devastated to see this. My inner engineer screamed out in pain begging me to walk away! Lol


This actually all leads to the next big break through that we need to make in firmware for whoops…the fundamental difference between silverware and betaflight… and how I believe the answer is in in some smart algorithms that sort of blend the two of them together… but before I write a dissertation on that … I’ll wait to see if anyone wants to engage in that discussion. :slight_smile:


Of course we do, lol.

What madness are you planning?!?


@Chaotix Thanks man! I’m such a novice pilot that I thought all quad should fly more or less the same!

@NotFastEnuf Awesome stuff! No one has ever written such a long and detailed explanation to a problem I had! It’s really amazing that a sub 30 grams craft to be able to do something like it does! I need to train myself to be a better pilot.


@Jakerock - were you able to sort the inverted FC out?
I’d like to try similarly.
My question is, on which axis is this line modifying? - SENSOR_FLIP_180


That means the front of the board remains the front but left and right are swapped, flipped along the front/back axis.


But boy is this fork making a difference in handling these, before impossible scenarios! What an achievement guys!

In love again with my whoops, even though they are just the cheapo e011’s and beecore lite fc based ones. Dive, dive, dive! Bansai!


E011, MTX MTX9D Multiprotocol TX Module on Taranis 9x, works with android app.

Getting it to work in level mode, acro mode, dual rates.

I think there are two bugs-- one I fixed and another I couldn’t figure out.

Bug 1: #define USE_MULTI in config.h isn’t defined when defines.h is read. So moved it to defines.h. You can see this as the compiler grays out the code that wouldn’t run
Bug 2: chan_5 – this seems to be actually mapped the channel 6 coming from the transmitter. I don’t know why. This could just be something goofy from the multiprotocol thing.

I had a lot of problems trying to get level mode activated at all. I initially had the problem that the drone wouldn’t arm until I did L-L-D on the right stick. But wasn’t until later I found out chan_5 in the git repository was channel 6 on my radio… so that could explain it.

Anyway, I can’t upload any attachments here. I did put my copy of my updated code git repository in a zip in the thread!!!(always-in-construction)/page120#post40122770

Post 1791.




Just because keil u vision doesn’t pick up the bold vs grayed out text on a define doesn’t mean the compiler doesn’t crunch it. Yes it’s supposed to … but in this case it doesn’t. It still functions and virtually none of the throusands of newcomers to silverware and this fork would know to look for that define in defines.h - it has to stay in config for useability. This is not a bug. It’s an intentional decision that has functioned properly since the beginning of my fork.

If your channel 5 and 6 are swapped … you’re just using the wrong radio type define. Looking at your link to rcg… you mention the tiny multimodule. That one needs use_devo defined. When you’re on the wrong radio define, 7, 8, and 9 still match up… but 5, 6, and 10 do not.

The top 2 rows of this chart may shed some light on your channel mismatch problems and the difference between devo and multi mappings:


I found this chart to be very useful!

I’m using use_devo, but found the MULTI Mappings matched my QX7 w/ nrf module, out of the box.

My favorite improvement from flashing my stock e011 with NFE_Silverware, so far, is a more accurate throttle! I used to need 70% throttle just to stay in the air :roll_eyes:


Can someone point me out to the right area I need to study how to flash or change pids from Alienwhoop zero flight controller to something that will work good on the Boss 7 and Boss 8 frame? Thank you.


You are here. All the answers lay in the thread above.

It’s as simple as uncommenting a different pid set in pid.c … I will say I have changed a lot since tuning the boss series … so some or all of those tunes may not fly like they used to. I plan to go back and explore the boss again soon.

YouTube has tons of videos on flashing also. Many are linked above. @luis09d made one of my favorites. @Canino did a great one too


The video was made for betafpv lite, but it is the same procedure for the other FC, you just need to know what you have and what you want. Reading the green letters is very helpful.

in Keil the windows that matter are config.h and pid.c

In config.h:
Radio protocol selection
Transmitter Type Selection
invert yaw pid for “PROPS OUT” configuration

In pid.c



Hi guys, want to ask how to flash FC H67? is there any special step for flashing this? or just same step like flashing betafpv lite or e011 with latest NFE firmware ?

I only found 1 video on youtube but seems using old NFE firmware because i couldn’t find :
#define SPI_SS_PIN GPIO_Pin_0

and other script that said on the video on file hardware.h

Thanks… really appreciate for any help