NotFastEnuf E011 / Bwhoop Silverware Fork


I currently consider whatever is coded for the feed forward pid controller broken code. I’m having the same problem with the code I adopted as I did in my own attempt at writing feed forward. Every time a stick touches the neutral line on an axis … it activates feed forward. This is the wrong time. It should only be going active on quick motions. So something must be wrong with the qualifier … or something that happens when a stick touches neutral must produce a large derivative of setpoint which meets the qualifier. I’m not pulling the code out cause I want us to examine it and find the flaw - it’s a wonderful idea in theory. But it’s currently no good.


So … aside from a feed forward flop … I do have some new new goodness for you all to try out. Now on by default is VBAT PID COMPENSATION!!! Pids will automatically be increased as your battery sags/drops in flight and overall flight characteristic should remain much more stable. I have set the boost up in pids to be 33% higher by the time voltage has dropped to 3 volts. In my tests this seems like a good default value. If you want to try more or less … you will find that setting hidden in pid.c. Otherwise the feature is available to turn on or off in config.h in the voltage section. I think 33% increase in pids as battery drops is a good starting point. This took about 90 to 95% of the slop out of my e011 test rig as I approached a dead pack.


Anybody knows a way to get the telemetry working on Goebish DIY module + Stock Taranis Q X7?

A guide would be helpful. :grin:


Trying to verify pids after flashing with latest binary and noticed that no matter what numbers I plug in or use in pid.c (then compile in Keil and flash with STlink Utility) seem to make a difference when using @sier’s

Not being able to read hex, I don’t know how else to verify what is being programmed into the FC.

@NotFastEnuf - I can tell that some stuff is definitely updating because I did enable the Feed Forward and I could see blinking leds with every twitch of the TX. The LEDS were off when there was no stick input, but immediately blink with the slightest twitch of the stick…

This is the output of
It never changes.

​Simon’s Silverware Tools for macOS


ROLL_P: 2.67e-01, PITCH_P: 2.67e-01, YAW_P: 9.50e-01
ROLL_I: 1.20e+00, PITCH_I: 1.20e+00, YAW_I: 8.00e-01
ROLL_D: 1.62e+00, PITCH_D: 1.62e+00, YAW_D: 7.00e-01

Accelerometer calibration data:
[13.24460506439209, 66.27589416503906, -8.9573974609375]

The PIDS translate to this selection:

//BOSS 8.0 - 816 motors, kingkong 66mm props - set filtering to WEAK_FILTERING
//float pidkp[PIDNUMBER] = { 26.7e-2 , 26.7e-2 , 9.5e-1 };
//float pidki[PIDNUMBER] = { 12e-1 , 12e-1 , 8e-1 };
//float pidkd[PIDNUMBER] = {16.2e-1 , 16.2e-1 , 7e-1 };

Is it possible that these PIDs are “hardwired” ? I am not selecting these PIDS at no point, but the viewer app reads these off my FC…


I’ll leave that to Simon… clueless…you’re speaking another language that I don’t know yet.

I can say this though … feed forward is a bust in its current state. Disable it unless you plan to test & edit code to try to fix it. That’s the only reason it’s there for now. …it’s a project.


The viewer shows you the PIDs that have been saved to flash via stick gestures. That can differ from the ones you are currently using if you have flashed a new firmware with new PIDs and didn’t use the save gesture after that.

I hope my explanation makes sense. Long story short: use the save gesture and my app can pick up the new PIDs :v:


With features like this, it seems like it could be important to get the battery voltage calibrated correctly. I tried using the automatic voltage calibration settings in config.h, but noticed that I could only get the voltage calibrated for one side of the battery or the other - at high voltage or low voltage. There was not just an offset, but a slope difference, too (and probably a curve, too, really…).

Until now, I used the settings on my Taranis Q X7 to calibrate out that slope and offset, as @chime13 and @Ian444 mentioned earlier in this thread (something like the Taranis settings mentioned before of “Scale: 10.4 and Offset: -2.62 but with the default scalefactor of 0.001364.”). Also, I noticed that I had to tune it different for my E011 board than my Beta65S Lite board.

This weekend, I added a feature to use a two-point battery voltage correction to config.h and drv_adc.c. It accomplishes the same result as the Taranis correction, but will work with any transmitter and allows the corrected values to be used for LVC, VBAT PID compensation, etc. I take measurements with a multimeter and then read the telemetry value for two points - with a full battery and a weak battery (say, 4.2V and 3.6V). Plug all four of those values into config.h and it will correct the slope and offset of the battery voltage “curve” (it is actually a linear correction). Now the voltage is (mostly) correct across the whole voltage range of the battery.
For Taranis people: now my Taranis voltage scale factor is set to 6.6 (which is what it should be for the 3.3V reference) and the offset is 0.0.

My two boards, an E011 and Beta65S Lite actually need different correction factors. I already build different binaries for them, so it’s not a big deal to keep their correction factors different. I don’t know if all E011 boards are similar and can share correction factors, etc.

Here is the pull request with the changes:

Any comments or suggestions?


Only to keep up the good work! I think ballpark values get the job done for defaults on pid vbat or throttle vbat so it’s not critical… but perfect doesn’t hurt! I have intentionally tweaked these features to values that won’t cause problems even if you’re a little off … but if you get voltage dead on you can probably push them up even higher. Very nice work. I’ll merge in the change this evening when I take another crack at a new pid controller!


I figured that was probably the case. I’m glad you’re thinking of that kind of thing!

I don’t like seeing my telemetry off by the 0.2 V (or more) I was seeing, since I have my Taranis set up to warn me when the voltage is getting low. Being in the code means I can get the bonus benefit of accuracy for other functions, too.

BTW, I’ve run several packs through the latest code and haven’t noticed any issues. I didn’t try the feed-forward stuff yet, but I think I’m still too new to notice the fine details in those kinds of changes, anyway :- )


Feed forward in its current state is a bust anyway… but testing it has helped initiate discussion over on rcgroups and the acknowledgement of some flaws in the approach… which is exactly the purpose of a beta testing fork like NFE. End result is a new implementation which I will port in soon. So stand by on that. Also… it gave me my own idea for what I want to do with the pid controller that i think will meet our our needs/wants in just one system. Which is something I am really excited about. I’m gonna try to code it tonight but I think many of you will be very excited! More to come on that soon… (yes another nfe teaser) :slight_smile:


Hey @brianquad, Trying to implement your 2 point voltage correction, I get a warnings compiling dev_adc.c

I get the following warning:
src\drv_adc.c(106): warning: #1035-D: single-precision operand implicitly converted to double-precision

src\drv_adc.c: 1 warning, 0 errors

Don’t know how to correct it. Otherwise it’s fine.

Nice job - can’t wait to try it!


Are there any stick gestures or anything else that might have knocked me out of horizon/racemode? I used to be able to steer almost completely with yaw when it was working but now my angle of pitch does not adjust to maintain forward angle. My TX switch positions have not changed.


Yes, I recently changed the default from use_devo to use_multi which changes the order of the auxiliary channels. If you didn’t catch that change, your aux channels are all mixed up.

What radio/module are you using?


QX7S and an IRX4+


Did you used to change use_devo to use_multi before you flashed older versions? If not, change your designation back to use_devo.


I’m pretty sure I had it working in multi. It might be a hardware issue like a failing motor because it seems to kind of work, just feels sloppy. I’ll flash an identical quad and check it out. Thanks.


Good catch, @chime13 ! I’m a bit notorious for ignoring compiler warnings :- )

Replace that line with this, which makes sure all of the constants are interpreted as single-precision floating point values:


I’ll make a revised pull request (how embarrassing!)


Could be for sure… I have not edited anything that should impact flight characteristics for racemode (while in the air - I did mess with on ground behavior on integral windups but pretty sure all that is working) and recently set up a few gates in the garage for a racemode rip. All was well and flew as expected - that yaw stick is the one that gets the job done as you have noticed - but I will give racemode a good thrashing tonight just to make sure before we press forward with any more changes. Default pids have changed a little towards the cleaner side (slightly lower for 7mm builds but higher for 6mm) and mix increase throttle max strength default is at a conservative 0.2f to prevent problems for flyaways on big prop builds … I am turning that up to 1.0f when I flash a fpv whoop, and the use_devo to use_multi are all the biggest changes which might really throw you off. But please keep us posted of your progress in resolving the issue. It really helps myself and others to hear about the unexpected behavior and eventually the fix that resolved it. Thanks for speaking up too on checking if it could be firmware - at the rate we are changing things that is a very valid concern and often very very helpful information to me when I am making changes! That sort of attention to detail and willingness to speak up makes you a valued beta tester! I do have a big change coming up here with the pid controller … I’d like to wait till we have you all cleared up before rolling it out so i keep you in the game!!

Just to really point out how valuable you guys are when you speak up like @DonnieH801 - most of the mistakes I have made in coding stuff have been uncovered as many of you pointed out some small change in expected behavior. When you do say something - I am dedicated to double checking - attempting to replicating the issue - and very appreciative of your involvement because it is exactly this interaction and the important roll you all play in this project which is keeping it all “on point” as the best whooping experience on the planet!!!


On a side note, as the list of targets increases that my fork of silverware supports … I wonder if it isn’t time for a new name for this thread and for my fork???

Maybe something like NotFastEnuf STM32F0 Silverware Fork? What do you think? Any suggestions for a new name? The e011 is basically out of the game except for the old boards we have accumulated, most of us are ordering betaFPV lites, and the release of the zer0 is coming soon… is it time for a change?


NotFastEnuf Boss SIlverware Fork.