NotFastEnuf E011 / Bwhoop Silverware Fork


What is the gesture for Alienwhoop zero motor filtering on switchable feature 1? The instructions at the bottom of config.h appear to be a work in progress, so I’m not sure, as the stick travel check uses RRD and LLD which I’m guessing is a switchable feature also?


You and me both. I still have not been able to get stock silverware to work. But I can do it in my own fork. Baffled

I thought is was connected to one of the leds?? I’m confused again!

Download a new copy… it’s updated now. I made a summary on the releases page of the stick gestures. But the filtering switch is RRR. Then DDD to save. Props out/in is DUD, and LVC forced Landi get is LLL. Save of course.

I rather hope we can get stock silverware sorted. I’m curious as to what I’ve missed. Agreed it’s just a matter of free time. Its Hard To Come by


If I’m reading the code correctly Alienwhoop zero filtering is SWITCHABLE_FEATURE_1 which diverts to RRR in gestures.c ? I’m just guessing here.

*ha it seems the man himself beat me to it. But I appear to not be completely stupid! :wink:


@Ian444, regarding switchable filtering, it’s just the motor filter currently which I don’t even use on brushless but can create fantastic results on brushed. I do have some code I could provide to you to paste into filter.cpp that will switch the 1st order gyro lpf frequency. That might be a bit more useful for brushless. We could do the d term also and build switchable filter sets. This is why I wrote the base code as a generic switchable feature. So maybe @yets could incorporate the framework and then we could go back and build whatever features work better for brushless vs. the ones I’m using for brushed.


Heh. I’m actually finding a few of your changes difficult to implement on the brushless fork… I need to add the zer0 target. I was reluctant as I didn’t feel that those who purchase such a board which is basically probably the pinnacle of a brushed whoop FC would then try to turn it into a brushless FC. Anyway, so it needs to go in and then I need to work out a few things and definitions not working correctly.

I do have a question though your SPI/Serial code for SBUS. Before the changed code, you were able to connect using SIlver’s code. With the new changed code, are you still able to connect using that method/code? Are you locked in to doing it serial only?


No I use spi on a zero. I’ll download your latest fork and take a look.


I was in the middle of updating it last night but I gave up, I need to rewrite the board definitions and maybe move the protocols/boards the hardware.h/config.h etc. I encountered a few issues with the SBUS protocol with the changes. Will be doing it Thursday/Friday anyway, just a bit busy…


Hey @NotFastEnuf, Any chance you can restore “#define RX_BAYANG_BLE_APP” as an option on config.c? I use this one to communicate Silvervise.

#define RX_BAYANG_BLE_BEACON doesn’t work for me. Using BAYANG_AUTOBIND_TELEMETRY with no issues.

Otherwise, great work as always!

BTW - Loving my 6mm 25.5k BOSS build! Amazing amount of power out of those 0617s!


Yeah just paste it in there. It’s not gone, it’s just not typed out.


Not sure if this will help, but if I comment out this line around line 230:
if (gettime() - flagged_time > FAILSAFETIME) framestarted = 0;

then I can get a bind, but lose failsafe. Maybe a clue, not sure?


Switchable filter sets sounds good, like switching/scrolling between weak/strong/very strong for example, as they are all customizable, they could be aligned for filters of interest at the time.


I tried for days to get kalman switchable but it is a little island of c++ code in our c system… and I don’t know c++ yet. It has a special function that only runs once that I would need to trigger to run again when we switch or when flash memory is loaded. But what you describe is feasible with the standard adjustable gyro filters, d filter, and alpha2 motor filter. I also want to do some more testing to determine what effect crunching all this live has on looptime. Obviously I have a lot more going on in my fork already and am at a point where over clocking is necessary to keep the loop pegged at 1k. It never ran 1k anyway in the main repo but I am curious to see if all my “features” extend it out further. If so, that changes the effective cut frequencies of the filters… so I will be overclocked from now. It’s been tricky to sort that. For example if i poorly coded something that pushed the loop time longer, a 90hz filter could actually become a 70hz filter. So it may seem cleaner and smoother … but it’s deceptive. Moving forward, I’ll be doing more experiments to optimize my code and figure out exactly what types of features strain the loop stability. We have it locked down at 1k now, but before we dive too much further into “configuration on the fly” instead of at compile time … optimized code is going to be critical … and I already played the overclock card.

Good work on uncovering a clue with dsmx. Maybe after we solve it’s functionality in standard silverware we can query silver for some insight about why my fork runs it ok and the main repo requires a different approach.


I would like to help but I do not know much English, I will be testing every update that you do but I do not know how to describe the results.

Versions would help to be able to compare, like NFE 1.1, 1.2, 1.3.


There are versions on my releases page. I like to name them. Right now a comparison between “genesis” and “berzerker” would be very helpful!


Working on that


Hello Ian444,

In march (maybe things changed already) you said that the new E011 board cannot be flashed. Do you know why and if it would be possible to make it working with silverware ?

I would buy some BO3 pro as replacement but they are sold out where E011 is available everywhere… and don’t see other alternatives in those prices, do you ?


Silverware requires a specific processor, if that processor is not on the board, it’s a deal-breaker. A good search term is “B03 receiver board”.
Also have a good price at the moment, and there is also the Betafpv Lite but the pads for flashing are very small. There’s probably other options in the lower price range but I haven’t been looking for a while.


Thanks for answering so fast !!

If I understand well that means the new board doesn’t use “stm32…” processor. And thanks, I didn’t know about tmart and they do have some complete B03 pro on stock, that what I was looking for, even more after learning that E011 is over now.


betafpv lite
beecore lite


Yep ! thanks !
But I’m looking for complete drone with a Tx as Bwhoop B03 pro is and E011 was.