search

mavlink / qgroundcontrol

Cross-platform ground control station for drones (Android, iOS, Mac OS, Linux, Windows)
http://qgroundcontrol.io
3.3k stars 3.62k forks source link

QGC on IOS version 3.2 from App store reports RXRSSI incorrectly. #7013

Closed Noircogi closed 5 years ago

Noircogi commented 5 years ago

The reported value appears to be a the raw 8-bit number with a percentage. Ie: a true RSSI of 99% shows up as 254%. Lower values appear as 248% etc.

DonLakeFlyer commented 5 years ago

@dogmaphobic It sounds like whatever message this comes across on is sent differently from PX4 to ArduPilot. If so, this needs to be firmware plugin-ized for translation.

dogmaphobic commented 5 years ago

How is it a "standard" when people deviate from it? Isn't the whole point of MAVLink to be a standard so you don't have to worry about stuff like this? I know, just a rhetorical question, but by being lenient and accommodating will only lead to completely inoperable systems.

DonLakeFlyer commented 5 years ago

Welcome to the world of mavlink. What has happened a number of times of times is that the "standard" has been "updated" to specify things which were not originally specified. Prior to that someone implemented a message as they thought made sense at least to them. Then somewhere along the way the "standard" documentation was changed to be more specific and match the way someone else was doing it. Which was not the way the other implementer implemented the thing. And then the first implementer says the hell with that all my stuff is working just fine I'm not going to change. Or they might not even know the docs were changed such that their implementation wasn't to spec. I have no idea if that's the history of this specific mavlink message but there are a number of cases exactly like this one in QGC for differences between PX4 and ArduPilot.

mrpollo commented 5 years ago

Great discussion on mavlink implementations, we should discuss further what role should QGC have, and define a stern position that allows QGC to have a sustainable development experience while remaining a neutral implementation of the mavlink spec.

@DonLakeFlyer Can you please show me where I can find the mavlink spec for this message?

@Noircogi What autopilot are you running? sounds like we are running into an issue with an incompatible implementation of a spec, thanks for the report and sorry for the inconvenience, we'll try to get this fixed as soon as we can coordinate all the interested parties and come up with a fix.

hamishwillee commented 5 years ago

Welcome to the world of mavlink. What has happened a number of times of times is that the "standard" has been "updated" to specify things which were not originally specified.

Nail on the head. For new messages I think we're getting better - more consistent review and using the fields provided to ensure units are clear etc. For older stuff we're going to have a problem until we manage to sort out our versioning - there are discussion on that ongoing. No resolution yet.

@DonLakeFlyer Can you please show me where I can find the mavlink spec for this message?

It will probably be one of: RC_CHANNELS RADIO_STATUS RC_CHANNELS_SCALED RC_CHANNELS_RAW

Don, on that note, what are the units/ranges for RC_CHANNELS? They are undocumented.

DonLakeFlyer commented 5 years ago

You'd have the ask @dogmaphobic where the RSSI comes from. The only units for RC_CHANNELS that I know about and use are for radio cal and are PWM values.

DonLakeFlyer commented 5 years ago

For new messages I think we're getting better - more consistent review and using the fields provided to ensure units are clear etc.

Yup. This is all ancient history.

Noircogi commented 5 years ago

The RXRSSI value is in the RC_CHANNELS and RC_CHANNELS_RAW packets. All of the versions of Ardupilot I've ever used had the range of 0-255 for that value. Currently, I have various flavors of pixhawks and a Matek F405-Wing running Arduplane and they all use the same scaling. The oldest version I have installed is 3.5.3, but I believe APM has always used that range for RXRSSI. Bear in mind that minimOSD, MavlinktoFrsky and many other projects also expect that range. QGC is the first thing I've seen which used a different range, but I come from the APM firmware side, not PX4.

hamishwillee commented 5 years ago

@Noircogi That's a bit ugly. So ArduPilot uses the full 1-255 while the "current" spec says values: [0-100], 255: invalid/unknown. What does ArduPilot use for invalid - NaN? Specifying in fractions of 255 feels pretty ugly.

@DonLakeFlyer Do we know of any other implementers other than those @Noircogi mentioned?

DonLakeFlyer commented 5 years ago

Do we know of any other implementers other than those @Noircogi mentioned?

I don't know much of anything about RSSI

dogmaphobic commented 5 years ago

What does ArduPilot use for invalid - NaN?

You can't fit a NaN on an uint8_t.

There is even weirder, undocumented RSSI value definitions. Look at: https://mavlink.io/en/messages/common.html#RADIO_STATUS

And here is the code handling it: https://github.com/mavlink/qgroundcontrol/blob/master/src/Vehicle/Vehicle.cc#L1654-L1671

RSSI is expressed in (negative) dBm (decibels relative to a milliwatt), where <= -120dBm is basically no signal and >= -50dBm is 100%.

In addition to the actual value, you need a way to tell you simply don't have it. On a 0 - 255 scale, do you consider 0 as no signal or no RSSI availability?

hamishwillee commented 5 years ago

@Noircogi As above, "What does ArduPilot use for invalid - NaN?"

@dogmaphobic That is for Sik radio. Anyone else know of other implementations of this message?

Yuk. I don't think we'll be able to rationalise this until we can version things better. I posted https://github.com/mavlink/mavlink/issues/1027 to discuss this particular case.

Noircogi commented 5 years ago

Generally, I believe 0 is considered to be "no RX RSSI present" in APM.

Noircogi commented 5 years ago

Here's an old Mavlink spec from the MinimOSD-Extra project which shows the 0-255 range for rssi in both packets. https://github.com/diydrones/MinimOSD-Extra/blob/master/libraries/mavlink/message_definitions/common.xml

hamishwillee commented 5 years ago

Thanks @Noircogi. I've added that info to https://github.com/mavlink/mavlink/issues/1027

DonLakeFlyer commented 5 years ago

@dogmaphobic Can you either FirmwarePlugin-ize this conversion or you can futz with the message as it comes into ArduPilotFirmwarePlugin using adjustIncomingMavlinkMessage to make it look the same by the time it gets to Vehicle.

Noircogi commented 5 years ago

I built with this change for IOS and tested against Arduplane 3.10.0-dev. RSSI now reports correctly.

Noircogi commented 5 years ago

Did this get lost in the #7017 revert?

DonLakeFlyer commented 5 years ago

Nope