Have you checked the latest release for fixes?
Description
If QGC connects to a flight stack and downloads standard modes, it doesn't know the initial sequence number. If it subsequently gets AVAILABLE_MODES_MONITOR it can set this number, but is forced to redownload the available modes because it might have an old set (subsequently it is fine).
To fix this, mavlink added the same sequence number to AVAILABLE_MODES in mavlink/mavlink#2557 and this is supported in PX4 main from PX4/PX4-Autopilot#28226
After updating to latest mavlink/mavlink, a GCS can read AVAILABLE_MODES.seq on first upload, and provided it is non-zero store the seq as the current sequence number. If AVAILABLE_MODES_MONITOR.seq is subsequently received the value is now known, so there is no need to re-download the modes unless the value of that seq is different.
If the value in AVAILABLE_MODES.seq is zero it should be ignored/NOT overwrite the store sequence, because this might just mean that the feature is not supported by the sender - as is currently the case for ardupilot.
Implementers might wonder if there is still and edge case where AVAILABLE_MODES.seq=0, which we can't trust, and then you get a AVAILABLE_MODES_MONITOR.seq=1.
This is not an issue because 0 is the initial value, and if the new seq is supported you will get a value if it is >1. Either way AVAILABLE_MODES_MONITOR.seq=1 means that you have to redownload if you got zero.
If the new seq is not supported you're no worse off. You can assume the initial value is 0, and any non-zero value will kick off a new download.
Platform
Windows
Flight Stack
PX4
System Information
PX4 main (version after v1.18). OS and other versions irrelevant. Latest QGC.
Log Files and Screenshots
No response
Have you checked the latest release for fixes?
Description
If QGC connects to a flight stack and downloads standard modes, it doesn't know the initial sequence number. If it subsequently gets AVAILABLE_MODES_MONITOR it can set this number, but is forced to redownload the available modes because it might have an old set (subsequently it is fine).
To fix this, mavlink added the same sequence number to AVAILABLE_MODES in mavlink/mavlink#2557 and this is supported in PX4 main from PX4/PX4-Autopilot#28226
After updating to latest mavlink/mavlink, a GCS can read
AVAILABLE_MODES.seqon first upload, and provided it is non-zero store theseqas the current sequence number. IfAVAILABLE_MODES_MONITOR.seqis subsequently received the value is now known, so there is no need to re-download the modes unless the value of that seq is different.If the value in
AVAILABLE_MODES.seqis zero it should be ignored/NOT overwrite the store sequence, because this might just mean that the feature is not supported by the sender - as is currently the case for ardupilot.Implementers might wonder if there is still and edge case where
AVAILABLE_MODES.seq=0, which we can't trust, and then you get aAVAILABLE_MODES_MONITOR.seq=1.This is not an issue because 0 is the initial value, and if the new seq is supported you will get a value if it is >1. Either way
AVAILABLE_MODES_MONITOR.seq=1means that you have to redownload if you got zero.If the new
seqis not supported you're no worse off. You can assume the initial value is 0, and any non-zero value will kick off a new download.Platform
Windows
Flight Stack
PX4
System Information
PX4 main (version after v1.18). OS and other versions irrelevant. Latest QGC.
Log Files and Screenshots
No response