NotFastEnuf E011 / Bwhoop Silverware Fork


Hi… Im not familiar with mosfet things… Can i just take off the front led and change with the new led?


Well that depends on the amount of current that your new led consumes. If it is moreally than can safely flow through the mcu, then it could damage it.


Ok new update , after a lot of trouble with one of my silverware build and throttle issue and TBS clone props . I decided to build another one mess a bit with setting . First thing first i did use classic Eachine 31mm 4 blades then went for props out , no motor curve and NFE pids , adjusted voltage and finally increased my idle up to 7% for some reason now everything is perfect oh i also swapped the crystal and antennela under the fc . Now its really perfect beside one thing … But its another story about my H01 cam getting Rear view safety line … Lol - thx for this awesome firmware .


Glad to see this is a problem for others, not just me. The lights stop flashing and I assumed I was auto-bound but could not arm without going into the model menu and selecting ‘bind’… Still having issues with arming. Using an X9D+ on a Santa JJRC67/E011… not able to fly yet, just connect and have it wig out and flop over twice. Has only ‘armed’ twice that way. I figure I’m doing something wrong on the tx side.


I’m also having an issue getting my silver-santa to arm… I have gotten it to ‘bind,’ seemingly automatically (x9d+), but not really. It has ‘armed’ twice by my choosing [bind] in the model menu… looks like others have that issue too, ie problems arming/binding the santas. Having any luck?


TAER? @Jorn?

Edit: for clarity I am adding a note here …
Bayang needs to be AETR


Yes. Lipo to quad gets a medium led flash rate, tx on and leds go solid, switch set to ‘arm’ (the model is set to ‘bind on power’) leds flash rapidly. I go into the model menu and [bind], tx chirps maybe once, the leds on quad chill again and then the drone flips out and over trying for the moon or the earth’s core.


Following your sequence here…

At this point you are bound. No need to do anything else for binding.

This is a safety condition indicating that you are attempting to arm while your throttle is not below the throttle safety value (which is about 10%) because you are not mapped to AETR

At this point you have resent a bind sequence with your radio which is doing who knows what to your rc signals… but whatever it’s doing it is toggling your throttle low enough at some point to satisfy and get past the arming throttle safety… But when done your throttle is at 50% cause it’s on the wrong channel and whatever mismatched channel your throttle stick is going to is athe a full throw. Thus flip out.


  1. Once bound (solid light on fc) - do not attempt any further bind sequence
  2. Fix your channel mapping in your tx. Attempting to arm and getting a fast flash shows that your throttle is not at zero. Likely because you are not set in your transmitter to AETR. You will know when you get mapping right because arming the quad will not return the safety condition … fast flashing.
  3. Evaluate flip out after fixing these issues. Likely when you get your channels correct on your tx… behavior will be normal.


I apologize… I had to edit my above post to AETR.

TAER is incorrect and I believe it what the taranis defaults to which needs to be changed.


Thanks for interpreting the flashing for me. Inputs and mixer pages show TAER. I’ll make a new model and try. Sorry to bring radio questions to a fc firmware thread.


@Jorn no apologies… this is a support thread, not just a firmware thread. You are in the right place. Please see my correction above to AETR. Anyway, the safety feature to prevent arming (fast flash error code) is am alteration I made to the firmware to stop you from taking a tiny whoop to the face. Lol. So still a firmware related question. :slight_smile:

I fly a devo myself and the deviation community fixes all this stuff automatically for us when we select the protocol. That’s why it’s not fresh in my head. I probably misguided you before too… I need to dig back and edit that past post as well for others reading in the future.


@NotFastEnuf Copy. My tx is default AETR and I had my sliver-santa model set as such prior but followed a setup video that was other (TAER) while trouble shooting the ‘arm’ issue. Just made a new model and it is ‘binding on power’ and when I arm the idle starts low but ramps up. With no stick input the idle increases til hovering and counter-clockwise yaw crashes it and I disarm. (using Insane micro motors)


A certain amount of this is normal. Bad props or a bent motor shaft will cause it to climb excessively high.

What are you saying here? That is is spinning counter clockwise on its own? Or that you tell it to spin and it crashes in response.

Take some clear photos of your build showing props, motor wire connections, anything you think might be helpful. Something is wrong in your mechanical setup if it is spinning on its own after taking off… even if it is taking off on its own.

Also check your control inputs after arming but before adding throttle. Pitch, roll, yaw… give slow inputs and look for an indication it is responding properly.


With no stick input it hovers and yaws counter-clock, I can increase throttle and it cyclones up. It’s spinning on it’s own and so far I cannot counter it. Stick input levels appear normal ‘at rest’ on the tx, that is 0s (some twitch between 0 to -0.5) and throttle at -100 on the channel monitor.

I did position the motors in the frame like in my TWR and not in the spots like the Santa motors came. The santa came with b/w-counter-clock and r/b-clock motors in the opposite positions as my TWR. Here’s the layout of my build: from top (camera is not yet mounted obviously), and bottom

I did not assign ‘idle_up’ a channel on the tx and left it alone (thus on?) in the firmware, if that could be an issue.


So you have reversed the motor and prop directions from the original configuration.

You need to switch it back.

If you insist on running that configuration on that frame … you are blowing air against angled struts and it creates some horrible prop wash handling. It’s just not the right frame for that. However, if you want to see for yourself, then re flash and turn on the invert_yaw_pid option in the motor output section of config.h. It’s noted with a props out description.


Works. I assumed wrong about the motor/prop orientation and I must have messed something up while trouble shooting the model settings in my x9d+, lastly I didn’t understand what the different led flash rates were indicating and got weird interactions between craft and radio through binding & re-binding while bound. For posterity the issues were fixed by using the original Santa’s motor/prop orientation, cleaning goofy radio settings with a new model (set to AETR), and understanding the LED indications…

Thank you very much.


Excellent work @Jorn and nice summary! !


I’m planning to use micro flysky rx with my bwhoop fc, so I’m going to order that rx from banggood. That micro flysky rx has 3 pins which is GND, +5v, and PPM. But I don’t know how to connect it to my Bwhoop fc.


I just download the NFE silverware fork and the readme lists a few precompiled hex files…but i can’t seem to find them. Any hints? Thanks to silverxxx and NFE for all the hard work!


Looks like they are missing in the latest release. The previous release has them in the “bin” folder and they should be much the same as in the latest release, here:

Right click the hex you want and “Save Link as”.