Handle SA2.1 GET SETTINGS #4596
Conversation
|
Hello, I'm having trouble getting this to work: Matek F411-wing (MATEKF411 target) - ST1 pin I am getting "partial" SA, meaning I get the info on the OSD about channel, band and power, but I cannot set them... Using other SA device in the same configuration works as expected... |
|
I have the same issue with Smartaudio on TBS PRO32 HV vtx on softserial tx pin (F411-Wing). I believe others are having the same issue based on discussions in iNav fixed wing group. I will ask them to comment. Earlier Smartaudio versions seem to work OK. |
|
I don't even get SA OSD data. Same config as @putimir above, Pro32HV port set to SA instead of CRSF, SA pin to ST1 pin, configured SoftSerial1 in Matek F411-WSE for TBS SmartAudio, but I just get dashes for the OSD vtx channel display element. This is unfortunate. |
|
@leeph It's a known issue that SA2.1 isn't working in INAV. |
|
Is anyone biting into this? I guess it's a pretty massive undertaking right? What about backward compatibility? I heard somewhere that 2.1 should be backward compatible ?! |
|
I believe Andreas Kanzler has a repository for his port of the BF/SA2.1 code. |
|
As an update, I managed to get things working on my TBS Unify Pro32 HV under iNav 2.2.1 by updating the vTX from version 1.08 (stable) firmware to 1.12 (beta) firmware. Once I did that, the OSD started displaying channel and band and power, and LUA scripts etc started being able to send band/channel/power changes over SmartAudio, however I believe there is an issue with the power levels in that power level 4 is only 400mw and won't let me switch the vTX to full power 1watt mode, and that we need the VTX power level tables in order for this to work properly. |
|
Yes, I can confirm that (we probably spoke yesterday in one of the FB groups)... I was using a hobby grade IRC power meter, I get 400mW, almost to the point, when it switches to powerlevel 4 (upon arming)... I'm pretty sure the reading is ok, since, when I set the power via buttons or via TBS agent, the output fluctuates around 1W... |
|
Sorry didn't realise you were the same person :-D That sounds pretty cut and dried - thanks for the info - wouldn't have realised that otherwise. |
|
@leeph That reminded me. The problem with using the betaflight code is that they went crazy with the tables for all the channels and power levels. That level of complexity simply isn't needed. Instead, just an optional power level table that can be customized would be appropriate. |
|
What would be most sensible would be that the VTX contains an integer parameter that represents the power levels for that particular vtx and the SA protocol simply provides for communication of that parameter to the flight controller or other SA host device such that it can auto configure itself for the correct number of power level steps for that particular vtx. But that would be too sensible. |
|
As I understand, with BF, YOU as the owner of the VTX device, provide the tables for your particular device, of course in correct manner. This is ok in my opinion, because with the growing number of devices with infinate number of powerlevels and power outputs, bands, frequencies....the 'old' SA 25-200-400-800 (or whatewer), just wasnt enough anymore. People were getting confused, as they saw in OSD, their 8 megawatt vtx "is only outputting 800mW" and such... |
|
@putimir Exactly, which is the problem with "just using the BF code" for SA2.1 in INAV as it's all tied to the tables, which I 100% disagree with. Anyway... INAV is not interested in being that paranoid about frequencies and transmitter power. So using the BF code is out of the question, which mens writing it and not just porting it. Making it more challenging. I have it "on my list" but there's more to it than just having a free weekend. I need to build a test model with a SA2.1 VTx. I have the SA2.1 hardware, but not the rest of the build nor the current time/interest. If another INAV developer has the time/interest, I can get them them the SA2.1 hardware. |
|
I understand, well too bad, that iNav is not interested in this, I know I would like that kind of flexibility. But understandable, it just a case of what I'd like against what the others will sacrifice to bring us these functionalities. I know I'm grateful for every little bit that you guys develop. The only fact that I'll add is, that current situation is certainly not ideal, and every little improvement will be welcomed and beneficial. Is TBS helping here in any way? Thank you. |
|
My suggestion to the iNav developers was to set up a code/feature bounty system. Highly-desired-but-currently-unimplemented features can be shortlisted and then the user base funds them as they desire by way of donations to the particular feature they want implemented. iNav developers can pick whatever bounty they want - code it, and then collect on the bounty once it is implemented to the user-base's satisfaction. The idea has fallen on deaf ears - it appears the devs would rather carry on complaining about how they don't get paid for this hobby project of theirs. You can lead a horse to water... |
|
Not related to the issue, but, yeah, I would pay certain amounts for implementing features... |
|
@leeph For me, the bounty system would be worthless. I'm not driven by money, I'm driven by interest. I can see how some may see a $50 bounty and jump on it. But for me, it would be of no interest to waste an entire weekend for something I'm not interested in and get $50. I don't think it's fair to say that developers are complaining about not getting paid. I believe you're misintpreting. It's more like, INAV isn't my job, I have a real job, family, and my own interests. I don't have the time nor the interest to code this at this time. Nor is it my obligation to do so as it's my hobby, not my job. I hope you can see the difference between complaining about not getting paid and simply not being important because there's no obligation or interest. |
|
I'm not sure the video posted by Pawel could be interpreted as anything other than a bit of a moan. I can understand the money is not the driving factor for you personally. However you must understand that for your end-users, you have created a very popular product and they will always want more features, so there is this disconnect between the users wanting more, and the developers considering it only a hobby interest and so some highly desired features never get implemented. The code bounty can help bridge that disconnect - those developers who want to be remunerated can do so, the end users feel they can contribute to the project, drive it forward, and get something they want, and those developers who do it 'just for the love' can either collect on bounties or not - up to them. Anyway, obviously this thread is not really the place for the discussion which is why I created a poll on the iNav Facebook group. It seems the userbase is interested in the idea. |
|
@leeph For this particular issue (SA2.1). It was coded without the hardware, so it wasn't too surprising that it didn't work. I now have the hardware, but it's just a matter of priorities/interest (probably not until a new model is built). |
|
@leeph Sounds like a user problem to me. Accept and appreciate what you have, don't expect anything more, be thankful and gracious if something you're interested in gets added. That's how I consider open source and free projects. End users can contribute now. Learn to code and submit a PR. No money needs to change hands. The user base should take up programming if they want features added. This is on open source project, everyone can contribute. |
Port of betaflight/betaflight#7461
Fixes #4594