V 2.8.3 Flysky FS-CAT01 altitude sensor

[1RicMcK]

Is there an existing issue for this problem?

• I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

I updatged from 2.8.1 to 2.8.3 and the FlySky Cat01 altitude sensors do not read correctly. Initally they say + or - 2-3K meters. Will offset if units are 0-. Data reads max altitude of over 20Km during any given flight and does not give any intermidate readings. 2.8.1 works fine.

Expected Behavior

Should be able to offset ot "zero" and should transmit realtime data 0-1,000Ft, and properly record max altitude. Works fine with V2.8.1

Steps To Reproduce

4

Version

Other (Please specify below)

Transmitter

Radiomaster TX16S / TX16SMK2

Operating System (OS)

No response

OS Version

2.8.3

Anything else?

No response

[richardclli]

The calculation method of alt from pressure is changed by Flysky to align with their own implementation.

edgetx/radio/src/telemetry/flysky_ibus.cpp

Lines 559 to 617 in 3692718

	const int16_t tAltitude[225]=
	{ // In half meter unit
	20558, 20357, 20158, 19962, 19768, 19576, 19387, 19200, 19015, 18831, 18650, 18471, 18294, 18119, 17946, 17774,
	17604, 17436, 17269, 17105, 16941, 16780, 16619, 16461, 16304, 16148, 15993, 15841, 15689, 15539, 15390, 15242,
	15096, 14950, 14806, 14664, 14522, 14381, 14242, 14104, 13966, 13830, 13695, 13561, 13428, 13296, 13165, 13035,
	12906, 12777, 12650, 12524, 12398, 12273, 12150, 12027, 11904, 11783, 11663, 11543, 11424, 11306, 11189, 11072,
	10956, 10841, 10726, 10613, 10500, 10387, 10276, 10165, 10054, 9945, 9836, 9727, 9620, 9512, 9406, 9300,
	9195, 9090, 8986, 8882, 8779, 8677, 8575, 8474, 8373, 8273, 8173, 8074, 7975, 7877, 7779, 7682,
	7585, 7489, 7394, 7298, 7204, 7109, 7015, 6922, 6829, 6737, 6645, 6553, 6462, 6371, 6281, 6191,
	6102, 6012, 5924, 5836, 5748, 5660, 5573, 5487, 5400, 5314, 5229, 5144, 5059, 4974, 4890, 4807,
	4723, 4640, 4557, 4475, 4393, 4312, 4230, 4149, 4069, 3988, 3908, 3829, 3749, 3670, 3591, 3513,
	3435, 3357, 3280, 3202, 3125, 3049, 2972, 2896, 2821, 2745, 2670, 2595, 2520, 2446, 2372, 2298,
	2224, 2151, 2078, 2005, 1933, 1861, 1789, 1717, 1645, 1574, 1503, 1432, 1362, 1292, 1222, 1152,
	1082, 1013, 944, 875, 806, 738, 670, 602, 534, 467, 399, 332, 265, 199, 132, 66,
	0, -66, -131, -197, -262, -327, -392, -456, -521, -585, -649, -713, -776, -840, -903, -966,
	-1029,-1091, -1154, -1216, -1278, -1340, -1402, -1463, -1525, -1586, -1647, -1708, -1769, -1829, -1889, -1950,
	-2010
	};
	/*==================================================================================================
	Name:
	Function:
	Input:
	Output:
	==================================================================================================*/
	int32_t getALT(uint32_t Pressure)//CalculateAltitude( uint32_t Pressure, uint32_t SeaLevelPressure )
	{
	uint32_t Index;
	int32_t Altitude1;
	int32_t Altitude2;
	uint32_t Decimal;
	uint64_t Ratio;
	uint32_t SeaLevelPressure=101320;
	Pressure = Pressure & PRESSURE_MASK;
	Ratio = ( ( ( unsigned long long ) Pressure << 16 ) + ( SeaLevelPressure / 2 ) ) / SeaLevelPressure;
	if( Ratio < ( ( 1 << 16 ) * 250 / 1000 ) )// 0.250 inclusive
	{
	Ratio = ( 1 << 16 ) * 250 / 1000;
	}
	else if( Ratio > ( 1 << 16 ) * 1125 / 1000 - 1 ) // 1.125 non-inclusive
	{
	Ratio = ( 1 << 16 ) * 1125 / 1000 - 1;
	}
	Ratio -= ( 1 << 16 ) * 250 / 1000; // from 0.000 (inclusive) to 0.875 (non-inclusive)
	Index = Ratio >> 8;
	Decimal = Ratio & ( ( 1 << 8 ) - 1 );
	Altitude1 = tAltitude[Index];
	Altitude2 = Altitude1 - tAltitude[Index + 1];
	Altitude1 = Altitude1 - ( Altitude2 * Decimal + ( 1 << 7 ) ) / ( 1 << 8 );
	Altitude1 *= 100;
	if( Altitude1 >= 0 )
	{
	return( ( Altitude1 + 1 ) / 2 );
	}
	else
	{
	return( ( Altitude1 - 1 ) / 2 );
	}
	}

And they have tested and verified the change.

[richardclli]

@Xy2019 Do you have any comments?

[1RicMcK]

Thank you. No, I don't have any comments as I'm not a programmer. I just wanted to report a bug I found. I will wait until 2.9 comes out to update my FW. Thank You Rick McKenney "Change the dream and our actions will follow it" Lynne Twist

…

On Thu, May 11, 2023 at 6:29 PM richardclli ***@***.***> wrote: @Xy2019 <https://github.com/Xy2019> Do you have any comments? — Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7YTNTD7I2OLLLAUXEQASXTXFWHA7ANCNFSM6AAAAAAX6LA6GM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[John-4565]

I also noticed the same weird altitude reporting from my Flysky FS-CAT01 when upgrading EdgeTX from 2.8.2 to 2.8.3. The upgrade also messed up a number of other sensors such as Tmp2 and Pres. I downgraded my Radiomaster TX16S back to EdgeTX 2.8.2 and all was good again.

[1RicMcK]

John, EtAl. I also down graded to 2.8.1,but have not tested it again. I assume that everything will be OK. Rick McKenney (via phone)

…

On Sat, May 13, 2023, 9:16 PM John-4565 ***@***.***> wrote: I also noticed the same weird altitude reporting from my Flysky FS-CAT01 when upgrading EdgeTX from 2.8.2 to 2.8.3. The upgrade also messed up a number of other sensors such as Tmp2 and Pres. I downgraded my Radiomaster TX16S back to EdgeTX 2.8.2 and all was good again. — Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7YTNTFGWJVIRPOKUMI2ZSTXGBMA5ANCNFSM6AAAAAAX6LA6GM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[richardclli]

Please specify the chain of equipments that you use.

TX16S -> MPM? -> What receiver -> CAT01

[John-4565]

Please specify the chain of equipments that you use.

TX16S -> MPM? -> What receiver -> CAT01

The equipment I am using is a Radiomaster TX16S -> Internal MPM on F/W 1.3.3.20 TAER -> Rx is a FlySky FS-iA6B -> Altitude sensor is a FlySky FS-CAT01. Let me know if you need more detail.

[1RicMcK]

I'm Running Radiomaster TX16S 4 in 1. \ mm-stm-serial-aetr-v1.3.3.20. \ RX FlySky FS-iA6B. \ Altitude sensor is a FlySky FS-CAT01.

[CharlesGauci]

Even I had to downgrade my Flysky NV14 to 2.8.2 because of the FS-CAT01 issue. I also decided to shelf my Flysky EL18 for the second time because neither the temperature, nor the voltage and not even the altitude sensors are working properly.
I mentioned this problem in PR number #3467 which is related to PR number #3386.

[stefanpeter218]

I've observed the same behaviour with latest edgetx and the cat01 altitude Sensor. Verified the bug with different receivers (FS-iA10b, FS-iA6b) and transmitters (Radiomaster TX16S and Zorro).
Is it possible to switch back to the calculation used in the previous release?

[gagarinlg]

As was stated before, that change came directly from Flysky. If it does not work here, for whatever reason, we have to roll back that change.

[stefanpeter218]

Dear gagarinlg, this was my thought. The calculation, e.g. in 2.7, seems to differ much from the 2.8.4 version (I couldn't find the 2.8.3 version .cpp).
Maybe flysky confused with afhds2a and afhds3 sensors?

[gagarinlg]

I have no idea, I did not went into the rabbit hole of EdgeTX telemetry, yet.

[richardclli]

Dear gagarinlg, this was my thought. The calculation, e.g. in 2.7, seems to differ much from the 2.8.4 version (I couldn't find the 2.8.3 version .cpp). Maybe flysky confused with afhds2a and afhds3 sensors?

I think The current Flysky implementation aligns the reading of this sensor with their stock radio with their stock firmware. As for your information, alt. is not detectable directly by sensors, it is calculated using pressure. Flysky stock firmware uses the same table lookup to do the alt. transformation and the definition is the alt above sea level.

For Flysky sensors, there are quite a lot of historical problems in the code. Third-party sensors, and flight control make use of the same ibus telemetry. When Flysky try to align the representation between their own products and EdgeTX, they discovered there a list of sensors that is never produced by them. I asked them not to touch that part and only fix their sensors and align with their own products.

I have been following these for months already but still cannot managed to see how to define what is right and what is wrong. Readings different from previous version not necessary a bug, but maybe a fix to a bug that you already used to it, it is just hard to tell, right now, need to gather more information and track down the history.

[RNIR]

Just to confirm, with 2.8.3 I also found altitude readings for flysky unusable (garbage values, not just slightly different than before).
Already ordered new Sensor, because I thought it got damaged, but now found the same behaviour with a different model.
I am using TX16s, 4in1 internal module, FSiA6b RX, FS-CAT01 sensor.

[richardclli]

I just verified for the FS-CAT01 sensor connected to AFHDS3 receivers, the reading are the same from PL18 with stock firmware and EL18 with EdgeTX. Will try to verify the reading from AFHDS2 receivers via NV14 and MPM afterwards.