The whole problem with the passthru scripts is that they don’t have the information I need on the screen for gas helicopters. And that information is not available thru ArduPilot even if the scripts did display the right stuff.

So my thinking was when the pipe is already full, why try to stack more stuff on ArduPilot? You can mix and match, pull from the FrSky sensors what you need that ArduPilot doesn’t have, and use from ArduPilot what you want - and if the software don’t exist to do it, write your own.

One problem I had is that somebody in ArduPilot decided the temp sensors aren’t important because the baro has temp. So the temp sensors got repurposed for other things. Except if you fly a gas engine aircraft and want engine temp, now what? In order to get it to work you either have to change the ArduPilot code or plug your sensor into the SPort pins on the back of the radio and re-program with a Custom ID.

So the SPort code in ArduPilot could use a couple changes to fix some problems.

Except for the issue that I don’t have an analog sensor laying around with the right impedance to work. My Gas Suite came with two thermistor type sensors that are very accurate with no calibration required, so why not use those? Plug those in and they “just work”

My idea is that we should try to get as much sensor data available to ArduPilot, even that initially we don’t use it and as a minimum only report it, but in time we can start adding automation on ArduPilot to what makes sense using those sensors

My idea is that we should try to get as much sensor data available to ArduPilot, even that initially we don’t use it and as a minimum only report it,

There is some advantage to doing that with more generic sensors like hall effect or thermistor sensors. I actually am pretty sure hall effect sensors are already supported in the code. But they aren’t output to the FrSky telemetry.

one thing is sure, the frsky passthru library fills all polling slots for sensor 1B with some data, if there’s nothing to send it sends attitude info, so it always saturates all the slots reserved to sensor 1B
It would be interesting to check if regular frsky sensors behave different.

The only difference I can see in the ardupilot code is the number of sensors used.
Passthru uses only 1 sensor, 0x1B.
Repurposed sport uses 4 sensors

from what Chris observed using more sensors gives a higher link quality, maybe by using the same sensor IDs in the library would yield the same results, this would in turn prevent the usage of proper frsky sensors with the same IDs or we could try to use 3 unused sensor IDs to obtain the same effect?

The only difference I can see in the ardupilot code is the number of sensors used.

Passthru uses only 1 sensor, 0x1B.

Repurposed sport uses 4 sensors

I like the SPort better than the passthru. You can pick and choose what you want to display on a custom telemetry screen pretty easily. The passthru seems to saturate it and degrade the link quality. It uses too much bandwidth on the link.

I had it on my spectrum analyzer to see what was being used per channel in the 2.4 GHz spectrum. The receiver (XR8R) appeared to be hopping 50 channels @ ~95KHz per channel with passthru. With regular SPort with the Gas Suite plus some ArduPilot ID’s it was using ~58KHz per channel.

Which is still quite a bit wider than the old 20KHz channel spacing used to be with 72MHz radios. But those old 72MHz radios had range. The new 2.4GHz ones don’t. I still have my old JR radio on 50.8MHz (6m ham) with a 56" stainless steel whip on it and that radio has a range of 10 miles, no problem. But it’s pushing less than 10Khz of bandwidth too.

After trying and flying several different things, frankly, I didn’t find the ArduPilot telemetry to be all that useful on the RC screen. It just duplicates what’s already on the ground station and the ground station has a nicer display of the data, nor can upload a flight plan to the helicopter anyway with the RC - need the ground station for that.

The Lua script that comes with the Gas Suite is not all that great. So I wrote my own with big easy to see numbers and a less crowded screen, just with the mechanical aspects of the helicopter and RC link status on the radio screen.

I am sure that custom GasSuite will be very helpful with your Gas-Helis during missions!!.
Remember few weeks ago when my 600 electric Heli disappeared and went up to 2400 feet above me I would have loved to have the Yaapu script on my Taranis at that time.
My laptop ground station screen is useless outside so it stays in my Van. No time to stick your head into the van to find out what is wrong with the Heli. He was going up 5.5m per sec. Later after I got the Heli back down safely I checked the logs and there were warnings I could read on the laptop screen which would be now on my TX with sound. I would reacted a lot faster and the Heli would have been stopped early to go up that high.
But I would not have that very impressive video from the onboard camera today!

Integrating the re-purposed ArduPilot SPort sensors with other FrSky sensors has proved problematic. ArduPilot “stole” all the important ones like Fuel and re-purposed it for battery. Which does no good in my fueler helicopters because the battery is charged by a generator and I want to know actual fuel.

And the Tmp1 and Tmp2 sensors were re-purposed for flight modes and GPS. When I want those for engine CHT/EGT and OAT.

I’ve decided the ArduPilot SPort code needs to be re-done to make it actually usable. With an AirLink you can change the ID on any FrSky sensor so you can run duplicate sensors, etc… So why didn’t ArduPilot use sensor ID’s that aren’t being used by the regular suite of FrSky telemetry sensors?

Hi Chris,
I did the very same mistake in my script, I exposed to OpenTX the sensor Ids used by the repurposed frsky telemetry library, I’ll fix it in the next release.
I’ll drop Tmp1 and Tmp2 for they are noy used anymore and I will move all IDs to the last instance of the proper type.
So for fuel I’ll use sensor 0x60F, leaving 15 instances for regular frsky sensors, the same for all other sensors.

Yes, I agree. There may have been a misunderstanding that only specific sensor ID’s can be used, so to make the SPort code work the ID’s used by FrSky sensors were re-purposed. But that’s not the case.

So if I rework the ArduPilot code to use unique sensor ID’s that aren’t used by FrSky sensors then folks can integrate any FrSky sensor with ArduPilot FrSky telemetry and there is no ID conflict. That will fix folks having to change a FrSky sensor with an AirLink to use those sensors with ArduPilot.

So I can make a script with maybe two pages for X9D - one page with mechanical telemetry from the aircraft, and another with navigation telemetry from ArduPilot. So the screen will have large easy to read fonts, but split it up by being able to switch screen with the Page key. That’s how the Gas Suite Lua script that I downloaded from FrSky was done - it has three pages.