Betaflight 3.3 RC1 Smart Audio? #5192
Comments
|
Betaflight can not help with this "Issue". AKK VTX/ Mach 2 VTX arent compatible with SmartAudio. Which is the reason they never worked with KISS or Raceflight Firmware. Betaflight somehow just had a Bug which made it compatible with thier Implementation. Betaflight fixed this bug and will not reintreduce it into the Firmware just for making a broken implementation work. Sorry for the inconvenience |
|
new Eachine TX5258 same problem, smart audio does not work, money is thrown out |
|
This has been public knowledge for a while. Unfortunate side effect of buying cheaper alternatives |
|
@RoughRiderFPV you also have this issue with unifys? Do you change channels via Lua script? Did you update those? |
|
Maybe we can create smartaudio_quirk cli option to force old working behaviour for cloned vtx and close those repeating issues for ever. |
|
@wind0r Considering it right now, but was loving the clarity of the Mach 2 over the unify. I have not been able to figure out the Lua yet (3 kids doesn't leave much time) to change channels but as far as OSD with 3.2.5 I loved it. I have a 5v unify but went over to the Mach 2 because I was having issues with it. Main issue being clarity of signal. |
|
@RoughRiderFPV: So in the case of the unify, there is no difference in how they work between 3.3 and 3.2.5? |
|
You could probably intruduce a cli option as @jirif suggested and revert this removal |
|
Only this change is important as far as i know: we have cli option vtx_halfduplex so i suggesting introduce new one with name vtx_stopbits with values 1 and 2, default 2. 1 will be for clones. I do not have this hardware to test it so if someone confirm than its correct its easy create PR with such feature. |
|
@jflyper it's always OK to use 2 stopbits instead of 1 on transmitter (receiver sees it as small delay between bytes). |
|
The problem with the AKK VTX seems to be that they always need two stopbits and this change (#4636) removes one stopbit when using software serial (this is in line with the protocol specifications). You could introduce a cli option to add the stopbit when using softserial. |
|
The stop bit is not the issue. In extensive testing, it turns out the AKK
VTX depends on an extra 0x00 byte at the end of the transmission. This byte
is not part of the specification and should not be there. It appears that
this byte was in the BF code originally to handle a high floating voltage,
which caused issues with softserial. The floating voltage has been fixed
with new serial options so the workaround is no longer needed.
Unfortunately, AKK appears to have reverse engineered the code and
misinterpreted this byte as part of the spec and created a dependency on it.
Long story short, this dependency is flawed and breaks support. This issue
is also present in RF and KISS, so they're pretty much unsupported on all
platforms.
…On Feb 19, 2018 5:02 PM, "Simon" ***@***.***> wrote:
The problem with the AKK VTX seems to be that they *always* need two
stopbits and this change (#4636
<#4636>) removes one stopbit
when using software serial (this is in line with the protocol
specifications). You could introduce a cli option to add the stopbit when
using softserial.
What do you think @codecae <https://github.com/codecae> ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5192 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHyTqaPgL-_6Iepa5cg5dqd8g1uO4pYEks5tWe-QgaJpZM4SEzy8>
.
|
|
I too use mach2 (based on "reviews") and I am currently staying at 3.2.4 just to keep functionality. I don't know about others using sa on softserial but I have not used it (sa) in that scenario softserial. According to this si-gr@90efdec there is three lines of code that differs from the "spec". Wouldn't a cli command coupled with simple if statements be able to accomodate at least the mach2 users who were making a purchase based on "reviews" and not necessarily on the basis of "supporting clones"? There are some of us who are just trying to enjoy the hobby but are getting jammed up when we try to work within a budget. I don't attend any multigp or sanctioned events but now I have to use "licensed" equipment just to fly at my local park? Anyways, I hope this can be done to help some of us who are just trying to fly after a stressful time at work versus being "approved" for sanctioned events. |
|
Ah, okay. Thank you for the clarification @codecae . |
|
It would be nice to have BF policy on these compatibility issues. Personally I would add new |
|
Many people use soft serial for things like SA. Not uncommon at all. When it comes to the philosophy of "compatibility", AKK owes the community, including RDQ, the respect it deserves. This is a failed implementation of a protocol, not a bug in Betaflight. Therefore it is not Betaflight's problem to fix. Creating things like CLI commands for one-off failures in implementations is not the answer for a few reasons. First of all, it permits these companies to deliver faulty product into the wild with the expectation that BF will cave and hack workarounds into the flight controller by introducing purpose-built pollution into the codebase that eats up arguably small, yet valuable flash space. As it stands today, builds often fail due to flash overflow (especially OMNIBUS). Code such as this will exacerbate this issue. Secondly, it does not create incentive for them to fix the problem. They will continue to plague the market with broken stuff. This good for nobody, except AKK. Let us not forget that this is not only an issue with users of Betaflight. It is affecting users of KISS and RF as well. "Fixing" things in Betaflight will not fix the problem for everyone. Clearly, the product was not tested for compatibility with all platforms before going public. As long as there is an avenue for "compatibility" the problem may never get addressed. Sadly, it is the customer that bears the brunt of the issue. We all understand that people pay their hard-earned money to stay in this hobby and don't want people to miss out on capabilities. However, it should be beholden of the manufacturer of the product to make this right to it's customers. Everyone, on every flavor of flight controller, should be able to reliably use these products. The only right way to fix this is to hold the manufacturer accountable for fixing and adequately testing their products. I can bring up the concept of a #define with the members to see what they think. It is not only my call to make. At the end if the day, we are advocating for the public in this matter by holding the manufacturer responsible for their mistakes. |
|
I personally understand where you are coming from. Currently akk/rdq (for the most part akk) is stating that the only fix they have is to provide custom compiled versions of the betaflight code for target boards. I had requested on several occasions for akk to provide updated binaries to allow existing vtx's to be updated. The "general consensus" is that akk "cannot" release such a file for fear of "it being copied". Where is the fear from? Akk? TBS? I had stated to many people that waiting for akk to provide the custom bf files is not a viable solution. For the majority of hobby flyers (myself included) we really don't want to have to keep compiling versions of software especially considering that a build environment would have to be created for one minor task. The reason I believe that having custom files provided by akk is not viable is because the release of bf changes (especially non-stable versions) will inherently have bugs in them that will not present itself without real world scenarios. If I use a custom file from akk I no longer have the "direct support" of the bf dev team if I need to report a problem. The first reaction would be to go to akk to resolve any issues and verify it is in the base code. Joshua Bardwell argued the smartaudio code was inherently open source by the simple means that it was included in the bf code. Now, I am no expert in the background wheeling and dealing of monetary gains involved with bf and other entities...but to again punish the everyday flyer for the mistakes of many is just financially disheartening. Not only am I out money for the vtx that has now been crippled due to miscommunication on multiple levels, but I have to again spend more to find another vtx that is to "spec". Akk offered a 50% off of new vtx's but only up to 2 vtx's. Really? I am still out money overrall. On all sides there are entities trying to monetize on everything and all we are told is to part with our hard earned money and "trust" that what we are buying will work. Bardwell recommended the mach2. RDQ interacted with akk to create the mach2. Akk reverse engineered an "open source" protocol that was inherently flawed by the bf team. The "open source" protocol code wasn't available easily (I couldn't find it before or after this fiasco). Through this I am still the one who ends up paying out of pocket. As the public we are expected to hold manufacturers responsible but besides refusing to spend money (which is what I believe is the heart of all this) the public has no strength in this matter especially in this particular facet (software development) because at the end of the day all we as the public can do is ask all entities involved if they will play nice with each other to allow joe schmo to just fly a battery pack after work. How about holding the software developers (bf and tbs) accountable as well? There is enough blame to go around. Why can't akk be allowed to release binary files to update existing vtx's? At the end of the day...I am forced to stop spending money on budget items. I am forced to "have to" spend more money on items that are "licensed" for sanctioned events that I will never go to. My financial budget and priority for this hobby is low. It is not that I personally cannot afford these items, I just don't need a corvette to drive the country side hills for a relaxing outing. This is not my main source of income (as a racer, promoter, developer, proprietor etc.) but I am being strongholded into parting with my hard earned income. I am sorry for the rant. If you feel you want to block me, ignore me, or whatever that is completely within your right. It just seems childish that no one wants to work and play well together before putting the dollar ahead. I never truly expected bf to keep the "bug" that smartaudio had but again I (and many other honest and hard working people) have been screwed every which way from sunday on this "issue". Thank you. |
|
Please submit your request to AKK as well. Tell them that their firmware has no commercial value for anyone besides them, they really should fix their flawed implementation (it's not just about wrong number of stopbits) and release an update for everyone's sake. |
|
AKK's decision not to release firmware and binaries is purely their own decision. A brazenly disgusting excuse not to support their customers, imho. If they don't want to distribute the binaries, they should recall the affected hardware and man-up to their mistake. Instead, they're creating political discourse in the community that is resulting in people, such as RDQ, TBS, and BF devs, getting lashed for doing no wrong whatsoever. Being an 'open protocol' does not imply 'open source'. For example -- Someone can implement TCP/IP on an embedded system without reverse engineering Microsoft's implementation in Windows. All they need to do is obtain the specs and build it properly. The specifications can be easily obtained and can be developed without a ton of brain-work by a capable engineer. Implementing a serial protocol is not rocket science. The practices made evident in the testing of this hardware exhibits design decisions that are not common or practical. Any engineer with experience developing serial protocols knows that it's pretty much standard practice (with exceptions) to interpret the CRC as the last byte of a frame. Instead, the engineers built a dependency on data that has no reason to exist that is transmitted after the CRC. For the record, the implementation in BF was not "flawed" as you say. It was augmented to support other features on the flight controller. The way the VTX interprets the serial data should not be tightly coupled with a given implementation of the protocol. Implementations change, so the VTX should've been built appropriately so those changes would not create any impact. BF and TBS should not be held accountable for AKK's lack of desire in properly implementing and testing a widely used protocol. Their lack of due diligence has erupted into this entire debacle. They should've implemented and tested it on every platform available and they did not. If they did, we likely wouldn't be having this conversation. AKK can release binaries if they want. That is completely up to them. Nobody has to "allow" them to do so. They're just choosing not to support their customers. I could personally care less what they do to resolve the issue, as long as they do something. I have no desire to block or ignore you. Your feelings are felt by many and I can understand where you're coming from -- it's utterly frustrating for everyone involved. All of this frustration should be summarily dropped in the laps of AKK so they realize that it's up to them to bring it to resolution. |
|
Forcing customers to purchase something new in exchange of receiving support for something they already own feels like extortion, to me. |
|
@ijustwannafly Another way to look at it is most (if not all) BF devs are doing this for fun/free/volunteer . It sounds like most people involved don't want to spend their free time trying to fix and support a broken protocol. As far as I know AKK hasn't really been involved in any BF work. I'm sure they could get some of their developers to spend a little time chatting and working up new features. If AKK was an active participant maybe the bug could have been fixed much much faster or some other workaround could used. Maybe they could write a feature to reflash the vtx over betaflight... There are a lot of manufacturers or representatives that drop by the betaflight slack or put in pull requests. This help make betaflight stronger and better. Other companies build products and ship them and rely on betaflight devs to fix their issues and support their products (support is a huge time suck). AKK isn't the only one, there are a bunch. Basically AKK not supporting their products wastes a ton of the volunteer developers time (and money). It sucks that you are out money because of this, but having developers pay in time (and money) to support it also sucks. |
|
We should really have a list of what companies support betaflight in terms of features or pull requests or sending hardware to developers. That might help people make decisions on what products to buy. |
|
Clicking a few thumbs up and whatnot just doesn't seem like enough to acknowledge your time and effort (and measured response), @codecae (et. al). Really, thanks for taking the time to explain all this. I feel like BF devs are getting absolutely hammered recently - really hoping you all keep your brilliant minds in the game despite this high drama period. BF really just seems to be getting better and better. |
That does not sound right. The one fix that will work 100% is to replace the faulty VTX with one that works as described. If you bought a monitor for your workstation, and after a Windows update, the monitor suddenly stayed black, would you go and complain to Microsoft for breaking your monitor? AKK / RDQ and the vendor you bought the VTX from have sold you a faulty unit. In most countries, there are laws that require manufacturers / importers / vendors of faulty goods to replace them at no cost to the consumer. What about going and invoking your right to this? |
|
I completely agree with you on all points. In fact I reached out to akk facebook pm to inform them they should reach out to the bf devs to get this issue resolved somehow. A list of manufacturers who openly and actively support betaflight would definitely benefit everyone. I wasn't trying to imply that bf devs are not doing what they should be doing. In fact I did state that I never expected betaflight to keep a broken function. Betaflight in my honest opinion has been doing a great job. The request to keep the bug was more the users concerned that akk/rdq has either been silent on a resolution or offered a non-viable option. I have personally tried to get the ball rolling on akk even outright asking them to provide an updated binary. At one point an idea was offered to have the customers send their vtx's back to akk or an "authorized" whatever to have the vtx's updated. Then the question was asked why we couldn't update ourselves. The biggest point really is that the consumer who fell into this situation based on trusted "reviews" is now left holding the short stick. On the one hand the manufacturer, even when requesting, has all but dumped the existing vtx's and is instead hoping that the consumer will purchase the "newer fixed" vtx's. On the other hand the bf devs could possibly help to alleviate the financial hit to the consumer by allowing some sort of support for those who can't or won't upgrade/replace immediately. Akk has already stated in their rcg thread that the vtx's won't be replaced 1for1 but instead a 50% off coupon can be used toward the purchase of a "fixed" vtx but only up to 2. I enjoy betaflight and I have seen firsthand the devs willingness to work within reason. I completely understand the dev positions. I am just trying to advocate for the consumers caught in the middle that we have been forced to lose money on this situation and this kind of request (bf allowing support) is a last resort as the manufacturer has clearly decided to let this issue die with the consumers money in their hands. |
As stated above, in most jurisdictions they, or their resellers, are acting outside of the law if they are doing this. It is up to the users in these jurisdictions to hold them accountable for this. |
|
@ijustwannafly apologies, I wasn't really trying to imply that you, specifically, were hammering the devs. that was just a general observation. this thread has been remarkably civil and seemingly productive in my opinion. Full disclosure: I have two AKK VTX's. I didn't pay for them. They provided them to me for free to review. Betaflight shouldn't support this in my opinion and AKK should continue to release custom hex's. It's painfully clear that they are incapable of producing their own binaries and that they rely on their user base to provide these files (that's their effort level). For the future of support if you run into issues related to having to roll back SA updates there should a red flag that indicates why you might be having this problem. I can't believe RDQ isn't replacing these. AKK i understand (or expect), but RDQ not providing replacements is pretty crummy. They even still have this somewhat fine print warning:
|
|
The bit about RDQ still stating the vtx is not supported is also disheartening since there hasn't been too much news regarding the issue except through other means that simply restated the non-working scenario. I am hard pressed to find any information on the RDQ site that says I can input my order number and have it replaced. Anyways, I really just wanted to get eyes on the situation since really there has been no big news development on it since Nov 2017 when the first "uh-oh" moments came about the issue not working. Rc2 is now available and the last statement I can find from RDQ is on a youtube comment stating that "it WILL work with bf 3.3". Me personally, I have started ordering replacements. But again, I do feel for the others who simply don't have the financial ability to just turn around and buy replacement equipment. Some are either still in college or in their late years of life with fixed incomes. Others like me would rather just buy once and replace when physical damage is incurred rather than because of a software error. From the bf software side I have no complaints. The situation just sucks. Such is life (queue the "Lonely Man" theme song) |
|
Indeed, @DieHertz, that's definitely true; this fork has definitely moved past the loud statement stage though. Sorry - I should've just stayed out of it. I'm just blathering. I definitely see both sides of the coin here. @JonnyPhenomenon how long ago did you purchase the VTX? Can you really not have RDQ fix the issue - my credit card pushes the effective return limit out VERY far. |
|
My mistake @DieHertz, I updated to 3.3, and unlike what I had read on rcg smartport is working fine with the EWRF e708TM3. |
|
They ultimately did offer a fix:
|
|
@localidiot it's not likely that Microsoft would issue a fix for, say, Nvidia's poor hardware implementation and drivers. They would depend on Nvidia to fix their problem, mainly because the hardware is proprietary and updating a software framework is not the solution for a hardware related problem... No matter, though, we have posted a workaround for download. |
|
I still don't understand why everyone is pissed at Betaflight when this hardware doesn't work on KISS or RF, either. Feels like all of the hostility lands in the lap of Betaflight when it's an industry-wide incompatibility. As far as I can tell, we're one of the only ones who really made it right. |
|
I totally side with you, but people get pretty upset when something works for a while and then a software update stops it from working. RF/KISS, it just never worked - easier to blame the manufacturer there. To be clear, it IS the manufacture's fault. BF is still also the bargain hunter's platform where protesting online mercilessly may be worth it to avoid having to buy something new vs. others were the time wasted waging war exceeds the price of just buying a different product. |
|
Just so it gets noted- Butterflight natively supports this with a slider (and CLI command) to enable the AKK hack. Confirmed working on my DYS F4 after spending a STUPID amount of hours trying to get smart audio working and finally finding this thread... sigh. Just flew it moments ago and I'm super happy I finally have something that works. I work in dev and really dont agree with some of the previous comments. Agreed it is an AKK problem but when one has the power to "mitigate" a bug- it is usually in their best interest to do so. Beating up end users will not cause the OEM to repair anything any quicker (usually). And in this case, all hardware would have to go back since they are not supporting a field repair. This is not ideal. Thanks to everyone who posted here! Nasty little bug to try to sort out if you don't find this thread... Cheers all. |
|
I think the purpose of blocking non-compliant hardware was to make OEM react and fix their products which they did. All products shipping from RDQ and AKK have the non-buggy version. Congrats to BF for that achievement 🍰 However, users with old non-compliant hardware are stuck and cannot use the latest and greatest betaflight, I know there are maintainance branches, forks and other means to get it to work but this is a pain. Moreover, many of us, me included, don't necessarily want to spend money on a new compliant VTX. @BF-devs would you reconsider adding the switch at least as a CLI so your users are not stuck? Is there any downside doing this (I heared about some firwmare size constraints on old boards)? |
|
It's added back for 3.4 and there's a custim build for 3.3 |
|
@DieHertz Do you mean smartaudio "v1" will work now ? |
|
@Vidalcris now? I don't know what version you're at, they'll work in 3.4 and in custom 3.3 branch available from ci.betaflight.tech |
|
"Now" mean what it mean dont you think ? I'm using the latest available build and this is not working. (Betaflight / OMNIBUS (OMNI) 3.4.0 Jun 9 2018 / 07:40:22 (f8a86d6) MSP API: 1.39) |
|
Which PR is supposed to re implement this ? |
|
This is the PR : #5448 I dont know how to explain correctly my feeling about this ... for sure i dont understand why this PR as been closed and not Merged as it should ! Isn't BF for the people ? ... So @DieHertz when you say "they'll work in 3.4" look like you are not aware about some interests in here ... maybe some people receive more money than you can imagine on this story .. idk @codecae thanks a lot for your PR, as i said, thanks to you now i'm able to make the latest build working with smartaudio v1 ;) |
|
@DieHertz just made a false claim. This can happen. He mixed something up. This wasnt on purpose There is a public statement about this and also many post here describing the Problem. There is a branch which keeps those bugs to stay compatible but there is no reason to keep bug in some bigger codebase. This just will lead into Problemes. I wonder why People come here again and again. When there already is a Solution and also the Problem isnt even caused by betaflight. Those VTX simply do not work with any Hardware. Those VTX just need a software upgrade. This happens when you do not read a specification or do not do any testing (e.g kiss and rf never worked with those old vtx versions. easy to spot that there is something wrong since kiss and rf work with other SmartAudio implementations). Betaflight will not be the dumpster projects which fixes broken products. If we would start with such stuff it will get out of hand. First AKK VTX, then there is some esc which speaks dshot but a little different. then there is some FrSky Smartport which is slightly different and so on. Technical Specification are there for a reason since it is easy to test and implement against those. |
|
Yeah, sorry. |
|
@wind0r I want the latest build working with v1 this is why i need to make my own build actually. You keep the same position... those VTX were working perfectly and are working perfectly with #5448 ... Oh also i'm not part of "people" i hope ... I'm far from a basic user ;) @DieHertz Its ok, thanks to you i did some research :) I dont care about the public 3.3 AKK ... so "for you" is not working here ... stop being patronizing with me please ! |
|
@wind0r I totally understand your point for not supporting faulty products. Stick to the spec is good, when there are specs. And this is where I diverge: it worked before, based on no specs as they were not public AFAIK. Then the specs were released and you decided to stick to it but it broke for some products. You punished the manufacturer for making bad clones, at the expense of letting down some users. I can understand this trade-off. Fast forward to now, manufacturer fixed their products and the only thing this achieves is letting down the users that bought a "v1" and are stuck with it. I know there is a branch, that's not very user friendly though and doens't allow for advanced users to test against latest build it seems. I'm no BF dev but a CLI option and an "if" statement doesn't seem like a big deal to maintain, that's no more work than branching. Just put a comment there as a reminder that this is not strictly in the spec and forget about it. |
|
Do we really need to discuss this with every stranger coming here every once a few weeks? |
|
So I'm guessing sheer pride? |
|
(Il est et restera condescendant ... La france en force ;) lol You should just close this discussion..and block comments ... like that the "Strangers" will not importunate you anymore ;) |
|
First of all, and since it looks that AKK still has not fessed up and replaced the defective hardware they have sold, we have added an official branch of 3.4 with the AKK/RDQ patch applied: This will be kept up to date with the latest release of 3.4.
As has been stated in here before, this is wrong. The SmartAudio spec that was used to add SmartAudio support to Betaflight is publicly available, there was no NDA between TBS and Betaflight for adding it. Point in case, a number of other manufacturers have released VTX with SmartAudio, and all of them managed to implement the specification correctly. @Vidalcris: You need to stop insulting people in here. |
|
Rofl where am i insulting people? |
|
I'm waiting a reply! You are insulting me while saying that im insulting but now i want proof of what u say! |
|
Nice! Thanks for getting the maintenance branch setup! FWIW, this was AKK’s statement sometime back (some of these offers are no longer valid though):
|
|
Just noticed maybe this is the branch you meant to link to @mikeller: Thanks again. |
|
@Diaoul the spec was released 2 years ago. VTX-Stack got refactored to allow different stuff (like low/high power on arm) and after that people noticed that AKK is broken. While reworking the VTX-Code stuff some bug in betaflight got fixed. Which somehow also made those VTX not work like with every other Firmware. When it just is a CLI Option and some IF i wonder why KISS and RF also do not implement it. It simply is unneeded technical debt and as allready described above first it is some vtx then it is some broken telemetery or strange rx glitched that bf need to write just some CLI Option and IF for. The Branch is middle way we choosed for this Problem and we explained it multply times. Even with a big promoted facebook post. We could argue more and more about this topic or just move on. @Vidalcris i dont think insulting was the right word to choose here but i also find your behaivor here toxic. Writing different languages and to mock us. This isnt the attitude we like here. I think you clearly understand was mikeller wanted to say with his post but you still move one. I think every Question got answer here mutliply times. The offical statement is on facebook and also in the PR #5448 which @Vidalcris allready liked above. |
|
I was just asking about the mistake said by Diehertz at start... Yes i know what mikeller mean but he should take some more time to choose his words (we are thinking the same about this point.). Without @eggbenedicts help i was unable to find #5448... I searched for two days how to modify the latest build to make it work with v1... No one talked about #5448! Oh one last thing.. All i said in french, i already said the same in english, and this is for Diehertz... Not you... |
"For you" is an impersonal form which means all the users. |
|
@EggsBenedict: Thanks for correcting the link. I was writing the reply above from a mobile. @Vidalcris: You and I both know where you insulted people. I am not going to drag up posts that you later on deleted or revised. And I will not stand to be attacked like you seem to be intent on doing, I think it's better that you stay out of here from now on, or behave in a civilised way. |
I have an issue. I use nothing but unifies and mach 2 vtx’s for the Smart audio function. I had to revert back to 3.2.5 to get that working again since my button doesn’t work on one of my builds. Will there be a custom FW or a revision to the current RC that will allow this to be possible to use or is Smart Audio going to be dead?
Other than that, I loved the build whilst beta-testing. Love the new filters and would love to use it but the Smart Audio issue is killing it for me and I’m sure alot of other folks too.
The text was updated successfully, but these errors were encountered: