Micro Motor Community

NotFastEnuf E011 / Bwhoop Silverware Fork


Supporting flysky and ibus makes good sense to me, their cheap radios are still very functional and actually feel pretty good. They have multiple tx antennas oriented at 90 degrees to each other to prevent blind spots, etc.

I actually have one, so I might be able to help with that bit.


Thanks @NotFastEnuf, for your work.

I’m want to build tiny8x (85mm) with 8520 motor + caddx turtle v.2.
The problem’s, I’m realy don’t know how to tune right now PID, filter, and the other. I don’t found any instruction on the comment (inside script) about whoop 85mm + 8520.

Would you give me some advice? Thanks before.

Right now, i’m using default setting for 65mm + 716 motor. and realy like the feel when i flying it. :slight_smile:


I’ve never built one. If you don’t have noise issues, then there is nothing to tune in your filters. Noise is evident by a throttle that will not responsively lower after being increased. As far as pids… If it’s misbehaving - raise P… If it’s oscillating in wind… Lower it. Try the boss 7 tune for perspective. It’s hard to write a definitive guide for tuning. Sometimes you just have to explore the range to see how your craft responds.


Thanks for your respons :blush:
I’ll try boss 7 tune first… :wink:

About noise, i’ve trid using beta filter on whoop 65, and my whoop not coming down altought throttle down. Is this noise?
I guest for whoop65 just use alienwhoop filter. Or i miss something when using beta filter?


Got a problem and need help: SantaWhoop board with 297l + mp65m starts blinking 4 times irrespective of what I am select as i2c speed. Same behaivior for HW + SW i2c selection. Has anyone a clue of what to do?


Answered in the other thread @qmike


@NotFastEnuf, i’ve tried boss 7 tune.

It’s flied good when acro, but why always go to one direction when hovering? Is that motor noise?


No, that’s excessive vibration causing accelerometer drift. No option there but to reduce vibrations or soft mount. On a plus, this is an indication of how fantastic the gyro filters are at filtering noise that affects gyro data/acro flight. But these filters have no bearing on the accelerometer. To solve this, the accelerometer will need to be subjected to less actual vibrations.

It’s worth mentioning that maybe you should try to calibrate the accelerometer of you haven’t


I’m sure i’ve calibrate the accelerometer.

Any idea how to reduce vibration? I’ve use soft mount already. But still drift :frowning_face:


So as I refuse to use windows as much as possible and the gcc compiler screws up kalman filters,I was able to install Keil v5 mdk526.exe and setup a make.bat wrapped in a make.sh to compile silverware via wine from my linux terminal.

Build appears to work fine without errors, I need to test-flash and make sure everything is working tonight.

Will update with a proper guide if anyone is interested.


I’d be curious if we could somehow devise a way to compare the performance of that compiler. Silver pointed out long ago (before any kalman existed in our code) that GCC does not optimize as well as keil does and ran a slower loop time. Since then I have overclocked to stabilize our loop time … But if you turn overclocking off - the loop would exceed 1000ms. Maybe we could compare your compilers performance by turning off overclocking for both methods and looking at the looptime? Or maybe we could leave overclocking on and create some sort of debug timer to tell us how much of the loop is occupied or how much free space is remaining? I am certainly curious of these things. Also, putting the cpp kalman code aside… Maybe there are settings such as compile for speed vs size that can be manipulated to bring GCC up to speed with keil? I certainly want to learn more about the different ways of compiling -keil, Linux, GCC… And ways to quantitatively evaluate their performance.


Well I guess you need to first evaluate the difference between vibration induced drift and accelerometer trim. If you have calibrated, you have made it learn what level is supposed to be but it is unlikely that our process teaches the FC an exact level. So a small amount of drift is just an error in our process and you can try using accelerometer trim in config.h to correct it. But if the drift is large it is not a trim issue, then your vibration is coming from props, maybe a bent motor shaft, or flex in your frame.


ARM has its compiler suite available for Linux natively. You should have no problem compiling with these directly.
I’m doing the same in a Docker machine on macOS.


I’m very interested. Thank you for your work


You are right but from what I read on their page you need a license for that or am I mistaken?
Is there some way around that? Can you maybe share your docker config?


I was researching vbat calibration a bit in this thread and stumbled upon your changes - it appears like eventho the request was merged and @NotFastEnuf mentioned he would merge it that they are no longer in the code.

@NotFastEnuf did you abandon this approach/is it no longer necessary?

I currently have the correction factor/ratio setup on my taranis but this probably means the vbat compensation is seeing wrong values in silverware so I’ll try to recalibrate with the REPORTED_TELEMETRY_VOLTAGE setting instead.

Further more I noticed that actually setting scale to 6.6 shows the correct voltage now as quoted in the pullrequest

Does that mean silverware is seeing the right value after all?


Our values for scaling in firmware are pretty close to accurate but I am going to overhaul all that code soon. If your taranis is off by alot … Rescale it in your radio. If you were to do it in firmware you’d risk really throwing off pid voltage compensation.


Understood - Btw. the 6.6 scaling was only fine for a full battery. Battery at 3.7V still showed 4.0V so ill go back to the taranis scaling mentioned above


@NotFastEnuf A bit more feedback on the Dual pass beta filtering on the 6 inch brushless; so I lowered the D Term 2nd to 70hz while keeping gyro 1 at 90hz, 2 at 140hz (not sure it was the correct thing to do) but with it I was able to add Torque Boost without quad flying away. Flips very cleanly now with nearly bounce back and nearly no propwash on descends in it’s own dirty air. Nice stuff.

My next test is the 0603 whoop which flies like a dream. Will see if I can get it the same and then wait for the D term passes :slight_smile: Looking forward to it all


quick update - compiling,flashing and flying worked perfectly - will post a guide soon