NotFastEnuf E011 / Bwhoop Silverware Fork


#964

Hello
I’ve been trying to set up a Bwhoop B03 with this firmware / DEVO 7E (with switch mod) and I can’t make it work.

No issue with flashing (I’m already using silverware on many quads) but can’t manage to set up properly the DEVO& config file.

When I try , after Arming the throttle makes the quad go at max trust…
The same setup works just fine with original SilverXXX Fw…
Can anyone provide a sample of the Config.h / Model.ini that works with This Fork of the firmware ?

sorry if already available on the topic - but i couldn’tfind it.


#965

It’s not your radio ini file. My fork has safeties that require throttle to be below 10% or it will not arm. You have another issue somewhere else. Try a fresh download and only change the transmitter selection. Also make sure you have your motor and prop directions correct. Default on the firmware is props in.


#966

Thanks for this fast reply.

I’ve already tried your proposal…
Quad : new BWHOOP B03 (not pro) out of the box

modification in config.h:

//HARDWARE SELECTION******
#define BWHOOP

(…)
// *************Transmitter Type Selection
//#define USE_STOCK_TX
#define USE_DEVO
//#define USE_MULTI

// **SWITCH SELECTION

#define ARMING CHAN_5
//#define IDLE_UP CHAN_5
#define IDLE_THR 0.05f //This designates an idle throttle of 5%
#define LEVELMODE CHAN_6
#define RACEMODE CHAN_7
#define HORIZON CHAN_8
#define PIDPROFILE CHAN_9 //For switching stickAccelerator & stickTransition profiles on pid.c page
#define RATES CHAN_ON
#define LEDS_ON CHAN_ON

And the Devo File is the same as I use for any Silverized quad w bayang protocol with:
Hold switch to activate Chan5
SWA switch to go to Chan6/7/8 to choose flying mode.
Chan9 not allocated.

I’m lost.


#967

You’ve undefined //#define IDLE_UP CHAN_5 but defined #define IDLE_THR 0.05f

Not sure if they work in conjunction but undefine IDLE_THR and see if that works


#968

Also there was mention earlier of quads going full throttle on certain builds if mix increase throttle was set too high (I think default is very high). Oops never mind, the defaults are set low 0.2.


#969

This is a very strange case indeed. Commenting out idle up is a supported use of the idle up feature and has been confirmed to be operational. In this case with the idle feature disabled but arming feature active, the throttle value is hard set by code to be exactly 0 anytime the throttle stick is below 5%. The arming safety confirms that he is not attempting to arm with the throttle at 100% because it would just blink at anything over 10% throttle. So the question becomes, how could a board go full throttle upon arming while the throttle is hard set by code to be exactly 0. I’m totally stumped.

I don’t think this is a software bug since others using the bwhoop target cannot replicate.

I don’t think this is a mechanical error - like motors plugged in wrong because @rege78 does not communicate a spinning condition or flip over on stock silverware or with NFE flash … just full throttle on NFE.

My best guess is that the devo model file is set to helicopter and not to multi. And toggling the hold switch is throttling up automatically in transmitter software the instant that the switch is flipped? In 10 years of flying devo - I’ve never used the heli selection to be at all familiar with any preloaded mixes there … but it’s quite possible that there is one. @rege78 - what is the model type set to in your devo 7e?


#970

Sorry no
type=multi


#971

Maybe try with idle up feature active.

Also what system are you compiling on? Mac, pc? Using keil?

Is there any nuances to the behavior you can communicate after arming or in your procedure?

Have you tried strong or very string filtering to address a bad motor shaft or bent prop? Have you tried stock silverware pids on the nfe fork?

My fork works out of the box on about 99.9% of all stock supported toys. Often the .1% can be quite a challenge to sort out. My tune and settings are right at the limits for high performance. I’m sorry yours seems to be struggling.


#972

Thanks again.
I’m using a Mac & https://simonernst.com/silverware/ tools.

Good news - using the packaged version of your firmware in Simon Ernst package is working fine.
And your settings & Fly modes are GREAT ! Thank you.

Still no success with the last Github master - I will try again with exactly the same setup (Devo File & Config) later today, in order to understand.


#973

the mac app uses gcc to compile, it sometimes can cause strange issues, although the math functions work now, they had issues in the past, so I think it’s possible there is an issue again


#974

Well I’m glad we got to the bottom of that @rege78! One of my next initiatives is to use the release feature of github more so that there are precompiled hex files with at least the different board targets and radio types provided. I feel like that could have helped us in this case. I have already started to do that with alienwhoop ZER0 target.

@silver13, do you think if I abandon the kalman filters for standard 1st order filters (since they produce mathematically equivalent results) - that it might resolve some of the build issues on mac with Simon tools?

@rege78 - could you enable custom filtering and change out the kalman gyro and motor filters for 1st order gyro and alpha motor filter to test?


#975

it’s possible I guess, but the kalman has always have been on. It would save maybe 70uS so that would not fix full throttle, but maybe improve performance a bit

I guess I have to compile with gcc and see if it works here

edit: gcc is causing the problem

edit2: it really is one of the kalman filters


#976

Yes it is really gcc : the same code is compiling fine with Keil.
(I prefer using my Mac , but i will have to come back to my old PC …)

Thanks everyone for the help.

I won’t have time in the coming days to fly - but il think it was the issue.


#977

I am wondering if it is possible to mount a silverware FC upside down? (Motor plugs up)
I see motor pin definitions at the end of config.h, but do I need to tell the gyro somehow that the board is upside down?

Thanks!


#978

Yea it’s possible :slight_smile: Theres line in config.h ! About remapping motors its possible too ! Its really easy . Fire up keil :wink:


#979

you need to add #define SENSOR_FLIP_180 in config.h under the defines for your board type (a good place is just below the other #define SENSOR_ROTATE line.)

If you change the motor wires to different points you will have to rearrange the motor pins too. It works fine though, I have a couple flying “upside-down.”


#980

Edit: nvm Ian is too on the ball


#981

Thank you very much Ian444!

Can you tell me which section to modify to rearrange the motor pins? There seems to be 2 sections (line 434, and 623)

Really appreciate the expertise :slight_smile:

Thanks yets and tarkux!


#982

You’ll need to swap the pin assignment between motor 0 and 2 as well as motor 1 and 3 for plugging into the nearest plug when upside down.

There are multiple targets at the bottom of config, just do it in the section that matches the board you’re using in the define on top.

On a side note, I think I’m gonna add a new header file for targets and move all that “lower” section out of config.h to clean it up somewhat. Opinions?


#983

Oh ok, I see the hierarchy of the multiple targets now in config
Thanks very much!!!