Servers by jDrones

Custom FrSky telemetry for Helicopter


(Chris Olson) #12

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.


(Luís Vale Gonçalves) #13

Wouldn’t the easiest be adding a adc temp sensor on ArduPilot ?


(Chris Olson) #14

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” :grinning:


(Luís Vale Gonçalves) #15

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


(Chris Olson) #16

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.


(Alex Apostoli) #17

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

#define SENSOR_ID_VARIO             0x00 // Sensor ID  0
#define SENSOR_ID_FAS               0x22 // Sensor ID  2
#define SENSOR_ID_GPS               0x83 // Sensor ID  3
#define SENSOR_ID_SP2UR             0xC6 // Sensor ID  6

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?


(Chris Olson) #18

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.


(Alex Apostoli) #19

Hi Chris,
you made me curious :slight_smile:

I recompiled arducopter to use 3 sensors instead of 1 on the passthru library, it works as OpenTX does not check the sensor ID

then I checked with a logic probe what gets sent

the rx polls in trains of 3 sensors in a row followed by the unused sensors one per train
In this configuration there’s a 25% slot loss (1 out of 4)

I then enabled SERIAL_PROTOCOL = 4 to check what happens in the other mode
this is the capture


here sensors are polled in trains of 4 in a row followed by the unused sensors one per train
In this configuration there’s a 20% slot loss (1 out of 5)

I reverted to standard passthru with 1 sensor


and as expected only 1 slot every other is used with a bandwidth loss of 50%

in theory the 1 sensor approach should be the safest with the least saturated link!

I have no explanation for what you observe, perhaps in your tests OpenTX is caching sensors even in case of packet loss

maybe Luis has an explanation!

cheers,
Alex


(Chris Olson) #20

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.


(Chris Olson) #21

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.


(Luís Vale Gonçalves) #22

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


(FRED GOEDDERT) #23

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!


(Chris Olson) #24

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.


(Luís Vale Gonçalves) #25

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 ?

:rofl::sunglasses:


(Chris Olson) #26

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


(Chris Olson) #27

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?


(Alex Apostoli) #28

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_FIRST_ID  0x0b70
#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


(Chris Olson) #29

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.


(Alex Apostoli) #30

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


(Chris Olson) #31

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