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 final #4855

Open
Nihilistic opened this issue Jun 19, 2019 · 9 comments

Comments

Projects
None yet
4 participants
@Nihilistic
Copy link

commented Jun 19, 2019

Steps to Reproduce

  1. Install iNav 2.2.0 on Matek F411
  2. Wire TBS Pro32 HV to ST1 pad
  3. Enable Softserial in settings
  4. Configure smartaudio on ports tab
  5. Does not work, dashes appear in OSD where band/channel/power should be.
  6. SA control works correctly with the exact same settings/config/wiring with an older TBS VTX with SA 2.0.

Additional context

https://pastebin.com/hfsT0uV3

INAV/MATEKF411 2.2.0 Jun 18 2019 / 14:54:48 (5e5551bd3)
GCC-7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

(edited by @digitalentity, added context from #4862)

@issue-label-bot

This comment has been minimized.

Copy link

commented Jun 19, 2019

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

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

@teckel12

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2019

Something that may help with SA 2.1:

betaflight/betaflight#8276

@crybeFPV

This comment has been minimized.

Copy link

commented Jul 7, 2019

Same here in 2.2.1 on Matek F722-STD withTBS Unify Pro32. Flashed forth and back with Betaflight 4.0.4 where everything is working fine.
Please merge the current Betaflight Code for Smart Audio. Thanks for all your work in the inav project @devs

@teckel12

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2019

@crybeFPV Looking at the Betaflight changes, they're fairly drastic for SA 2.1 support. They changed a bunch of things so it's not at all as simple as merging some code into INAV. There will be a significant amount or re-work involved or it will need to be re-written to work with the INAV code.

The other issue is that no core INAV developers have a SA 2.1 VTx to test with. TBS is going to supply a few SA 2.1 VTxs for development/testing, but there's no promises on when this will fit into anyone's interest schedule.

Finally, I've heard that some are still having issues with SA 2.1 in Betaflight. So I'm not totally sure the Betaflight code can be used as-is (again, test equipment is needed to confirm or deny this).

Basically, it's known that it doesn't work correctly in INAV at this time. Also, pull requests with the Betaflight SA 2.1 code is encouraged.

@Jetrell

This comment has been minimized.

Copy link

commented Jul 9, 2019

Just thought i'd say, that I'm interested in seeing SA 2.1 working at some later time, as well.

@teckel12 I'm finding that the 2.1 BF development SA code is working fine.
I think most of the problem... Is that users aren't loading the correct table for their VTX... or aren't loading a table at all.

@teckel12

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2019

@Jetrell That appears to be correct, that the current problems in the latest release of Betaflight are because people are not setting up their VTx correctly. That's also exactly where the complication is with porting the Betaflight code into INAV. A lot was changed in Betaflight to create the VTx tables, and going that route may not even be an option for INAV.

@Jetrell

This comment has been minimized.

Copy link

commented Jul 9, 2019

To be honest. I'm not totally sure that the tables are that important anyway.
It appears to me, that the main reason they have been implemented. Is to keep users compliant with there local frequency laws and power levels.
We have got by just fine, selecting the correct frequencies and power levels in the past. Perhaps the port from BF could be simplified much more, by not including the table function at all.

@teckel12

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2019

@Jetrell I believe it's part of the same PR, or at least based on it. In any case, it adds to the complexity.

I would like to see some type of customization of the VTx power levels. It's kinda a hot mess right now with every VTx manufacture having a different number of steps and different mW levels. It would be nice if the user could select the number of steps and each of the mW levels as there's a lot of confusion with the current system.

We are, however, getting ahead of ourselves. I just talked with Trappy again today about getting SA 2.1 samples to begin testing with. I don't see any progress being made till there's samples in developer's hands as obviously trying to implement SA 2.1 support without the hardware wasn't successful.

@Jetrell

This comment has been minimized.

Copy link

commented Jul 10, 2019

Thanks for talking to Trappy about the matter. Hopefully he can forward a few to the guys here 👍

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