Micro Motor Community

NotFastEnuf E011 / Bwhoop Silverware Fork


Guys - Embarrassed here - I honestly can’t make heads or tails on how to work in Github. I find myself cutting and pasting bits of code because I don’t know how to merge, pull or push. I know there’s got to be a better way. I did it once and now I can’t seem to do it again.
Ultimately, I’d like to be able to merge other’s updates and features into my fork.

On another note: I agree with @yets (NFEBSWF) pretty much covers everything


Yeah I suck too… what’s worse is you’re all flying my code. ROFL. :wink: But at least I have a pretty good idea of what the heck I need the code to do so it rips balls… and I get there eventually. Honestly I don’t know how gitbash is still a thing. My personal opinion is that there is a secret society of programmers somewhere somewhat like free masons or something … and they have forced this oppressive system on us so that true computer scientists remain relevant and deserving of massive salaries for professional work. Reminds me of a thing for android called MIT APP INVENTOR. You can basically use it to make almost any android app. All the preconfigured blocks of code are visually embedded into these puzzle pieces that are all nicely colored and have special shapes that only mesh together in accordance with the rules of good code. Building an android app is like playing blocks with my 3 year old. Sooooooo easy! Meanwhile back in the c coding camp… we are oppressed by the gitbash overlords. How is this still a thing. Seriously it’s 2018 for God’s sake.


Speaking of this … I think there is now a flaw in the way expo for horizon mode is being handled. When I first created horizon mode … I had not yet broken out separate expo variables for angle and acro. And after I did separate … I made a knee jerk decision to apply the angle mode expo variables to horizon without thinking about it much because it was a mode that had some leveling. It just now occurred to me that I tuned horizon mode at the time of its creation to my acro expo values and i think i need to restore it to using acro expo.

Its more of an acro mode with light leveling assist than it is just a leveling mode with the ability to flip. It’s behavior is dominated by acro type code and there is no way that can feel right as we apply minimal angle mode expo values to massive rotational rates.

I haven’t flown it in a while but my guess is if I do… it won’t feel right. Will some of you guys try it out at defaults … then copy your acro expo over into angle expo and see if it feels better? I think I need to switch the expo that horizon pulls in over to acro expo.


I’m one of them :sweat_smile: It think it’s beautiful, and a lot simpler than the weird GUI stuff :sweat_smile:

On the other hand, I’m completely lost with all this PID mumbojumbo and really want it to go away :joy:


I have a 6x15 build which has a weight of 16.1 grams including fpv. It flies perfectly with e010 props and hovers with 30% throttle, but it can’t descend with bayang x9 props even with zero throttle on idle up. I’m using eachine 260mah lipo and boss 6 tune and I’m in acro mode.


Comment out line 321… #define MOTOR_MIN_ENABLE

That’s another thing that increases minimum motor command. This could help!


I have been trying to find more information on attaching a frsky RX to the sbus on the E011 FC but I have been coming up short. So wiring locations and Hardware recommendations would be great. I have been looking to ditch my multiprotocol and have better range. Can you help? Thank you!


Well I’m gonna go out on a limb and say you are gonna be the first to attempt this in the world. So welcome to a journey into uncharted waters. I’m in for the ride… let’s figure out how to make it work!!

First thing we (or at least I ) need to do is get up to speed on the difference between a flysky rx signal and a frsky sbus signal. Does anyone have any links technical information which describe the output signal of flysky in detail. Is this ibus? I have no current knowledge base in flysky so I need to learn some stuff.

Which pins we are gonna use is easy once we know what the signal looks like and how to handle “hearing” it in code. You basically only have the clk programming pin as an option, or you could remove one of the leds and it’s current limiting resistor and grab a mcu pin there. But I have the feeling we are going to need some code to support. So maybe for testing… let’s keep it simple and use clk and a plug of some sort to be able to disconnect the rx as needed during the figuring this all out process.


I am new to this. So forgive me if it is a terrible question. I figured it has something to do with adding a fs-rx2a using the sx pins for com and power. It is also quite possible that this feature is not avaiable for this FC and I had it confused with another project you are working on.


Oh I misread… I thought you said flysky.

Frsky is in fact supported. Does that rx have an inverted or un inverted output signal?


Which would you suggest? I have not picked up an rx yet. I want to make sure I get one that is compatible. Oh and I am using a flysky fs-i6x (10ch) tx.
I looked as best I could and could not find any difinitive instruction on setting up an sbus rx on the E011 fc.


Well you’ve got me good and confused now. Lol. I don’t know what you’re trying to do. Flysky or frsky? And to be honest I don’t know a thing about flysky, and I only got my first ever frsky rx a few weeks ago.

So please be more clear… exactly what receiver protocol are you wanting to use? And is it an inverted or uninverted signal?

I use a r-sxr. Frsky sbus is supported. You simply comment out the bayang receiver protocol in the receiver section of config. and uncomment rx_sbus. Then you connect your signal wire to the clk pinhole… or if preferred the Dat pad below (since the pads have reversed labels). You can’t use sx because there is a resistor in line on the board that will mess with serial communication. Grab regulated 3v power and ground and you’re set. You will only be able to flash the board for updates in the first 2 seconds after it is powered up once rx_sbus is set. After that the clk pin will switch over to being your receiver rx pin beyond 2 seconds.


Please forgive my confusion, I guess I did mean a FLYsky (not frsky, my bad) micro sbus. An AFHDS A2 sbus (fs-a8s rx to be exact). It would be great if you could figure out if it worked. Sorry for all of the confusion.


OK gotcha. I have to do some reading about flysky and I will tag you with any updates.


In the mean time… anyone tested horizon recently? I don’t remember the last time I flew it and today it was packed full of oscillations on an e011. Still need to test other whoops and see if it’s just a mechanical issue or if I screwed it up somewhere along the way with all these recent updates.


i had bad oscillations with hv lipo on bwhoop pro3. just alittle throttle to lift off will have oscillation and wobble up to the roof even with sticks all the way down. i did changed pid gains abit and found out what caused it. it was from me adding yaw gain. lowered it by 1 and flying to the roof went away but still some oscillation.


In a leveling mode right @Whoopingtits??? Acro fine should have been fine…???


Well I had I gigantic post here that I just deleted.

New update in place of the old mess. I advise everyone to turn off pid voltage compensation. I’ll update the fork shortly to remove the define from config. I feel like my implementation of this feature has a critical flaw that is creating latency in the PID controller and somehow huge oscillations only in leveling modes. I hope to sort it out soon. I had made a bandaid for it last night but screw that … I need to get to the root of the problem instead of accepting it and covering it up.


Since I don’t use leveling modes, I have no issue - thus far…but I’ll keep an eye on it.

On another note:
Is there a possible conflict in config.h? (see below)

Can/should both be enabled at the same time?

// *************compensation for battery voltage vs throttle drop
#define VDROP_FACTOR 0.7
// *************calculate above factor automatically


Looking through the code (in main.c), if AUTO_VDROP_FACTOR is defined (not commented out), the VDROP_FACTOR will be overridden with the automatically calculated value.

So there is no problem with having both uncommented at the same time.