Custom FrSky telemetry for Helicopter

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.

1 Like

@ChrisOlson You were supposed to be having fun at IRCHA :slight_smile:

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!

I use FPV for seat of the pants flying.

@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.

hot @ChrisOlson ?..nah…

so, you didn’t go with your Gas E700 to “sell” ArduPilot as the next hottest thing around on the 3D line ?


No - didn’t even take a heli along. I went to check out turbine engines and pick up a PHT3 JetCat.

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.

What follows are the IDs as understood b OpenTX

OpenTx DATA IDs from /radio/src/telemetry/frsky.h

// FrSky new DATA IDs (2 bytes)
#define ALT_FIRST_ID              0x0100
#define ALT_LAST_ID               0x010f
#define VARIO_FIRST_ID            0x0110
#define VARIO_LAST_ID             0x011f
#define CURR_FIRST_ID             0x0200
#define CURR_LAST_ID              0x020f
#define VFAS_FIRST_ID             0x0210
#define VFAS_LAST_ID              0x021f
#define CELLS_FIRST_ID            0x0300
#define CELLS_LAST_ID             0x030f
#define T1_FIRST_ID               0x0400
#define T1_LAST_ID                0x040f
#define T2_FIRST_ID               0x0410
#define T2_LAST_ID                0x041f
#define RPM_FIRST_ID              0x0500
#define RPM_LAST_ID               0x050f
#define FUEL_FIRST_ID             0x0600
#define FUEL_LAST_ID              0x060f
#define ACCX_FIRST_ID             0x0700
#define ACCX_LAST_ID              0x070f
#define ACCY_FIRST_ID             0x0710
#define ACCY_LAST_ID              0x071f
#define ACCZ_FIRST_ID             0x0720
#define ACCZ_LAST_ID              0x072f
#define GPS_LONG_LATI_FIRST_ID    0x0800
#define GPS_LONG_LATI_LAST_ID     0x080f
#define GPS_ALT_FIRST_ID          0x0820
#define GPS_ALT_LAST_ID           0x082f
#define GPS_SPEED_FIRST_ID        0x0830
#define GPS_SPEED_LAST_ID         0x083f
#define GPS_COURS_FIRST_ID        0x0840
#define GPS_COURS_LAST_ID         0x084f
#define GPS_TIME_DATE_FIRST_ID    0x0850
#define GPS_TIME_DATE_LAST_ID     0x085f
#define A3_FIRST_ID               0x0900
#define A3_LAST_ID                0x090f
#define A4_FIRST_ID               0x0910
#define A4_LAST_ID                0x091f
#define AIR_SPEED_FIRST_ID        0x0a00
#define AIR_SPEED_LAST_ID         0x0a0f
#define RBOX_BATT1_FIRST_ID       0x0b00
#define RBOX_BATT1_LAST_ID        0x0b0f
#define RBOX_BATT2_FIRST_ID       0x0b10
#define RBOX_BATT2_LAST_ID        0x0b1f
#define RBOX_STATE_FIRST_ID       0x0b20
#define RBOX_STATE_LAST_ID        0x0b2f
#define RBOX_CNSP_FIRST_ID        0x0b30
#define RBOX_CNSP_LAST_ID         0x0b3f
#define SD1_FIRST_ID              0x0b40
#define SD1_LAST_ID               0x0b4f
#define ESC_POWER_FIRST_ID        0x0b50
#define ESC_POWER_LAST_ID         0x0b5f
#define ESC_RPM_CONS_FIRST_ID     0x0b60
#define ESC_RPM_CONS_LAST_ID      0x0b6f
#define ESC_TEMPERATURE_LAST_ID   0x0b7f
#define X8R_FIRST_ID              0x0c20
#define X8R_LAST_ID               0x0c2f
#define S6R_FIRST_ID              0x0c30
#define S6R_LAST_ID               0x0c3f
#define GASSUIT_TEMP_FIRST_ID     0x0d00
#define GASSUIT_TEMP_LAST_ID      0x0d0f
#define GASSUIT_SPEED_FIRST_ID    0x0d10
#define GASSUIT_SPEED_LAST_ID     0x0d1f
#define GASSUIT_FUEL_FIRST_ID     0x0d20
#define GASSUIT_FUEL_LAST_ID      0x0d2f
#define DIY_FIRST_ID              0x5000
#define DIY_LAST_ID               0x52ff
#define DIY_STREAM_FIRST_ID       0x5000
#define DIY_STREAM_LAST_ID        0x50ff
#define FACT_TEST_ID              0xf000
#define RSSI_ID                   0xf101
#define ADC1_ID                   0xf102
#define ADC2_ID                   0xf103
#define SP2UART_A_ID              0xfd00
#define SP2UART_B_ID              0xfd01
#define BATT_ID                   0xf104
#define RAS_ID                    0xf105
#define XJT_VERSION_ID            0xf106
#define FUEL_QTY_FIRST_ID         0x0a10
#define FUEL_QTY_LAST_ID          0x0a1f

it was a bad design choice from the beginning IMO

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)

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

No, you can’t run any other FrSky sensors with the passthru. It doesn’t work.

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.


1 Like