In arducopter some parameters are set with bitmask number … why is it that not all parameters in bitmask have charge checkboxes available in qground …
Eg arming_checks has different checkbox options
But ins_raw_log_opt has only number to fill
Thanks
Because with the current approaches to software development, all this knowledge (the description of each parameter, and in particular whether it is a bitmask, and if so, meanings of each of the bits) has to be hardcoded into ground control software. INS_RAW_LOG_OPT is very new, so not all ground control systems have added the corresponding support yet, though they may do that as they roll out updates.
One of the possible consistent solutions would be to fetch (and cache) parameter descriptions from the particular Git snapshots corresponding to your current running version of Ardupilot. Due to how exactly parameters are implemented, this is not a straightforward task. And even this is imperfect, because a straightforward implementation will fail with custom branches without universal public access. I don’t even mention possible pitfalls working around possible changes of parameter handling code in Ardupilot itself…
So TL;DR you probably have to wait for a newer version of QGC or any other equivalent, and in the meantime learn how to interpret numbers as bitmasks.
1 Like
Thanks for the reply, no problem for me if you know the parameters it is easy to adapt. When an unknown parameter comes in it will be more difficult .
Thx
Normally the most recent description is in Complete Parameter List (Complete Parameter List — Copter documentation for copter, roughly the master branch, also there are such pages for all other vehicle types, also there are pages for all recent stable versions), so if in doubt, go here. I always do.
These are generated from embedded documentation in the sources, so if there is a human-readable description for something, this is it. In rare cases, this documentation may be not up to date.
And, definitely, the minimum, maximum and step values for parameters are often “recommended” or “safe enough” values rather than their true limits, which some of the ground control systems mistakenly enforce in some of their interfaces. There is no easy way to tell apart one from another. When in doubt, I study the source code, but it’s relatively easy for me and may be hard for most people.
Not exactly.
The Index of /Parameters/versioned contains all the information needed.
The Ardupilot Methodic Configurator uses that information and requires no changes in it’s source code, meaning if a new ArduPilot version comes out, You do not need to update the configurator, and old configurator version will be able to correctly display new Ardupilot parameters 
1 Like
This one is nice to have, but it will work imperfectly for beta versions, as this directory is not populated for them, and especially for different branches, as this directory is not populated for each and every git branch in existence.
So although this helps, some kind of fallback behavior is inevitable.
And based on the user’s feedback. apparently QGC does not use this (yet).
1 Like