Mavlink parameter sync and general congestion review

[dagar]

Mavlink parameter sync ignores the mavlink instance data rate and current rate multiplier (throttling). It does check the tx buffer, but this isn't sufficient. As a result some setups (eg SiK radios without flow control) can be unusable at times failing to complete the initial parameter sync. #10394 (comment)

Ideas to explore

• parameter sync respect data rate and rate multiplier
  • move back to TX thread? @bkueng
• pause all other telemetry (except HEARTBEAT) during sync?
• rate multiplier consider additive increase, multiplicative decrease
  • mavlink data rate start at minimum and increase
• rate multiplier treat RADIO_STATUS rxerrors as critical and drop the rate substantially
• mavlink track and send drop rate for rate throttling (MAVLink Status mavlink/qgroundcontrol#6847)
  • add new mavlink status message to send drop rate (@dogmaphobic)
  • would also help on bad UDP connections
• QGC request data streams that are actually required.
  • for example default to Mavlink MINIMAL (https://github.com/PX4/Firmware/blob/master/src/modules/mavlink/mavlink_main.cpp#L1882) and only add new streams or increase rates as needed.
  • Mavlink NORMAL is roughly 100x more data than MINIMAL and just as functional for the vast majority of usage
• only send HEARTBEAT until first contact?

Parameter sync is the best target to improve, but all of this should apply to mission sync or FTP as well.

[LorenzMeier]

@dagar FYI: Parameters and mission items are on purpose taking all bandwidth they can (but are still throttled) to speed up these transfers when they happen.

[dagar]

The problem isn't that they're hogging all of mavlink, it's that they're completely ignoring both the initial data rate and scaled (throttled) data rate of the instance.

https://github.com/PX4/Firmware/blob/master/src/modules/mavlink/mavlink_parameters.cpp#L311-L328

You can see this in some radio setups without flow control with newer firmware (logging enabled from boot) where I've added mavlink stats to each telemetry_status message. There also seems to be a secondary problem with older SiK firmware RADIO_STATUS and Mavlink v1/v2, but I haven't nailed down the details. The end result is that there's no RADIO_STATUS message received by the mavlink module, and the user is completely unaware.

I'll post a log.

[julianoes]

It's also ignored here, I think:
https://github.com/PX4/Firmware/blob/cfad556a1609048029e66f540c7e87e87f2d8905/src/modules/mavlink/mavlink_log_handler.cpp#L145-L148

[dagar]

@julianoes yes, anything that transmits off of the receive thread is ignoring the data rate settings and scaling mechanism (partially). See #7226

• parameters
• ftp
• mission
• log

#7223

[brad112358]

I've submitted a pull request which should fix the parameter download portion of this issue. #16910