SA 2.1 not working in iNAV 2.2 RC2 #4852
Steps to Reproduce
Swapped out my ancient TS5823 for the TBS Unify Pro32 MMCX on a 5" quad with an F405-CTR. Tried soldering the SA wire to TX2, which did not work. Then tried TX5, and added the extra ground wire as well, and this did not work. I enabled the correct corresponding UART on the PORTS tab first by selecting TBS SmartAudio from the devices drop down box.
First of all @digitalentity worked in porting smart audio 2.1 into INAV and it should work, please re-check your setup again.
But then your attitude forces me to point of something:
It SHOULD work...but it DOESN'T. There's not much to check. Solder the SA wire to the TX pad of an available UART. CHECK! Enable TBS SmartAudio on the corresponding UART on the PORTS tab. CHECK! With this particular Vtx, there is a menu option to select OFF, CRSF, or SA. Select SA. CHECK! I've tried TX2, and TX5, neither work.
I opened a support ticket with TBS, and the responding tech said that he has received multiple complaints like mine, and they're looking into it.
I've read of others complaining about SA 2.1 support not working so well in BetaFlight either. Did anyone actually test the commit to see if it worked before closing the issue?
This Vtx is probably the most powerful 5.8 ghz Vtx you can buy. Instead of all these transmitters on the market that boast 800mw or 1000mw, but don't come near it. This one DOUBLES the rated power at every setting. If Breaksteel's video with his Rotor Riot RF meter is legit.
If ever there was a Vtx that NEEDS remote controllable power settings, this is the one. It's hardly a "pointless feature". You don't want to be farting around on the ground with this thing on full power, pumping out 2 watts, and hitting 200 degrees F without air flow over it.
I'd be happy if TBS would just release a firmware using the original SA, instead of 2.1. My Rush Tank uses the original SA, and it works fine on my other 5" quad.
I dropped $50 on this Vtx, and can't use some very important features, because the software hasn't caught up, despite this being a known issue since at least April.
The original TBS Smart Audio works great. Is 2.1 so vastly different that it's got you all stumped? I don't even know what 2.1 brings to the table...only that as it stands now, SA doesn't work at all.
For now, I have the Vtx wired to use CRSF via my Nano RX, but that means fiddling with the lua script right before taking off. The option in iNAV that lets you stay in low power till arming is so much better. And you can see what band and channel and power setting you're on in the OSD.
If I could change Vtx power settings via a switch on my Taranis through CRSF, that would be fantastic.
@Nihilistic See shellixyz's post above. It's appropriate to close this issue because fixing it in the latest release is more correct. Also, if SA 2.1 isn't working so well in BF either, it could be there's a TBS issue (maybe firmware differences from unit to unit for example).
In any case, just because it's not working for you doesn't mean it didn't work for digitalentity. He's using different hardware so there's no reason to assume the code wasn't tested.
Do you know how many of those 50USD ended in INAV pockets? ZERO So please don't use the money thing to justify the fact that it must work in INAV....
So you have some possibilities again:
1)ask for your money back
@Nihilistic I don't get what you're complaining about. The second issue you created is still open. Someone is going to take a look at the issue. I think only one of the dev team members have a SA 2.1 compatible VTX. Also contributions from TBS to test and make SA 2.1 work in iNav are welcome. Take a deep breath and calm down we're not responsible for your choice to buy a VTX with a control protocol that has very recently been added and might not work right in all situations yet.
@teckel12 We went round and round like this about DSHOT and F7 boards...and when you boys got over yourselves...then you were able to fix it.
The TBS Unify Pro32 HV is NOT the only Vtx affected by this. I've seen complaints from other sources about SA 2.1 not working on other TBS Vtx's.
@shlellixyz, It's fine dropping the duplicate. I just don't want to see this being ignored for months. The issue has been open since April or before, and a commit went forward into this release, which did not fix the problem.
These are pretty popular video transmitters, and with the kind of power this thing is blasting, it's going to appeal to a lot of those endurance 7" quad builders that want video range reaching out with their Crossfire or R9 control links. It's worth fixing, if you care about iNAV progressing.
@giacomo892 So iNAV is not so much open source as, grease my palms and maybe I'll code that for you now? You really want to just snub TBS and their entire line of popular Vtx, and all the people that would like to be able to use their full capabilities?
If it was tested, what Vtx was it tested on, and by whom?
@Nihilistic So what your saying is that you plan on taking this route each time you want someone to spend time writing code for you for free. I'm sure everyone can't wait to help you from this point on.
Please see the INAV new hardware policies here: https://github.com/iNavFlight/inav/blob/master/docs/policies/NEW_HARDWARE_POLICY.md
I would suggest you follow the new hardware policy for SA 2.1 support.
@teckel12 I thought the spirit of open source was that we're trying to work together to make iNAV as close to free and accessible flight controller software, because most of would rather not fork out for Eagle Tree Vector.
You seriously think I'm the only iNAV or BetaFlight user that would like to see SA 2.1 working? There are several TBS Unify products that are affected.
I don't see how you can miss the desirability of SA doing the power switching for you. I can do this with Crossfire, but I have to take my goggles up and squint at a Taranis screen to run a dodgy lua script, to do what iNAV would do for me automatically.
What are you going to do? Refuse to fix stuff to spite me, and screw how many buyers of these gadgets?
What's with the Runcam Split 2S control fix? We had a guy fix that, and you won't test it to green light it into a release, because I want it? What are you six?
We don't want to ignore anyone, reach out for TBS, again, and ask them to fix or send instructions to us to fix it, otherwise it's unlikely a fix will ever happen.
i'd say, code that for YOU first of all, then share with others!
Personally? Nothing at this stage. Cannot debug not working stuff without having it nor having a clear documentation of what's implemented into those VTXs
To ensure the quality of the code it has to be tested, unsure who has RC Split among developers.
Being said that man, i'm going to drop this if there isn't something new rather than insinuations and misconceptions about open source projects and our great team!
In case you didn't notice - you can download INAV totally free of charge from the release page, so we are pretty much at the "free" stage.
Now about the spirit of open source - you are free to take the code and do whatever you want with it (except making it closed). So, take it, fix the issue, have the fix merged back - that's about the "working together" part.
Can't code? Ask if somebody who can wants to look into the issue and get ready to donate some hardware so the issue can be properly debugged.
Can't donate? Ask hardware manufacturer to work with developers to fix the problem.
Can ask? I don't know what you can do at this stage, sorry.
@digitalentity As I said, I opened a support ticket with TBS, and the responding tech said they have gotten multiple complaints of this. I can't force them to either fix iNAV, or release a firmware update that enables the original SA to work with this Vtx. All I can do is voice my displeasure, and then vote with my dollars and never buy any of their shit again, until I know it works. Of course, adoption of new products and the evolution of this hobby will come to a crawl if everyone is waiting for someone else to be the first through the door.
Maybe you iNAV guys should tell Runcam and TBS and other hardware makers to stop making product claims that require as yet unwritten iNAV modifications to work. As for me, I'm done buying new FPV shit that's not been thoroughly confirmed and verified fully functional.
I don't know if any of the iNAV developers have reviewed any TBS products, and begged for affiliate link clicks, or begged for Patreon support, during such reviews. But, that was sure the case for the Matek F722SE. The target for that FC needed serious work for DSHOT and optimizations, and I was RIGHT. And I've gotten nothing but resentment for calling it out.
iNAV needs testers willing to put their expensive gear at risk, and willing to take the time to report issues, for our mutual benefit. But, apparently you don't appreciate us very much. If we're not coding, or slipping you a few bucks, or gifting you hardware, or carrying you through life on the shoulders of Patreon support, we don't matter.
@Nihilistic nobody forces you to use the firmware. Nobody forces you to support anybody. Nobody keeps a gun at your head when you buy the hardware. You and other users do that at their own free will.
To keep things moving forward developers invest their time, skill and equipment to write code; testers invest their time, skill and equipment to test code; people liking INAV click affiliate links, sponsor developers on Patreon, shared their successes and failures, report bugs or support INAV in other ways. This is how community works and those types of users are welcome, respected and their contributions appreciated.
However, there is always people who complain and demand stuff to happen without even investing a minimal effort to format the bug report according to the template. Even though, community may still benefit from those people since bug reports are still bug reports.
I would consider this matter closed now. Feel free to file high-quality bug reports or support INAV and you will get the gratitude of the community.