Crossfire protocol added into GitHub last night. I have not done anything to address telemetry - it’s just rc control for now. Failsafe functionality requires the latest version 2.88 firmware on your crossfire gear. Earlier versions returned a set position of zero throttle and mid stick values which tricked my 1 second timeout for no frames. In v2.88 the receiver stops sending frames when it has lost it’s link to the transmitter - but you still have the option to override this behavior and set your own failsafe. Be advised this is not recommended and will trick failsafe in the FC. If setting your failsafe in the agent - you get a warning that asks… Are you sure you want to change your failsafe mode to “set position?” - answer no. To undo a failsafe set wrong on a v2.88 receiver, you have to power the receiver up with the button held, then release and hold the button again for 10 seconds, then release and short press and repeat binding. A fresh upgrade defaults to the “no frames” failsafe so if you are just now updating - it should be fine. Any and all feedback from testing is appreciated. Anyone who wants to take a crack at adding telemetry or smart audio scripts will certainly be welcome with open arms.
I was just about to install a bayang transciever from a bwhoop toy tx on my Zer0, but maybe I could try XF instead
What needs to be done with Smart Audio? Doesn’t XF receiver just output SA directly to VTX and it’s all done via the lua script? How is this affected by FC firmware?
To be honest I have never used smart audio before on anything because I use a devo. I think in crossfire you are right, the receiver can do that. But for sbus it needs the FC to relay the signal out of a uart I think? I am honestly a little out of my league here with no smart audio experience… But I keep being asked to add it … Whatever it is. Lol
I think at least vbat telemetry is a higher priority.
Ah I didn’t realize you meant SA control via UART, since you were talking about XF I thought you meant its own integrated SA thingie which should work… Anyway recently I read the SA specs, thinking I would challenge myself to build SA control for Silverware via some kind of stick gestures, and the protocol itself seems quite straightforward, I am just a bit rusty with C and I have no idea how to output stuff on uart (or even what pin that would be on Zer0) + I saw you were mentioning adding OSD support which would be much nicer for that than stick gestures so I just gave up
Btw I’m attaching the latest version of SA spec (the one you can download from their site is outdated a bit and doesn’t include v2.1 that new VTXs like Pro32 Nano have).
TBS SmartAudio Specification Rev. 09.pdf (560.7 KB)
are there any plans to add ibus to the code?
Thanks @fichek that document will be helpful.
@jocejrod, I don’t see any reason not to add ibus. I’ll have to take a look at it and see if it’s within my novice capabilities. I did just finally get a 4 in 1 module for my spare Devo so I at least have a transmitter that can speak ibus… That’s half way there. At some point I will likely need to get a receiver too.
May I copy-paste this tuning guide and push it in the Wiki? Always did trial and error while setting filters, so this post is much help even to the more experienced tuners
Sure but just to clarify context … That was my routine for brushless stuff. I am finding that I occasionally need to go even lower than 90hz on some brushed. My boss 7 is happiest with two gyro passes at 70hz… And the 2nd order D filter at 120. But anything you think is helpful is always fair game for the wiki. No need to ask. I guess it’s the same procedure … I just start it all off a little lower on brushed.
Also, I should add that the filtering code is going to evolve at least one more step before I’m done with it. I am going to make D a two pass too and revisit the dynamic notch. My hope is that once this is complete - we can just settle in on some all around defaults and really stop tuning filters for the most part. That arduous task can be left for those chasing away and nitpicking propwash.
Great, thanks. I’ll add that brushless/brushed note as well.
Btw, your latest boss tune feels just awesome on my latest brushed quad (the one I showed here a few post above). The frame is printed in PC, very durable!
+1 for ibus support. Will allow for super light weight micro flysky rxs like the rx2a pro
Flysky a8s is the only sbus flysky rx. But It’s bigger and heavier compared to flysky ibus receivers like rx2a. Ibus support might be beneficial for flysky users but I don’t know if its worth to add ibus support in silverware.
Well I know I’m going against the silverware grain a bit by not being monogamous with the bayang protocol… But I am laying foundation towards reaching out to all the neglected flight controllers like f1 and f3 … Many of whom do not have an integrated rx. Flysky has some super cheap entry level radios which does follow the budget conscious approach of silverware so I think it makes sense in the long run. And shifting perspective towards seeing this firmware as an all around option for micros and high powered brushless alike… I am certainly more comfortable using high quality name brand receivers to ensure a solid radio link when there is more on the line than a tiny whoop.
The more rx types supported the better IMO. If people are going to venture into silverware, it’s good if they can keep a bit of their comfort zone in their choice of rx and tx. Plus the right rx to do the job can be chosen.
That tx stuff raises the question if Silverware’s low latency is the only advantage against Betaflight? I guess not? Besides the possibility to use smaller boards (smaller MCU footprint). I have neither used betaflight recently nor at recent (f4, f7) boards.
I have flown on 4 different radio protocols now and I feel like I can definitively say that the advantage to betaflight is not in the radio selection. The Silverware magic persists across them all.
Thanks. That’s what I wanted to confirm
I concur, the magic is not just down to Bayang. Its something that will hopefully always be different to betaflight and give silverware a unique place amongst the other flight firmwares.
I have 4 e011 by now… and one of those after a crash doesnt work anymore…
Anyone had this problem before ?
(flash it again and still the same )
You may need to replace the cylindrical crystal on the board. They are susceptible to breaking after hard crashes.
Awesome! Happy to hear you say this, its very true. Ive been using an FS-I6 for years now and its only 40 bucks for the transmitter itself and you can get rxs that weigh only 1 gram and cost 6 dollars so its very budget minded and wont increase weight as much as some sbus rxs. Hope to see this change implemented some day as itd open up tons of options!