Telemetry and r820

[Greebo]

It's been about 2 years since I looked at what the current version of er9x was for my 9x, so what a shock it was when I finally loaded up r820 the other day.
You guys have been busy! Mike, I love the new menu system.

I have noticed an issue with the telemetry display. I had a search around the forums, but couldn't find a reference to my issue, happy to be pointed at the other posts if its already been reported.

I'm running r820 of er9x-frsky.hex (m64, FrSky telemetry version).

I'm receiving telemetry information via a FrSky D4R-II, sent from CleanFlight 1.12 via serial.
the Baro reading appears fine in the cleanflight GUI, but in the telemetry display on my 9x, I get negative numbers for anything below 1.0m.
I have this from 2 different quads with different flight controllers (both running cleanflight v1.12 though)

So if the quad is sitting at -1.4m and I lift it up, the numbers change thus: -1.3 -1.2 -1.1 ... -0.2, -0.1, 0, -0.1, -0.2, ... -0.9, 1.0, 1.1.
I can see in the Cleanflight GUI that it reports those heights correctly during the same test.

Is there any way I can tell from the radio itself what the raw data is, coming from the D4R-II?

On another niggle I have, the decimal points in the telemetry screen also seem to be poorly positioned - see attached image

[jhsa]

What if you hit MENU SHORT while on the telemetry main screens and reset the altitude? That should fix the problem?

João

[Greebo]

What if you hit MENU SHORT while on the telemetry main screens and reset the altitude? That should fix the problem?

No, I don't think so (although I will try it when I get home).

My point is that a real value of altitude (as seen in the GUI for the flight controller) of 0.9m (positive 0.9m) (for example) shows up on the telemetry screen as -0.9m (negative 0.9m). A real value of -0.9m also shows up as -0.9m.

So -0.9m showing on the telemetry screen could be either -0.9m or +0.9m - there's 1.8m of difference there, which on my quads is easily the difference between hovering above the ground and ploughing into it.

So its only values between positive 0.1 and 0.9 that show up incorrectly as negative values.

[MikeB]

I think I can see the problem in the code.
The FrSky hub protocol has a fundamental flaw with things like altitude. The value is sent in two parts, the whole number (before the decimal point) then the decimal part as a separate value. So, 7.9 is sent as +7, then +9, -10.3 is sent as -10 then +3 (yes +). The flaw is that values between 0 and -1 cannot be represented as these would need the whole number part to be -0.
With the code trying to sort this out, I have a test on the whole number part being greater than 0. This test should be greater than or equal to 0.

Mike.

[Greebo]

Ok, wow. So how does -0.5 come through? Or are you saying that it doesn't?
What were they smoking when they came up with that protocol... lol

I assume then, that changing it to >= 0 will mean values between 0 and -1.0 will not show the negative either (which I guess is preferred)

[Kilrah]

I remember having to fix the same issue in OpenTx a year or 2 ago... and yes that protocol is really stupid.

[jhsa]

I don't remember someone calling it stupid at the time it came out
It's quite old now, and it was Frsky's attempt at telemetry. It has served me very well and it still continues to do so..
I find the D equipment more reliable than the new one. Never had a problem with it, and can probably count on my fingers on one hand the times I have read about problems with this equipment.
I can't say the same about the X series unfortunately.
So yeah, I still prefer the "Stupid" protocol

João

[MikeB]

Most of the values sent like this are positive (like battery voltage), so it isn't a problem.
The altitude value is sent as an absolute value, based on air pressure, so the value you get, when at the same actual height, changes from day to day as the air pressure changes. The Tx notes your starting value and uses that as your 0.0 value.
You are correct that values between 0 and -1 can't be sent.

Mike.

[Kilrah]

You are correct that values between 0 and -1 can't be sent.

It's been a long time but I believe they can, the sign is also sent in the "ap" part. If I remember well our problem was that in this case some stuff was logged as things looking like "0.-13"

[Greebo]

Just poked around in the Cleanflight source...

Code: Select all

static void sendBaro(void)
{
    sendDataHead(ID_ALTITUDE_BP);
    serialize16(BaroAlt / 100);
    sendDataHead(ID_ALTITUDE_AP);
    serialize16(ABS(BaroAlt % 100));
}

From the short time I've been playing with these FC's it appears that Cleanflight sets the Alt to 0 when the board is powered up (I'll poke around in the code a bit more to see if I can find that), so based on that and the function above, its never going to send anything between -0.99m and -0.01m inclusive.

I'll just make sure I power it up on the ground, not on a bench, and I'll probably never see negative Altitudes in practice.