Wouldn’t the easiest be adding a adc temp sensor on ArduPilot ?
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
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
#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?
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.
you made me curious
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!
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!
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?
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
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
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.