Micro Motor Community

NotFastEnuf E011 / Bwhoop Silverware Fork


You could just easily tweak this project for brushless to give it a quick whirl tho… right now it’s more about does the code even work than is it a major improvement. Lolz. That’s why it’s a separate download on my gdrive and not on github yet. :slight_smile:


Actually, I’ll just do that.


Have you ever created a branch in git?

You could make all these changes on a separate “experimental” branch (like a mini-fork of your own stuff), you could push the changes and easily share them on GitHub without contaminating the “master” branch others rely on. In the software development world, we often create a new branch for any new feature and test and fix it before merging back to the master branch.


Yeah that’s the right way to go about it… I guess I just wanted a few more eyes on the changes before even doing that. The filters are all c++ and that may as well be Greek to me. If some of you guys that know your stuff look it over and say that it’s functional code… I’ll branch the fork


Good to see some activity in here!
And branching is the way to go. It will also make it easier for us to review your changes :wink:


I did it to see the diff:


While I await feedback on the dual pass gyro filter code (does it even work??) … I am playing with 4s brushless again. @yets you will probably be happy to hear that. Hehehe. Specifically I think that pid voltage compensation needs to take into consideration the number of cells you are running in your pack. I was looking at that code and I think that vbat_filt is the value that’s input into the compensation function, and it’s evaluated from 4v to 3v. So vbat_filt needs to be divided by the # of cells for it to calculate correctly. I also plan to look back into the voltage reference and voltage scalefactor code to see if there is a more intuitive way to define that sruff. 2.8 or 3.3 vreg value would need to go in the target … and maybe scalefactor can just calculate from a number of cells define. There is also that code for “tweaking” the values reported by telemetry, and while it works … @brianquad pointed out that his test case still wasn’t scaling properly across the entire range of full to dead pack. He had proposed a solution to correct the slope of that calculation but I think it just needs an entire overhaul and I’ve always wanted to clean it up for a more elegant solution. Maybe I can sort all this out at once.

Which brings me to my next question … @Ian444 - related to the above stuff … do you remember what vreg is feeding the f0 on your brushless board you sent me? I am gonna guess it’s a 3v3… cause m presently using the h8 target with adc ref set for a stock 2.8vreg and i my slope is way off between a full to a dead pack. Anyway, if you can’t remember I can pull my canopy and measure it. Thanks again. Just insane I can fly a 4" on 4s in my front yard with your fc.

To finish this post out … can anyone confirm if my code for the dual pass filters is valid?


Also … happy cake day @Ian444!!! Your contribution to micro flight is amazing and has been super inspirational to me. Frame designs, flight controllers designs, ultralight micros, first in line to test new things - your fearless attitude to get right out on the bleeding edge over and over again really encouraged me over the years! You have changed the hobby more than you know!


You are too kind. I think I just lead people astray off the tried and proven path :wink: You however have done some great work with the firmware and spreading silverware to so many people.

The Vreg should be a ZMR330 with “330” written on it, and as you guessed, 3.3V. Interesting that you bring that up, as what I’ve done to date is set the correct telemetry voltage with a fully charged battery using the scalefactor, then fine tune the low voltage warning for each quad. I don’t look at the voltage during flight, only before flight to check I have a full battery. The low battery warning for any quad varies a bit depending on the actual battery being used and how hard I fly it. Harder flying results in lower battery resting voltage (after landing) and light flying a higher resting voltage. A good quality hi-C battery results in a lower resting voltage, and a worn-out battery gives a higher resting voltage. It’s always worked well enough, as long as I can read a full battery, and get a consistent landing voltage (more importantly - not wreck batteries) I am happy. Ahh - and that Vref thing probably explains why my two 3S quads have low battery warning set at 3.91 and 3.96 to land at around 3.78-3.82! :slight_smile:


@NotFastEnuf I haven’t had a proper chance to test the dual pass yet, been trouble shooting a few issues with a 3s quad which ties in to the voltage reference and scalefactor code perfectly; yeah calibrating it has not been a rewarding process! That does need looking into for sure. I did peek at Brianquad’s code (along with his excellent Analog aux channels) and with my minuscule knowledge I thought it would work well but never got round to adding it.

In regards to the PID compensation, that code is from the H101 code and @SirDomsen uses it and changes the factor for more than 1s battery. I’ll find that bit but I think it’s already coded in, user needs to change cell amount manually. I was supposed to leave a description about it!

There’s some other little things in the brushless branch you should look at, in particular Markus Gritsch’s Motor Linearisation code.

I did quickly try the Dual pass on a Silverwhoop H8 LOS quad, has beaten up props after i tried to teach the little one to fly (massive failure). Worked good from what I flew. Actually flew really good with stock PIDs


Well that’s a good sign Yets, it flies. I forgot to mention, I compiled the firmware (no errors) but not loaded yet. Will test this weekend.


PID voltage compensation raises PIDs as Battery voltages drops while discharging (therefore 1.33 factor). The 3S/4S auto detection (taken from here) and PID adaption is a different story :wink:


@yets, sounds like you are one step ahead of me with cell count adjustment to pid compensation then. I’ve had compensation for some time and it is based on the h101 code yes, but had pretty much been focused on 1s so never thought to write in cell count adjustment till now.

Anyway, I’m gonna try to rewrite all that adc stuff and tie it more intuitively to target defines. Basically I hope to just define the mcu voltage as 2.8 or 3.3 and the voltage dicider resistor values, and have the rest fall into place. Maybe something tricky can be done with vbat_filt automatically “guessing” cell count so the rest of the compensation stuff falls in line.

@SirDomsen - interesting stuff from markus about pids scaling linearly with voltage. That may be very useful in my future project for the ai/self tuning quad.


I flew with dual pass Kalman, single pass Kalman, and single pass PT1, all seem to be flying fine. Will test some more in the next few days, this is on a 2S 1103 100mm LOS. Every time I fly NFE (or Yets) it always seems “sharper” as in quicker response, and this one feels the same, so I probably need to load standard NFE to compare it against. I like the quicker response, I’ve compared all the files with standard B-03 (using Winmerge) in the past on a couple of occasions but could never find anything that might account for the difference (doesn’t help that I can’t read code).

BTW I would have thought that 1S/2S/3S in itself would not make any difference as the higher cell counts are scaled down to “1S” anyway.


Are they? I was thinking they weren’t and that this was a problem


Well, scaled down with the voltage divider. I might be missing something though.


No I think you’re right if you tweak your scale to match 1s voltage… I guess I was just going about it the other way where I want it to report actual voltage accurately. Plus, while it’s probably not a super big deal, there is an element oferror that’s getting scaled which can accumulate a bit more than I’d like from 1s to 4s. IDK… This will require some thought to approach it in a clean way that makes sense.


Still continuing to test the Dual pass and to my untrained eye and thumbs it seems to be working really well. I’ve mainly tried the Dual pass, will give the single pass a go next up


It’s not really working in single pass selection with only filter 2 enabled, and I think disabling both filters is also broken too… . I’ve found and corrected the mistakes and will push changes to GitHub soon. The code is totally functional as 2 passes though.

On my own testing I have been able to eliminate motor output filtering from both my whoop and my boss 7, and have been able to run higher cut frequencies for d filtering. I think I like it


What does motor output filtering actually do NFE? I was looking for info on this on the weekend, and found nothing. Strange.