NotFastEnuf E011 / Bwhoop Silverware Fork


#1064

I just checked out the Alienwhoop documentation (nice job, guys!) and saw that the Alienwhoop is flashed for a “props out” configuration because it “provides better flight characteristics.”

I’ve been curious to try out “props out,” as I have seen it mentioned here and there, but have also seen a few notes from @NotFastEnuf about issues with some whoop frames causing issues due to the motor strut geometry. Was that the E011 frame?

What do you guys think? I’ve got E011 frames, Beta65s frames, and BOSS 7 frames. Which are compatible with “props out?” What’s the latest opinion?


#1065

E011 and bwhoop need to be props in for example. You just have to look at the angle of the struts. You can always run one of those props out by rotating the frame 90 degrees and sliding the battery in from the side.

Boss has no struts, always run them props out. Red/black motor wires to front right…


#1066

Yeah, you lose thrust with props out on the E011, ask me how I know that :sweat_smile::sweat_smile:


#1067

I got terrible propwash handling too


#1068

You were the one who told me to do it :joy::joy:


#1069

Thanks! I’ll try it on my Beta 65s frame, which at least has symmetric (and rounded, not angled) struts, and my BOSS 7 frame.


#1070

Never listen to me! I learn everything by making mistakes! Ha! :):laughing:

Speaking of … dsmx/dsm2 is ripping! I have a local copy of the fork that I’m gonna push changes up from soon. It includes all reworked safeties and that issue you pointed out about low bat blinks blocking arming fixed. In case your curious - it was that line that silver pointed out. I had added it because in many of the radio protocols - as a failsafe condition was being cleared from the rx code, motors were going active on last value for about 4 frames/loops and while failsafe blocked motor output, it was leaving last known position of throttle sitting in that variable bucket. The result was motors that could spin in certain situations for just a blip after failsafe cleared but before rx array updated… and led behavior change was a shortcut to that event being over. So during failsafe now, I’m clearing throttle to 0 and that fixed it. I also added a counter that increments requiring a 10 good frames before my safety flags can toggle on good rx signal coming in as 2 stage protection. If it continues to test well, I’ll push it all up.


#1071

Did you update a lot of the other protocols with the rx_state line? I remember adding it a few times when incorporating the changes? Looking forward to the update! You should be incredibly proud of the work you’ve done. Thumbs up all the way.


#1072

no changes have been pushed up yet … but code around rx_state will change in the radio protocols. It will make sense when you see it.

And thanks man! :slight_smile:


#1073

Hello everybody and thanks for the work made until now on Silverware,

I spend the day long trying to flash an E011 board with NotFastEnuf’s Silverware version but couldn’t achieve it under linux Lubuntu 18…
I managed to unlock the board, compiled a binary file after cloning the Git repository and flash it to the board (and flash again the factory firmware). But I didn’t get the quad to fly with Silverware.

What I achieved so far was a binding (leds blink quick and stop when stock TX is tuned on) and then leds blinking five time, then stop, and five time again…

From what I red I suspect linux/gcc to be the source of the problem. Because when I flash the board with a version compiled on my computer the verified amount of bytes is slightly lower than the written amount (flashing with openocd), while when flashing the factory firmware (from Silverware Git) the amount of verified and written bytes are equals.

Could some of you help me with this ?

I’m so enthusiast about Silverware’s ability to run on such cheap boards and so frustrated to not be able to give it a try and go further !

Thank you


#1074

hi, first make sure you disable the kalman filters and enable a first order filter instead. They are known not to work with gcc, they cause full throttle. second, we are flashing the 16k chip with up to 32k, this means the openocd autodetect mechanism has to be bypassed like here

https://www.rcgroups.com/forums/showpost.php?p=38162521&postcount=11339

a bit unrelated, but still under linux, flashing from rooted android:
https://www.rcgroups.com/forums/showpost.php?p=39982887&postcount=14411


#1075

My hands are SHAKING !!!

Replace the words"Cs source" by Alienwhoop Zero DSMX


#1076

Thanks silver13,

About kalman filters : I selected 1st order filters and the alpha one for motors and still had warnings at the end of compiling process. No changes after flash.
About flashing over 16k : I already did the bypass as I needed to flash again the E011 factory firmware from your git repo.

Maybe you have somewhere a bin file ready for stock E011 that I could try to flash ? (with stock TX). That way I could be sure the problem comes from compiling and not flashing.

Is there a meaning of the led blink ? 1-2-3-4-5 – stop – 1-2-3-4-5 …


#1077

here is one compiled with gcc for e011 stock
e011.zip (11.6 KB)

the 5 flash indicates a code error most of the time , bad instructions / etc. There was a gcc issue but it was on mac iirc. Might pay to try a different one

my gcc is older, “6 2017-q1-update”


#1078

Yep !
Flash worked with your bin file (even if the verified number of bytes was still a bit lower than written one), and the drone flies !!

Now I need to learn how to point make to an other version of gcc than the default one which is 7.3.

Thank you

_ An hour later…_
So I’ve installed gcc 6.3.1 and modified the Makefile lines 5 and 6 adding -6.3.1… then I found in config.h that I should choose “custom filtering” in order to avoid kalman filter. Compiling worked, mentioning a 6.3.1 version of gcc. The warning about LP filter disappeared (still got some warnings). But after flashing… still the same 5 blinks…
For now, I have no more ideas about where is the mistake/problem. At least I can play with the .bin you provided, but I would like to be able to compile myself.


#1079

try the code here with the defaults, that’s what I used. Then if it works we can see from there


#1080

I’ve followed your link, clone a fresh folder, cd …/gcc and make. I had some warnings about lpf filter again. and after flashing the file, again the 5 blinks.

Here somebody was compiling right under linux, it should work also on mine !
https://www.rcgroups.com/forums/showthread.php?3060011-Some-notes-for-silverware-E011-flash-on-linux

This afternoon, I’ll try to reinstall all the tools on another computer and see.


#1081

I guess you already have seen this page but just posting the link in case.
https://simonernst.com/silverware/


#1082

Just an alert to anyone downloading / updating NFE right now…

I am currently staging the fork for a second official release for the Alienwhoop Zero. So for a few days, its gonna be all set up on ZERO defaults … make sure to change your target and props in/props out to match your equipment.

Updates include:
-reworked arming safeties
-dsmx/dsm2 support with binding
-added a stick gesture which toggles a variable saved to flash memory

In my local copy I am playing with using this variable to change gyro filtering, but it could be used to turn lvc on or off, change props in props out, or its format could be duplicated to add more features whose state will save to flash. Right now it is just framework though … no feature is tied to it officially yet.


#1083

the only thing i can think of, the boldclash makefile has --specs=nosys.specs added and I am not 100 % sure why, there was an issue but it affected newer builds, you tried the same as mine. Anyway you should try it