Micro Motor Community

NotFastEnuf E011 / Bwhoop Silverware Fork


E011 takes E011 target, E011C takes bwhoop target. You switch targets in config.c by using the //. The board in the list without the // is the one you have selected. By default it is the Alienwhoop Zero. So you would place a // in front of that board and remove the // from the board that matches what you have.

Same thing for the receiver type. By default it is sbus. So put a // in front of sbus and remove it from bayang telemetry autobind.

Once you do that, compile & flash, and you should be good.


Thanks for help will try after work


All done thanks but just having trouble setting channels for flight modes chanel 5 does led on off cant get anything els but rate mode


That’s an indication that your module uses different mapping for aux channels.

If you’re on the default of use_multi… Then switch to use_devo… Or vice versa


New Firmware Double Kalman is awesome ! Tested Outside at -31c with some wind and it even better than the previous filtering system .

Raw Footage with music . Thanks NFE !


@yets … What I’m working on next may impact you the most. I’m restructuring the hierarchy of header files to defines - including hardware -including targets (a new file) - including config. This daisy chain of headers will allow us to define anything in config and carry the influence of that selection all the way through the other headers. The end result is that it will be super easy to add a new target and have it be all inclusive for any setup related to the board (including changes for brushless vs brushed). It will also be pretty easy to “build your own profiles” in the config file with massive #ifdef’s. You could essentially have your favorite config setups matching to your different builds on different defines up top … And then it would select the matching config settings in an ifdef below to that define. All your flying things on one project.
Where we fell short before was a selection in config couldn’t influence hardware.h, and we were desperately in need of a targets header.
Not sure if I explained this well so you may just have to see it in action…but I know you are trying to keep alot of the legacy stuff in place and I am gutting it in favor of new stuff and a new layout. I plan to start including the brushless targets as well so if you want to stay on board… It may be easier for you to just start with a whole fresh copy and move back in any legacy stuff you want. Thoughts?
I am also looking into the keil targets options feature as a way to select different mcu… So we may even be able to have all the ports to f1,f3,from contained within the same project.

This is another thing that needs discussion. Branching out to other mcu opens the opportunity to have black box, osd, osd configurator, USB support… The list goes on. But at the heart of this is a configurator and the restructuring necessary to support changing settings at runtime. So what do we do…does this project just grow into that … Or do I put a freeze on the stm32f0 project in it’s current form.


@NotFastEnuf Thanks for the heads up. To be honest buddy, once you kick this update in and start with the brushless, I’m probably just going to stop with the Brushless fork. The changes sound like they’ll be great addition to your fork and I only started doing all the legacy stuff as you were focused heavily on Brushed. But if you intend to start highlighting Silverware as a brushless option (which I really hope you do), I have no need to carry on :smile:

In my opinion in regards to the project on whole which isn’t worth much, whatever route you take I hope that it continues to be accessible to every pilot that has come along the Silverware journey. Oh, and to defo keep the feel of Silverware (flight), that’s bloody important!


So true ! That Feeling is an addiction !


I am committed to keeping the feeling in tact… That’s why we are all here… Myself included. And yes, accessibility is always a priority. If this all goes well for what I Invision, adding new targets should be easy - which will include the piles of previously non silverware fc’s we have all accumulated that are being quickly decommissioned by a growing betaflight.

I’m still just not sure if I should start a whole new project for f1, f3, f4 and leave the f0 project as a separate entity… Or lump it all together. Maybe I’ll just have to see how it goes.


I just really don’t want Silverware to turn into Betaflight. Let’s have less features, but better.

My fear is that we abandon F0, and are requiring more and more powerful hardware. And suddenly we need to buy a frickin $80 FC (*cough*newbeedrone*cough*)

I like Silverware because it runs on $8 worth of gear and puts all the Betaflight options to shame.


What sier said.

In think that’s one of the reasons of the popularity behind silverware, the cheapness of it all.


Well it’s cheap and it performs well in flight, 2 very strong points.

I would be all for dropping the toy features that are better suited to off-the-shelf LOS quads e.g. use stock tx, stock tx autocenter, lvc_lower_throttle, stop low battery, flip sequencer, startflip. For those quads, standard code can be used if those features are needed. Does anyone use enablestix I wonder?

Some things could be hard-wired on, like yaw fix, transient windup protection, tx power. Just ideas to slim out the large number of selections that exist. The simpler the better.


Would supporting F3 potentially mean flashing via USB cable? There’s lots of cheap F3 boards about nowadays and people wouldn’t need to pick up an STLink programmer.

Even things like the ability to run an OSD would make everything more accessible, without needing to touch the core code, you could then even shift the config to the menu without needing to recompile to make changes.

There’s quite a bit of floating point maths in the code base, if nothing else wouldn’t this be better run on a chip with an FPU?


This is a good discussion, and exactly what I had hoped to inspire… Please let’s continue it and get as many influential opinions voiced as possible to guide where this goes from here.

Regarding price: many of the non f0 FC’s I own were all under 10$. Just hop on AliExpress and check the price of a naze32 or even better a cc3d… A board with already broken out spi and swd pins. And nothing is more silverware than swapping on a f3 in place of the f1. Beyond that are piles of cheap f3 and f4 FC that can be purchased with osd chips already on board for 10 to 15 dollars. Just imagine what is going to happen to the price of the f3 based FC as betaflight discontinues support as they have done with the f1. The opportunity to grow and expand the breadth of silverware is not one that need require any additional money to be spent for the price concious, but there are many new silverware pilots being added everyday that are here just because it flies well. Isn’t it time we see silverware taking podiums in multigp events? We are not going to get there on a bwhoop FC hot glued into 5" racer. Not to say it wouldn’t be capable, just saying it’s not likely to be adopted until higher quality boards are readily available. For example last year at the Tiny whoop invitational race thrown by Jesse Perkins - there were no bwhoops or e011s competing for the podium … But this year over half of the top 10 qualifiers were flying silverware and podium seats were won on this firmware because of the introduction of new hardware in the market. You have all contributed to that here and those wins are a feather in your cap too.

Regarding features: my focus is two fold. Flight performance and accessibility. If it flies well we want it. Otherwise it’s fat. The one exception to this is if it impacts accessibility. This is where supporting configuration via osd, USB flashing, or anything else that makes it easier to use also becomes a priority.

Regarding f0 support: we have two choices… Either start a new project so that both our current one and the new one are available … Or lump it all together. There are many creative ways to mod a toy board for lots of advanced features … The only limit is the number of mcu pins that we have access to. Fortunately the designers of those boards are in love with LEDs so removing a few of those gives access to quite alot … I’m not against back porting some cool new stuff to f0 if kept in a separate project, and I’m not against keeping it in either… It’s not that far off from supporting f1 given the usually i2c gyro (except cc3d) and need for a USB/uart bridge for connectivity.

Regarding the need for change: Floating point units, more timers to move things out of the loop and on to DMA, more processing speed, black box logging, spi gyros in place of i2c… Guys we are out of time in our loop and already have to overclock to stabilize a 1k loop. There is no more room to advance. We are short the number of pins we need in a tssop20 to keep our spi receivers and add a superior spi gyro to our designs. I think it’s time to push the envelope of what our firmware can really do.


Great news, I was hoping you’d say something along those lines :slight_smile:

I do think branching the project or starting from fresh would be a better way to go, rather than litter it with preprocessor in an attempt to get it to compile for both boards.

Would there be any more complexity with F3 due to the fact there’s dozens of different models of F3 whoop boards about, whereas there only seemed to be a handful of companies manufacturing F0?


…and how about turtle mode? No pins for that on tssop20 either… Lord if I only knew where all this was going I would have started out on the h8 mini 3d…and may have even skipped right over f0, cause keep in mind that’s a gd32… Clone of a f1. So it’s not like silverware is only for f0.

@Ian444, there are still many pilots worldwide using toy transmitters. I can’t cut them totally out. It’s one of the reasons I’m considering a new separate project so that all that toy code can just stay in it’s box. The toy auto flip however I think could also be adopted into a far superior turtle feature so there may be some hidden gems in some of it.

Thank you all again for participating in this discussion - don’t bail on me now. I can’t pretend to know the best way to approach this by myself - I need your ideas.


Ease of adding a target is one of my priorities. I’m certainly not going to add them all on my own, but I want it to be easy to silverize any board just by adding a target file for it so that anyone can contribute and the project grows.


Things are getting cheaper and cheaper in this hobby. That’s what I noticed since I was beginning in toy quads 3 years ago. At that time you need 70$ to get a micro aio fpv. I feel like this is a good time for Silverware to be used outside f0 because micro brushless builds, boards with built-in osd, turtlemode, and many others, are so popular. I have a beecore v2 and I feel like it flies like a fat chicken compared to NFE silverware. We really need to put Silverware on other fc so that they’ll fly like a Boss😎


The idea of backporting changes to F0 rather than trying to keep everything under one codebase seems to make more sense to me. (Basically, you would have NFE Silwerware for F3/4 and NFE Silverware Lite for F0). I too love the fact that my $13 BetaFPV Lite board is competitive and fun to fly, but it really does sound like Silverware is running right up to the limits of the F0 chip.

There are so many old F3 boards out there that the Betaflight codebase is leaving behind. It would be awesome to breathe new life into those with Silverware. Even if it’s just porting the existing Silveware codebase to the F3/F4.


Good morning! Stock TX question (e011c, most recent NFE)- I cant seem to get anything other than what acts like horizon mode. My channels also don’t seem to work on the stock tx, but gestures do. Anyone experience this?