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!
@LuisVale we came back last night to beat the heat in Muncie and the rain here. I saw everything I needed to see on the scale flight line. We didn’t even check out the 3D flightline.
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.
Chris, was the gas suite LUA script running when you had passthrough telemetry packets drops?
file Gassuit_forX9_v1_0.lua at line 162 function telemetryRead()
local function telemetryRead(fieldx)
return sportTelemetryPush(0x1b, 0x30, 0x0d10, fieldx)
end
this function queues on OpenTX a response to a 0x1b sensor ID polling and is periodically called by background() via refreshNext().
This could lead to unexpected results for ardupilot is responding to 0x1b polling as well.
betaflight/cleanflight would have the same problem btw.
If this turns out to be true we’ll have to change the sensor ID used in ardupilot, i’d say nothing difficult but it would also be a chance to fix a couple things.
What do thing @LuisVale does it make sense to you?
Edit: the gas suite lua script also periodically calls sportTelemetryPop() consuming telemetry packets that could very well have been sent by ardupilot
I finally got the repurposed sensors for SPort to play nice with the regular FrSky sensors. With my turbine heli at flight idle on the ground everything works now.
