FrSkyRC / ETHOS-Feedback-Community

Feedback & suggestions are welcomed here for ETHOS by FrSky

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

having trouble with calculated screen

williajgr opened this issue · comments

I have a screen where i add a value to 0. value is 99PSI. this is the output of Frsky pressure sensor. it gives me an answer of 681232 psi.
IMG_2523

Ya, I also found that there was some problems with how the precision of a value is handled in the calculated sensors. I ask for no decimal places and the calculated sensor just moves the decimal point instead of dropping the non-integer portion. 6.12 volts becomes 612 volts when the decimal places is set to zero for example.

Above is a screen shot where I am subtracting the Maximum altitude provided by the GR6 receiver and a calculated maximum altitude from the maximum of GR6 provided altitude via actions, that has been scaled to centimeters to remove the decimal places and get this calculation to a ~zero result. Anyway, I don't think that you are supposed to be able to subtract 78 from 7800 and get 0.3. The correct altitude here is the 78.3 meters and the difference should be zero.

I am not sure that I understand what you are trying to do?

I am trying to create a max altitude value that does not reset when the altitude sensor is reset, so I can get a maximum value per launch, per flight timer duration, and per day. It has to withstand altimeter resets and radio shut downs. I am also trying to mitigate the sensor starting at some random value when the receiver is initially powered up. This one pictured starts up at about 78 meters and then drifts for a while while it warms up, so a check for the reset so that it kills only the weird value and not one that want to keep (,but that is a lump of a few issues and features that I haven't had time to separate in my brain).

So the discovery is that if a calculations are made using the altimeter they need to be scaled to match each other's precision, and the output precision has to match the input precision. It can't handle 10 + 1.0. If the decimals field of the calculated sensor is set to 0 this is 20. If it is set to 1 this is 2.0.

I think our OP here is seeing the really wonky value because they have the decimals field set to 0, and the output is just the raw sensor value from the ADC.

In calculated sensors, I would like to see these values making more general sense. In the sensor I have pictured I would like to see the Value field reflect the result of the calculation fields. To me the sensor I have pictured should be 7830 - 78.3 = 7751.7 I'm not even sure where the 0.3 is coming from, some raw data calculation maybe. I would like to see the Decimals field affect only how much precision is given in the result, and any rounding to happen only to the final output value.

In native sensors the Decimal field affects the output value correctly.

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days.