Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SA 2.1 not working in iNAV 2.2 RC2 #4852

Closed
Nihilistic opened this issue Jun 18, 2019 · 15 comments

Comments

Projects
None yet
5 participants
@Nihilistic
Copy link

commented Jun 18, 2019

Current Behavior

Steps to Reproduce

Expected behavior

Suggested solution(s)

Additional context


  • FC Board name and vendor:
  • INAV version string:2.2RC2

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.

@issue-label-bot issue-label-bot bot added the BUG label Jun 18, 2019

@issue-label-bot

This comment has been minimized.

Copy link

commented Jun 18, 2019

Issue-Label Bot is automatically applying the label BUG to this issue, with a confidence of 0.89. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

@shellixyz shellixyz closed this Jun 20, 2019

@Nihilistic

This comment has been minimized.

Copy link
Author

commented Jun 20, 2019

What? Why is this closed? Because the developers care about SA about as much as they did DSHOT?

@giacomo892

This comment has been minimized.

Copy link
Collaborator

commented Jun 21, 2019

Hi @Nihilistic

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:

  1. This is on open source project, you are free to try to fix things that aren't working as expected
  2. We as developers prioritize what we like to do. We indeed take a look at feature requests and presented issues.
  3. We do everything in our spare time, so bringing new features and fixing bug can take a long time.
  4. If you cannot fix by yourself you might want to hire a developer to fix it for you.
  5. You might also want to send a bunch of samples of the hardware that isn't working to the developers and gently asking them if they are willing to give a look at the issue.
  6. INAV is an invaluable piece of software, millions of work hours have put into it and its predecessors, respect this, developers also cared about you since you have a machine flying with just a pointless feature possibly not working.
@shellixyz

This comment has been minimized.

Copy link
Collaborator

commented Jun 21, 2019

@Nihilistic No need to get all worked up. I closed this because it is a duplicate of #4855

@Nihilistic

This comment has been minimized.

Copy link
Author

commented Jun 21, 2019

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.
[(https://www.youtube.com/watch?v=DALHYt6V77Q)]

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.

@teckel12

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2019

@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.

@giacomo892

This comment has been minimized.

Copy link
Collaborator

commented Jun 21, 2019

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
2)go complain with TBS to fix their issues or add support for that VTX into INAV. They have the resources and it is legit if they use 1 cent of your 50USD to pay a developer that is able to submit a PR to INAV and apparently BF too.

@shellixyz

This comment has been minimized.

Copy link
Collaborator

commented Jun 21, 2019

@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.

@Nihilistic

This comment has been minimized.

Copy link
Author

commented Jun 21, 2019

@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?

@teckel12

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2019

@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.

@Nihilistic

This comment has been minimized.

Copy link
Author

commented Jun 22, 2019

@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?

@giacomo892

This comment has been minimized.

Copy link
Collaborator

commented Jun 22, 2019

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?

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.

code that for you

i'd say, code that for YOU first of all, then share with others!

What are you going to do?

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

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?

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!

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jun 22, 2019

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.

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.

@Nihilistic

This comment has been minimized.

Copy link
Author

commented Jun 22, 2019

@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.

@digitalentity

This comment has been minimized.

Copy link
Member

commented Jun 22, 2019

@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.

@iNavFlight iNavFlight locked as too heated and limited conversation to collaborators Jun 22, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.