Micro Motor Community

NotFastEnuf E011 / Bwhoop Silverware Fork



This is a nice start on the cpu load analysis!

The optimize for speed tick box sounds like a winner - super easy.

I worry a bit about the overclocking, but if the temperature is okay after running 10s of minutes and no computations are corrupted, I don’t know how to argue against it :- ) The overclocking community probably has standard ways of testing that an overclock is stable, I guess.

The switching between LEDs and gestures, etc. is a good idea. Those human-speed things shouldn’t need to be done at the same resolution as the gyro/PID loop. Another thing to throw in there might be the battery voltage reading, etc. Sub-second changes there probably aren’t too important.

I’m afraid I’d be pretty useless evaluating the different filter types. I’m just not that experienced a pilot yet :- )


Yeah vbatt stuff too. I forget about that today but was looking at it previously. Unfortunately vbatt and gestures are pretty small processes… So hopefully we can add more to their group to offset against the 100ms of led stuff or it’s almost pointless. I need to reassemble my fleet and fly these changes.


Vbatt is used for voltage based PIDs so probably not the best idea to slow it down?

Another note, I got problems while ticking speed optimization box a while back, it broke debug mode from time to time and broke the passthrough feature. Not sure how it behaves at your fork but keep that in mind :smiley:

Also, OC caused instabilities in debug once (Keil issue?), solved meanwhile, but probably better to check :wink:


Gotcha, I will set up test debug and serial pass through stability next then. Testing debug is unavoidable - I basically live in debug mode now… But serial pass through I have never even played with. So this is an excellent idea for a next step on my breadboard.

As for voltage stuff and the loop … Don’t worry there. All of our decisions in the loop based on voltage are using a Vfilt- a filtered voltage that is normailzed to remove moment to moment sag and fluctuations. Checking the actual voltage on adc and updating Vfilt 500 times a second instead of 1000 times is still overkill to keep Vfilt accurate and stable. But the decision to run it every other loop will depend on if I can find a close to equal amount of stuff to alternate with it’s 100ms. Right now gestures and led stuff together isn’t even close to enough. A better approach may be to look for and optimize any floating point math in the project that isn’t directly flight related.

Your perspective and suggestions are very helpful @SirDomsen - thank u.


Thank you for the quick reply! How about putting a DSMX sattelite rx on the CLK pad of my E011? Or my R9MM? (For the R9MM I need to setup Sbus in SIlverware’s config.h file I presume)


Yes just select whatever receiver type you intend to use and connect the signal to clk pin. Keep in mind when you flash this change to a toy board… You will only have a second after connecting a battery to flash any future changes. After that the programming port is closed. You may/may not also need to disconnect your receiver to flash as well. Finally you will need to finalize s stable voltage source to run your receiver. Toy boards only have vbatt and 2.8v regulated. You may need a separate voltage regulator to power your Rx for it to function correctly.


Hi guys, last night I was building latest NFE and find out that I cant change mode to autolevel using CH_AUX1 when I assigned that index to LEVELMODE.

I am using config betaflight rate, use_multi and bwhoop board.

I debug the code, the gesture was working fine, but whatever the code aux[CH_AUX1] = 1 triggered at gesture.c, wont affect if(aux[LEVELMODE]) in control.c for evaluation

I wonder if anyone also experienced this issue


Yes this was just discussed here over the weekend. I have hard wired ch_aux1 to the stick travel check mode. If you want to use this stick gesture as an auxiliary switch, you need to comment out stick travel check mode.


Flew FPV for the first time and it seems I’m in Horizon mode. I don’t know how that happened. Trying to figure out what each button does vs the channels in NFE.

I believe Chan_6 is the left most button under the Throttle as that arms. Beyond that I’m just guessing. The sticks themselves can be depressed to activate SOMETHING. Found this image on the net but it’s not that helpful. Will research some more.


Moving the board to avoid gyro calibration extends the time to be available for flashing ,iirc since it is initialized after gyro?



Also @Fissionbomb.PMR. The answer you seek is here:

This key tells you, for example, that channel 8 is toggled with the roll trim buttons. If you look at your channel assignments in config … And if you have not changed them from default … Horizon mode is assigned to channel 8. So therefore - if you are in level mode … Toggling your roll trim buttons will turn horizon on and off.


I think this is close? Ch_8 more like On/Off-Left/Right rather than 2 individual buttons.


Ch 6 is the red/lld stick gesture not a button. There is no channel 10.

The older controllers had the expert button on top. It was very convenient for arming and disarming. It seems you have a trim style on off for arming on this new model


I think I found the missing piece.

I did not realize I had to match the definitions in the NFE Fork to the Stock TX if_def you shared.

NFE definitions:
#define ARMING CHAN_5
#define IDLE_UP CHAN_5
#define IDLE_THR 0.05f //This designates an idle throttle of 5%
#define HORIZON CHAN_8
#define PIDPROFILE CHAN_9 //For switching stickAccelerator & stickTransition profiles on pid.c page
#define LEDS_ON CHAN_10


Yep and you can move those around however you like too.


We could look into switching some computations into fixed point math instead of floating point. Surely not all of the math needs the precision and dynamic range of 32-bit floating point numbers. The Rx stuff and rates comes to mind first, but more than that would probably be necessary. It would probably be important to stay in fixed point as long as possible before having to jump back into floating point (converting back and forth could easily negate the gains).

ARM has a pretty good fixed point document available:


Great work getting this going and sorry for not responding to your initial request sooner. USing the stock remote was something of a curiosity for me but was always planning to go to a multiprotocol if it worked. You clearly had better staying power than me - great work.


So I messed around with level mode algorithm tonight… Just for a change of pace. I came to a determination that level mode max rate is essentially useless. Angle pid sum is a product of angleerror which is a product of errorvect which is limited to 1.0 … So the angle mode pid output can only reach as high as the angle P setting … Which is a long way off from our value of a couple hundred degrees per second.

Anyway, I decided to run two angle pid sets and calculations … And do a transition between them based on angleerror (since it goes from 0 to 1). I use the high level p set for small errors and transition to the low level P set as error increases. The result is super snappy and crisp … But gets comfortably softer if you stick bash- less out of control and keeps things from freaking out when you clip a gate (high level pids were bad at this before).

Anyone want to whoop it?


Yes please- if you think it’s cool to use on a boss. Just this evening I was experimenting with angle mode settings on my e011c boss builds, 7 and 7xl, ended up in pid.c and then adjusted settings based on the 7mm boss info in there.


Sure. NFE Silverwared B03Pro with 716 motors with OTX multi. Not a coder, but can do edits. Would like to have Level mode with Racemode on a switch.