NotFastEnuf E011 / Bwhoop Silverware Fork


OK @yets, I was able to replicate. It seems I can not start off with a battery that is dead either. It won’t arm. I’m curious now. Did I do this? Was it intentional? Does standard silverware not block throttle if you plug in a battery that triggers low voltage blink? Guess I’ll poke around.

Friends don’t let friends code past 3am. Remember that :slight_smile:


It’s not really a problem that it won’t arm with a low battery is it? Usually 99% of the time one starts with a full battery? Ahh, if there was a crash…

I’ve always struggled with low battery warning if I change props or battery on a brushless. I would think these characteristics would be the same on a brushed though. For example, if a run a larger battery, or lower IR drop battery, I get the warning at a lower voltage than if I flew a weaker battery. Also prop changes (the load presented to the battery) affect the low warning voltage. It would be nice if the VBATTLOW value could be stored in flash and read and write it with silverxxx’s PIDview app. I never hear of people with brushed reporting any issues with low batt warning though. Once set, it’s very reliable, but if any changes are made to the quad, it has to be set again. Hence easy access to change the VBATTLOW value would be a benefit IMO.


Interesting. I was sure I’d seen this before, too, but couldn’t figure out what the pattern was. I was confused at it happening, because I’ve seen the “STOP_LOWBATTERY” feature disabled in config.h and it seemed to be acting like that described. Low battery at power up appears to have its own LED flashing code, though, so that would look different.

I just tried a bunch of weak batteries sitting from 3.7 - 3.9V (measured with a multimeter, and showing about that in telemetry, but that has the compensation factor built in) and none of them would let me fly either of my silverware whoops. They don’t even show the arming flashes - just a steady two-ish flashes per second right from connection.

I’m taking a look in the code, but haven’t found anything yet…


But 3.7 to 3.9 shouldn’t be blinking low voltage?? For me the behavior is consistent with low voltage blink which is consistent with my adjusted telemetry voltage.


Yeah, I wouldn’t think 3.7-3.9 would count as “low voltage,” but these batteries at about at the end of their life (that’s what I meant by “weak” before, but wasn’t clear). They sag pretty hard now under load, so maybe that’s related.


It’s not necessarily low voltage but it’s likely to be the hysteresis settings as silver described. As a test, set your low battery voltage at 4.1v with hysteresis at 0.10. Plug in a fresh battery, it will flash low battery depending on how accurate your voltage detection is. See if it arms then?

The problem isn’t really a problem if you set low battery low and hysteresis low too. Silver’s defaults are 3.5v and 0.1v which would mean it’s unlikely you’re going to try to reattach and use a battery which has a voltage under 3.6v. It only really comes into play if you have a higher voltage warning and more hysteresis and you eject a battery after a crash. Then you have to replace the battery even though you may have enough juice on the one you were just using.

I tend to eject batteries a bit on my 1s builds as I crash hard and they’re only held on with elastic bands :sweat_smile:

@NotFastEnuf, I’m no coder even after spending a lot of time with it all but is it worth disabling the linked in LEDs quick flash that signifies throttle over safety level when trying to arm? You’ve probably already thought about it


Well I had my testing interrupted by my devo going bonkers. It suddenly turned telemetry off, and removed my watch boxes from my main screen. By the time that was sorted - it was 3am.

What needs to be tested next for reference is 1. the main silverware repo, and 2. The behavior in NFE with arming feature commented out to determine if throttle will respond when plugging in a battery that’s causing a low voltage flash.

Arming is linked to the status of rx_state and rx_ready inside the radio protocol as well as throttle. If those variables are affected by low voltage - it could be blocking arming - but it’s otherwise not linked to voltage at all.

@yets I think it’s this… I do remember when testing one of the first or second prototypes the zero, we did not have adc scalefactor right and we’re blinking all the time - but were able to arm and fly while i figured out the right value to match our voltage divider. I’m pretty sure I added safeties after this second zero prototype version but I’m not totally sure.

@Ian444 - having a block against trying to fly on a dead lipo isn’t a terrible idea to me … I am just intrigued because I can’t remember doing this on purpose (which doesn’t mean much), and I don’t know exactly where in the code this determination is being made. I like to know things - and I will feel better about it when we can put our finger on the line controlling the behavior.


I ran through a bunch of old .hex files I saved and found that the version I made on 5/8/2018 does not have this “feature” but the next version I built on the morning of 5/10/2018 did. So, this probably first got added to the NFE branch with your 5/9/2018 commit with the comment “add binding while armed safety block & update some personal flight settings”.

I took the latest code and commented out the “#define ARMING CHAN_X” line and could now get throttle control, even when plugging in a low voltage battery (which was causing the low voltage flash on the quad).

So it looks like it is somewhere in the arming and safety code, but I’ve run out of time for today to dig into the code deeper to find the issue. I may have more time tomorrow to check it out if no one else gets closer before then :- )


main.c line 423


Good work! We will end up tracking this back to radio protocol files then and the behavior of how rx_state and rx_ready update.

To help understand why I have two variables that communicate the status of a bind event, it is because across different radio protocols there was different behavior. I do think remember exactly which protocol gave issues, but one of them toggles rx state back and forth once just as its completing bind. So I made it a two step check. Rx_state was given an additional new purpose of helping with notification to safety code of the rx state of bind. Rx_ready is a second variable I added to make it two step safety.


Yep, there it is!

This was a terrible implementation but functional. Although this accomplished what I wanted, I should come up with a better way to do this. I stand a better chance of it now after trying to write a radio protocol. Dsmx is getting closer ( I think )



I’m pretty new to the NFE fork of silverware. While I first tested with the Mac tool which comes with an older version of NFE silverware, that flew fine. I’ve downloaded the latest version and compiled successfully however, on arm, it goes full throttle. Is there something that I’m missing? I’m using B03 Whoop FC with 0716 motors.


Hopefully ! Cant wait for that ^^ Thanks for your good work !


There are all sorts of compile issues on mac. Most result in your flight experience. What method are you using to build a hex?


The mac tool comes with a one-click compiler and will generate the hex file.

I’ve gone back to digging up my old PC and sorted out the flashing process. I’m able to load it with the latest NFE version. Took it on a flight and having a small issue. On heavy roll+yaw, the motor on the opposite side seems to lose power and dip, meaning on heavy yaw right, the left motor will dip slightly and likewise for the opposite direction.

Sorry for such noob question.


Hi, I’m new here and these tiny whoop style thingies are new to me too… a stupid :wink: santa drone for my son got it all rolling 3 months ago. He didn’t play with it… in de mean time found a 2nd hand devo 6s I flashed with deviation firmware and in which I installed an nrf24… Off course I’m flying angle mode.
A difference with the stock firmware is the “inertia” in horizontal movements… is there a way to tune these? An e011c will stop quicker with the original firmware.
Another thing is the additional weight of the cm275 cam on one of my two whoops makes it quite ‘jumpy’. I improved this with a throttle curve in deviation, but still not fully happy and I still need to improve my flying skills using fpv too! Besides that, silverware is fantastic! Thanks!!


@Toobsrc - post us up some dvr or a video of your issue so we can take a look. How are your batteries and motors? Super fresh?

@Bern - are you flashing NFE at its defaults or are you changing anything? If you’re new to whoops, learning to fly one of these things with camera weight is tricky, but you may have another issue going on as well. I’d say for you to post up a video too if you think the condition can be accurately depicted.


Good morning. Among the various FCs, I use a BetaFPV lite (firmwar NFE) connected to a toy TX. I also have a TX02 BetaFPV (Frsky D8 - SBUS). Is it possible to connect the FC with the TX02 BetaFPV?


If you can attach an SBUS rx on the Betalite board, then I think it’s possible. There is code that supports it and I’m sure it’s been done by a few


the entry should be SWCLK. I wanted to know from those who have already done the work, if it is a feasible thing with little or very laborious