Will there also be an integration for the new Frsky ETHOS?
Greetings Bernhard
Unfortunately, the current version of the ETHOS operating system, unlike the OpenTX operating system, does not yet have a LUA interpreter to run LUA apps, including our Integrations.
We know that a few days ago FrSky released an internal Alpha version that should also contain a LUA interpreter with which to make the first internal tests.
Both us and our Beta testers are waiting for the beta release of this new version of ETHOS to verify if the version of the LUA interpreter made by FrSky contains the same commands of the OpenTX LUA interpreter and therefore if our APPs work also with the version made by FrSky of the LUA interpreter (there is no universal standard for LUA interpreters, each company makes its own LUA interpreters with specific instructions for the product on which the interpreter is run).
So for now we are not yet able to test and know.
If our app doesn't work, we will need FrSky to realize and provide the documentation of the commands of the LUA interpreter they made in order to verify if the necessary commands exist and to be able to realize and test a specific app dedicated only to the ETHOS operating system.
Thank you for your prompt reply.
Greetings Bernhard
Hallo Brain Dev ,
Now Ethos support Lua. It is out of beta.
https://github.com/FrSkyRC/ETHOS-Feedback-Community/releases
Please integration for ETHOS !
Hallo Brain Dev ,
Now Ethos support Lua. It is out of beta.
https://github.com/FrSkyRC/ETHOS-Feedback-Community/releases
Please integration for ETHOS !
If and when the Ethos LUA interpreter will no longer be BETA and therefore subject to possible changes and modifications, but will be officially released, if it turns out that the final ETHOS LUA interpreter will not be compatible with the OpenTX LUA interpreter and therefore our current LUA applications will not work, then we will purchase a Tandem transmitter with Ethos OS and start working on the integration.
Hello Rik, plz keep me advised. 🙂
This is very exciting! I would love to have full integration with my FrSky X20 / ETHOS transmitter.
Just circling back to see if there has been any progress or updates on the LUA scripts for ETHOS?
Hi,
I have installed a TW Lite Pro and TW MX receiver into my 800 to try.
Radio is X18SE , Ethos 1.4.6 , Brain2 ver 3.4.100
Integration does not work.
Protos 380 with Archer RS and ver 3.4.094 works OK. Both are FBUS from RX to FBL. Also tried F.Port on TW MX and still doesn't work. Archer RS works in F.Port and FBUS mode.
I guess you probably haven't had a chance to test TW protocol with Brain2. I can do that if you have an idea of what is wrong.
Edit:
I spoke to my colleague, supposedly it only happens with external Twin modules, with Twin radios like Twin X-Lite integration should work ok. Working to get more info if this is something that needs to be addressed with the integration script or with Ethos.
First, you need to be sure that you are using the latest version 1.0 of our LUA app and not an earlier version (the LUA app version is on the transmitter screen top and center when the LUA app is run.
Next, you should not confuse different radio frequency protocols by which wireless connections are made between transmitters and receivers with the different RS232 wired protocols used for data transmissions and receptions between receivers and flight controllers. The Smart.Port, F.Port, F.Bus protocols are standards defined by FrSky to transfer telemetric data between LUA applications running on transmitters to flight controllers and cannot behave differently between receivers. Our flight controllers only deal with communications via the three different protocols mentioned earlier that should not change by changing receivers. If then some receivers work and other receivers do not work, that is not up to us but up to the firmware of the receivers (or different transmitters).
We suggest that you contact FrSky pointing out that unlike all Archer receivers and all TD receivers, TW receivers do not transfer the transmitted and received telemetry data streams correctly using the Smart.Port, F.Port and F.Bus protocols.
When they learn about the problem and manage to solve it they will release an update firmware for their receivers that will solve the problem.
Regardless of the above we do not understand why the "fad" of long range receivers designed only for FPV flights with drones is catching on even with RC helicopters with which being single-rotor by their nature unstable compared to four-rotor aircraft one has to constantly check their attitude by sight and therefore have to be kept at shorter distances. It seems to us that the market mistakenly believes that the low radio frequencies needed to achieve greater distance also guarantee greater reliability at short distances. Obviously this is totally false so much so that new WiFi Routers to be able to penetrate obstacles better and improve the transmission rate are moving from 2.4Ghz to 5Ghz frequencies.
I'm very aware that F.Bus and F.Port are different from the RF protocol (TW, TD, ACCESS, etc). I never said they were the same I was just pointing out how it was connected, since normally that's one of the information you want for troubleshooting, and historically there has been some differences in how integration works and historically Brain2 has had issues with FBUS despite it working fine with other systems. So I figured I'd give as much information as possible in case it was possibly relevant, but next time I can provide less information if that's what you prefer, just let me know.
Regrading TW and other "fads" it is not a "fad" at all. The twin RF link of TW, a LoRa technology equipped protocol, similar to ELRS which also uses LoRa are a very welcome improvement to the traditional FSK (Frequency-shift keying) technology RF links that RC has been using for decades. As you said, WiFi and etc are using 2.4GHz and 5GHz as well and of course you'll notice that the most recent innovations in RF technology like ELRS and TW both of which use 2.4GHz only are providing extremely good range and link quality compared to traditional RF links even without using lower frequency and that is certainly a good thing. It's better to have way more than enough range available than to lose signal because your flying field is in the middle of a very noisy RF environment. I fail to see why improving the quality and robustness of the signal controlling a very dangerous flying chainsaw could possibly be a bad thing. If I can improve my link reliability then heck yea I'm gonna do it, especially as the RF environment continues to get more and more noisy.
Finally, if you read the last sentence/edit of my post you'll see that it is reportedly only an issue with the use of external TW modules (in the Lite bay) so it seems I made the post in haste. I have already spoken to them about the issue and from what I gather it could be either a Lua script issue or an Ethos/Lua interpreter issue. I will report back with any new information I get and if it pertains to something you need to do I will let you know.
Good morning Keith,
Have you had a chance to try the new version 1.1 of the LUA app for Ethos yet to see if it now works also with external radio module?
We could not add the specific commands to enable telemetry communication with either the internal radio module or the external radio module since the LUA interpreter does not have a command to be able to recognize from the settings which radio module has been activated and used by the users, but we have removed commands that might limit the LUA app to work with only the internal radio module.
Since we don't have the Twin module to be able to test this, we would like to know.
Thanks.
