NotFastEnuf E011 / Bwhoop Silverware Fork


Regarding led behavior… if you have a taranis with a geobish module and use_multi defined instead of use_devo… you will get a led that turns on and off with the arm switch due to the channel mapping mismatch between devo and multi.

@yets I think opposite… channel off is profile a


That makes more sense… Thanks.


Sorry I have a noob question after finally getting into it tonight. For a stock Boldclash Bwhoop B-03 pro using stock controller, I have chosen:
#define BWHOOP
#define USE_STOCK_TX
no other changes

Have I got the radio protocol and transmitter type selection right for the stock tx? Are there any other changes required?

Also what are the gestures if any to bind? Change to acro if needed as I only fly acro?

Assuming I can handle the learning curve I will try add an SBUS receiver soon. Thanks in advance and for all the hard work. I think I will pick up a zero as well but I wanted to at least get an appreciation first.


For the gesture go look here


All of my gestures are different. Best place to get up to speed on that is the alienwhoop zero manual.

You selected the wrong receiver type. It needs to be standard plain bayang for the toy transmitter. No telemetry or autobind. Also, it is going to arm and switch between acro/level or other flight modes using the different trim buttons and the old flip button and such. I believe in the aux channels section of config I give a key in the notes as to which button matches to each chan_#. This is how you will control features. You may want to consider putting the rates option on a switch instead of being on high all the time. The toy tx is very hard to fly with unless you extend the sticks.


Thanks Travis think I’ll get the toy remote going for proof of concept and will then get a spare xm receiver hooked up in short order for SBUS.


I’m afraid I still cannot bind to the toy transmitter that came with the bWhoop B-03 pro:

// *************Radio protocol selection
// *************select only one
//#define RX_SBUS
//#define RX_DSMX_2048
//#define RX_DSM2_1024

// *************Transmitter Type Selection
#define USE_STOCK_TX
//#define USE_DEVO
//#define USE_MULTI


Maybe try this - type in “#define RX_BAYANG_PROTOCOL” and comment out all the other protocols. The stock controller doesn’t have telemetry so maybe that’s the problem.


Thanks Ian, I forgot I removed that one during a recent housecleaning.


Did you mean to remove the BLE_APP which is used for Silvervise app? Unless it works with the BLE_BEACON?


No, and to he honest I’ve never messed with any of that. I was just trying to clean up the rx options a bit… and chucking the toy tx seemed reasonable since it’s a pretty terrible experience to use it.


Is it worth reinstating the BAYANG_TELEMTRY_BLE_APP as it’s still viable as a means to see telemetry and PIDs on Android devices? It’s pretty helpful for PID tuning if you like to see the numbers. You could get rid of the BLE_BEACON as that’s pretty much redundant.


Cheers Ian, will try that tonight. As I said will be good for proof of concept.


agree. instead of dropping the silver VISE telemetry, it could still be nice to have Telemetries switchable / between silver VISE and Devo telemetry or something…


I do like the idea of the switchable telemetry, but I want to knock out the spi gyro for @Ian444 first then examine a configirator. I’m still not sure how I want to pull off a configirator though… hence my recent stall in development. BLE, osd, serial, total rewrite using msp… I want lay groundwork that’s relatively futureproof… possibly even to ensure that the next stage of development gives us access to all flight controllers eventually. I’m just torn between utilizing the groundwork laid by multiwii and totally reinventing the wheel.


Well, I’m pretty sure the multiwii path is not what we really want. it’s been there, it is there, it will be there, - but Silverware has always been different. I think we should stay different. SilverVISE Is a nice app, if we could use it for configuring things, it would be nice. But to be honest, since we have PID gesture tuning, dual PIDs and stuff like that, I usually flash a quad once or twice, then it’s done for a long time…
Also, using a classic Configurator may mean to have all options actually compiled in the code and flashed to the MCU. 32K would not be sufficient I guess.

So: keep Silverware as lightweight as possible. ‘heavy’ FCs including huge config stuff sort of things are already there.

I agree though that KEIL is not everyone’s taste, so what if it would be possible to compile and flash via a mobile phone (android? because it runs sorta Linux machine?)
SilverAG brainstormed once something similar, so SilverVISE could be used as a ‘configurator’ which allows to select various filters, channels, etc - which you currently set up in KEIL by text. Then push the button and it compiles the hex you want to flash :slight_smile: Just some thoughts…


I thank you for your thoughts! I’d like to take a unique approach like some of the things you suggested for f0.

Then do something totally new borrowing the best from silverware, betaflight, and open pilot using msp for config which is aimed at f1 to f4. The plan is to call this project Quicksilver.


hi there…! really need help sinced I flased my e011 flash with nfe silverware, when armed n increase the throttle yaw spin directly, any mistake with my silverware setup need your ig big helf :roll_eyes::grinning:


Go to the releases tab of my got hub and read the notes on the stick gestures for the zero. It is configured props out and you are likely props in. You need to input a stick gesture to switch it and another gesture to save. Down up down then down down down. It will fly fine then. :slight_smile:


i see… thanks a lot bro, will try n test after it :pray::pray: