NotFastEnuf E011 / Bwhoop Silverware Fork


#504

As for progress on the safety feature to squash mix increase throttle until we have taken off… it turned out well. I added a blinking led to indicate that it’s happening so we have a visual reference. So everything will be as it was before as you bind and get ready to fly … then when you arm - the led will blink rapidly indicating that mix increase throttle has not been engaged … as you raise throttle past the threshold - the led will go solid. It kinda makes it fun … like you’re anticipating a big launch. :smile: I had it in at first just for visual reference in testing cause the difference is so subtle - but now I kind of like it so I might leave it there. Oh and I also only added this safety to the mix increase 3 flavor. There are others as you long time silverware guys know but I have removed their define references from config.h - I will probably remove them all together as I really like how the “3” flavor behaves as an airmode.

I’ll keep you all posted when it’s on github. @yets - do you think that may be a good feature to add to brushless fork? Seems possibly important there with higher powered motors. I added it because I heard reports that whoops when armed w/idle up & mix increase while in angle mode were getting a little “excited” on the ground before taking off. It’s still as of yet untested if this rectifies that problem. @Velcrofpv will be doing the honors there of letting us know if this improves his ZERO racing rig!


#505

Actually now that I think about it, and while on the subject of safety features … I should probably abandon the led blink as an indicator of the transition of on ground to in air … and write some code that blocks arming if throttle is not below the threshold. Ie. If you try to arm with the throttle up by accident. I could use the blink there as a visual warning that you need to lower throttle beffort props are gonna spin up. That seems smarter. … just thinking out loud here. Lol


#506

I flashed a second board, that works. Maybe something is wrong with the first. No clue. :smiley:


#507

Probably a hardware issue. Fortunately it’s pretty simple hardware. I bet you can fix it!


#508

Yeah, sounds good to me. For those already using brushless silverware, I think they’re used to the little things about the FW but those coming from Betaflight would probably be in for a shock… There’s very few on here who have taken the plunge with Brushless Silverware, so I can’t talk for them but I’m sure some of the other guys on RCG would welcome it.


#509

Sorry chime13, I do everything in the TX so I’m a bit ignorant! :smiley:


#510

Speaking as one of those brushless Silverware guys, I’d like to see this feature implemented as an option when selecting idle up settings. Makes sense safety wise and increases the familiarity with Betaflight behaviour.
@yets I’m trying to compile a useful report for you on my attempts with the Mac flashtool and your fork. I’ll post in RCGroups thread as it seems most relevant there.


#511

Yeah, I agree. I linked the “airmode threshold” (for lack of a better term) to mix increase 3 ONLY since that’s what is most often used in brushless I guess and it’s all I use for brushed. I’m not gonna put it in the other mix increase … but it will be easy enough for yets to add it there if he wants to. I think these safety features on arm and idle up may qualify these two features to be merged back into main silverware if @silver13 is interested and after some time testing. They are all on defines so they don’t have to be defaults in the main repo.

@chime13. Your feedback will be invaluable to make sure it plays well with the split arming and idle up. We will also need to test undefining those features one at a time again for a functionality check.


#512

Just as an anecdotal data point, that would prevent something I was doing yesterday. I landed (crashed right-side up, really) in some grass and immediately disarmed. Once I saw my quad was upright, I wanted to try and take off again. Since I had idle up enabled and didn’t want to spend much time chopping the grass, I set my throttle up enough to take off, and then re-armed the quad so it would hit that throttle point right away rather than me arming, idling in the grass, and then upping the throttle.

I’m new to all this, so this is probably not a very good use case. It just kinda made sense to me at the time :-). And since I put idle up on a switch anyway, I could get around this by just turning off idle up until I got in the air. I just thought I’d throw that out there!


#513

Maybe it’s a QC issue, the one which has a white dot on the chip is the faulty one. Next to the chip on the right the solder pads are also soldered. Hm…

I ordered a new set of the 19.000kv Boldclash motors and on one the shaft came out with the propeller on it… ouch… sticked it back and it works… LOL :smiley:


#514

Examine that board for a bad solder joint


#515

Thanks, I’ll compare the two. Hopefully will find something.


Another theme:
Where do you buy the 716 motors?


#516

I worked out why it initialises to both trims “enabled” on the stock tx.

This needs to be initialised to the default value of the transmitter:

static char lasttrim[2] = {0x1F, 0x1F};

At least that’s what my H67 jelly bean tx transmits


#517

I’m not sure I understand what you mean by “enabled” - lol - can you elaborate for me? I only messed with the toy TX for one evening to work out mapping.


#518

The pitch trim and roll trim both start in the Enabled/on state after I bind the TX.

I assigned Idle up or arming on those channels and the quad starts armed/idle up. If you make the change I mentioned, they start in the off state


#519

Just let us know when it’s ready for dl - I’ll be all over it like tarnish on silver…ware


#520

Thanks @rich110 - great find. I’ll test tonight and keep you posted!

Thank you also @chime13 - you are a great help as always


#521

Some code needs to be pulled from upstream to get silvervise/BLE working for me:

This line gets BLE working but the rest of the commit is probably a good idea too:
#define XN_POWER B00000001|((TX_POWER&7)<<3)


#522

Yeah I’m a little behind since being caught up in the alienwhoop zero project. I’ll try to get to it ASAP and report back. Anyone out there that could collaborate on getting spek sat working?


#523

OK new changes pushed up to github.

Arming safety is in with a threshold of 10%. So if you try to arm and your throttle is above 10% … it should just blink at you till you drop your throttle stick.

Also, I have squashed mix_increase_throttle_3 until you take off and pass that 10%. This should translate to slightly better “on ground” behavior after arming with idle up turned on. After passing 10% the mix increase throttle thing will kick in and stay engaged until you disarm again.

I know these features work with arming and idle up defined and switched on together… but I have not had a chance to test them with in any other split configuration or with either one of arming or idle up features undefined. It should be good but I welcome any reports of unexpected behavior. Most of the code changes are in control.c with a few variables added outside the main loop in main.c and a define way down low in config.h. The threshold is adjustable but I didn’t put it in a highly visible spot since its a safety feature. Also, if you undefine it - it will just resort to staying on with a throttle safety threshold of 15% … again no getting around it cause its a safety feature. Feel free to look it over if any of you are code savvy - it should be solid.

Next up I will need to test out fixing the stock tx issue that @rich110 pointed out. But first I gotta disassemble my laptop and repaste the cpu and gpu and unclog all the dust. I am cooking right now. So hopefully that goes smooth… :sweat: