Offer selection of telemetry sent over FUEL sensor with FrSky otx/etx?/ethos?
Good afternoon Brain Devs.
Just wondering if you could add a drop down (or something) to choose the telemetry data sent via the FUEL "sensor" on FrSky Rx's & any others where you're using FUEL to send global vibration data.
Honestly, Gvib is incredibly useful to me for monitoring a heli's overall mechanical health & also aid mechanical setup & tuning.
But it also seems to be the one oddball that would lend itself nicely to allowing users of non Jeti equipment to be able to choose at least one parameter from the extensive list log-able parameters to send over telemetry in flight.
Obviously better if FrSky/everyone added some empty sensors for you guys to use, but I don't see that happening anytime soon.
So in the meantime I think it would be a worthwhile addition & I'd definitely use it quite a bit.
FrSky telemetry, compared to Jeti telemetry is more limited. Only the sensors already provided by the manufacturer and managed in the firmware of their transmitters can be handled.
I have been asking FrSky for six years to include a vibration sensor among the various sensors, but evidently the helicopter sector is not considered a priority by FrSky (although I think that being able to measure vibration on airplanes and drones as well could be very useful).
It must be said, however, that it is not only FrSky that has these limitations; other brands have them as well.
Not having a dedicated vibration sensor available, the "Fuel" sensor (also available on other brands of radios) that has been working for several years with OpenTX and EdgeTX operating systems was chosen.
Unfortunately, with Ethos unlike OpenTX and EdgeTX, Bertrand Songis has decided that the maximum value acceptable from the Fuel sensor in radios with ETHOS operating system can reach a maximum of 100%, higher values generate errors, the value turns red and the "sensor lost" voice alarm is issued.
From the flight logs we have received in recent years, we have seen that the vibrations of our users' models can vary from zero to values as high as 2,000%
For this reason, in the instructions for Ethos telemetry and integrations, we recommend deleting the Fuel sensor after it continues to be automatically recognized by the transmitters anyway, so as to eliminate this cause of false alarms.
We have also discussed this problem countless times with Bertrand Songis but he has been adamant. As of today, those who want to receive model vibrations telemetrically must necessarily use OpenTX or EdgeTX operating systems and not ETHOS.
Note: FrSky expects that up to 16 sensors of the same type can be used on the same model. We assign the sensors emulated by our flight controllers the sixteenth sensor.
So a "real" "Fuel" sensor can also be used as long as it is programmed to function as a sensor between 1 and 15.
All great info but I guess I wasn't clear/you misunderstood.
I already love the global vibrations being available on otx/etx with the emulated fuel sensor.
What I'm suggesting is to open that sensor up so users can decide what they want to use it for. So instead of global vibrations users can choose rotation rate, or iKon2 reported frame rate, or iKon2 reported frame losses, or an acceleration, etc, etc.
But damn, that sucks about the rigidity/pushback with Ethos. I was thinking about changing from otx to Ethos, but that's a deal breaker for me.
This is unfortunately not possible with OpenTX/EdgeTX/Ethos.
Instead, it is possible with Jeti, which, as we have already mentioned, uses much more sophisticated telemetry data communication protocol.
Damn. Was really hoping for some kind of normalized % data that could be scaled with sensor ratios but I guess that starts getting complex really fast with all the different options.
Thanks for the quick replies at least!