I’m guessing we could control a buzzer in this manner? Anothr question would be can RealPit be powerd with 1 cell or needs a board with 5v somewhere
Yes buzzer can be controlled, silverware already has support for it.
And Realpit takes 5-28v according to spec - not sure if it will work with lipo voltage, it’s technically just a FET.
I go 5v output from alienwhoop zero -> realpit -> minimosd -> camera/vtx.
Been quiet here euh ? Something special is coming i guess he he he
Maiden flight today… everything went great! This means I can push full steam ahead to fix the remaining bugs / port in the rest of the features I want, and prep for a public release!!!
Currently Quicksilver supports all the previous NFE f0 targets, and now some f4 targets too. There is plenty to do before I can drop it on you guys … so it’s still gonna take some time. But @tarkux is right, I have been very busy!
omg omg omg omg omg omg omg omg ! Won’t be able to sleep tonight !
Awfully quiet in here? Whats the news on Quicksilver?
Steady plugging away and making progress. It has actually inspired some cool ideas for some new stuff to try on f0. So I’m considering taking a break and coming back to F0 nfe_silverware for a spell and trying some new stuff.
Awesome, if you need some testing of silverware or quicksilver let me know.
Yeah anything new/fun to test will show up here. One thing that is not getting much attention is the different min throttle algorithms which have been available for a while. They are down low in config.c and each one performs very differently. I am close to making a change for my favorite and eliminating the other 2 (one of which scheduled for deletion is the current default).
I certainly encourage everyone out there flying brushed to try these out!
Are you referring to minimum motor output in config.h?
Yes there are 3 types
Hi all, I have quad (using bwhoop) that previously was using the notfastenuf build from June 2018 and was flying great. Today I decided to flash from the latest notfastenuf repo and now the quad spins aggressively when armed. I have played around with the different filters and it still yaws aggressively when armed.
I have also flashed the latest on another quad and the same thing is happening.
I’ve reverted back to the June 2018 source and things work properly again?
Is there any secret sauce that i’m not aware of when configuring for either 8520 or 720 motors using the latest source code with a bwhoop board?
Yes, default is now props out… so that’s your spin. A bwhoop is props in. You need only perform 2 stick gestures to fix it. One to change to props in and one to save that setting permanently.
To be honest I can’t even remember it at this exact moment lolz… but if you click on the releases tab… and scan the release notes, you will see an extensive explanation.
Thanks @NotFastEnuf that did the trick! (DOWN-UP-DOWN). I’ll have to find some time to catch up and read the threads from July 2018
Don’t forget down down down to save
Just a FYI of a kinda neat thing. I found a couple of Android STM32 ST-Link apps (ZFlasher STM32 and StlinkP are the first two I tried, and both work great via OTG) and using my OTG adapter, I can build a bunch of trial builds and load them on my phone. Throw the ST-Link and my programing harness in the bag and Voila!, able to flash in the field without lugging a laptop/tablet!
Zflasher I have used with success, stlinkp I will have to check out. Thanks for sharing!
I’ve recently flashed my Betafpv Lite FC with the latest NFE_Silverware. I am using the irangex irx6 multi-protocol module with my Flysky FS-I6 transmitter (stock firmware).
I noticed that the channel mapping seems to be off. For me, channel 5 on my TX maps to CHAN_10 and channel 6 on my TX maps to CHAN_5. I’m using the USE_MULTI type and RX_BAYANG_PROTOCOL_TELEMETRY_AUTOBIND protocol.
Anyone else have similar issues?
The irange follows devo mapping. Not multi