NotFastEnuf E011 / Bwhoop Silverware Fork


Same as any other board, just choose BWHOOP board in the board selection define in config.


Guys, heads up if you’re hunting for some Silverware T-shirts and other fan stuff.
20% off at Sept 5 and 6 here:

Code: ANY20


This thread has been really quiet ! Anything special going on @NotFastEnuf


Been working on some new DSM bind code for the zero. The new format will still include the “bind tool” on TX1 as a backup UT, but will also include a feature where RX1 starts off in bind mode too. This way a new Zero will automatically put a rx in bind mode without having to move from tx1 to rx1. Then after binding is complete, a stick gesture can be issued and binding pulses will no longer be sent…

This should mske it possible to build no solder necessary bind n fly whoops. Customer just binds up, issues the stick gesture, and it’s all set.

Rexently we created our own bayang RX and made on on board bayang receiver version of the zero. Maybe we will do the same for dsm and frsky. Not sure. I think focus is shifting now to spi gyro instead of i2c and maybe the beginning of a serial configurator, usb flashing, and brushless or brushless aio. First I want to take a break and work on adding software spi support and bayang to betaflight. It’s the perfect multirotor radio protocol. I’d also like to mod the protocol for extended range with behavior similar to crossfire. Oh yeah, I need to add crossfire support to the zero too. So…I’m keeping busy.


Thank you NFE ! For this awesome feedback ! Thats some good news about the bayang rx , would be really amazing to be able to use it with betaflight / butterflight !

Thank you again for all the work you’re doing for the community.


Oh btw my @NotFastEnuf !

I did many experiments to get toy grade fc with Silverware to hook our own rx ! Its now officially working perfectly on the E011c ! Im presently using DSMX on my Santawhoop ! Thats a Great news for low budget people :slight_smile:


Here @NotFastEnuf


Oh SirDomsen ! i didnt take time to check you merchandise ! Thats really awesome bro ! Loving it ! We all Silverware pilot wear those brand ! Thank you very much sir !


Hi everyone, ive been playing with silverware firmware its so much fun love how it flies. I just had little difficulty configuring my tx wan tjust fonud if u use original nrf24 module from Goebish u need to define USE_DEVO in config.h and not USE_MULTI.
I was thinking of making a lua script who handle stick gesture if anyone interested let me know.


Trying out the fork on a betafpv lite FC, everything working as always. However, and I experienced this with my E011 on certain versions – I can’t get the LEDs to turn on while armed. They turn off as soon as the FC is armed, but they DO flash for things like stick travel check and gyro calibration. I seem to be running into this on all my FCs as of late.

Defined it as a BWHOOP, using DEVO, using BAYANG_TELEMETRY_AUTOBIND…

Is there anything else I need to change? I tried CHAN_ON for LEDS_ON, I’ve tried CH5 (which is my arm switch), I’ve tried a few other things. No dice.



I’ve noticed the LED turning off too with some firmwares but never kept notes to track down where or why. The fix is to comment out or in (as applicable) #define LED1_INVERT so I’ve just been doing that. If you are running 2 LED’s do it for both of them.


Unfortunately I tried it, no change :-/. In all cases, before I did this and before…all the other LED functions work…just not the solid LEDs that should be on when the copter is armed…hmmmm


That define has to change the LED behaviour when the quad is armed. Maybe you changed the line for a different FC, E011 instead of Bwhoop or vice versa? Or otherwise there might be a bug.


Double checked, all defines are correct. Going to mess about with it a little more and see if I figure anything out.


Did you try it both ways?


Ian444 – I re-did it again, and …as you said it would…it worked. I’m not sure exactly what went wrong. I think I just needed to close the previous file out when I programmed as it very well might have been programming the same hex file back when I thought it was switched. Thanks man.


No worries, glad you got it sorted out, as I had run out of ideas :wink:


I have been playing with led behavior to help me identify versions of firmware in support for the zero. Currently when you have it set to off… it will be on. Lolz. Sorry for the confusions.


Actually I got that all wrong sorry. If the LED is off instead of on when armed, the line #define LEDS_ON CHAN_X needs to be changed from OFF to ON, or ON to OFF, or your switch positions reversed if using a radio channel and a switch.

Commenting or uncommenting the line #define LED1_INVERT inverts the behaviour of the LED during powerup and looks weird if not set the right way. It does also “fix” the “not being on when armed” issue but looks unusual on powerup.

Hope I got it right this time.


Actually @NotFastEnuf, if #define PIDPROFILE CHAN_ON is the profile set to A? I’m sure it is, just wanted to be 100%