Don Gagne
Don Gagne
So this was changed 9 years ago: https://github.com/mavlink/qgroundcontrol/issues/2951. The rational behind it which is to save in the file the actual value with full precision I think still makes sense.
I thought it was just decimal places were the problem. Not sure where QGC's param format differs. Can you detail? Also FYI: QGC 5.0 supports showing you the diff between...
So I've been looking at the QGC format, which is: `Vehicle id, componentId, paramName, value, type`. It's been this way over 10 years, predates any of my work. That said...
@AndKe And thank you for always reporting problems and helping to make QGC better for so long now.
Also FYI: Although parameters theoretically support [u]int64's. QGCs px4 parameter metadata parsing code assumes 32 bits only for bit masks. That said switching to support 64 bits doesn't seem like...
@dagar Any reason bit masks can't be UINT32? That would fix the max problem.
A unit test which sanity checks the metadata would be nice so that this doesn't make it all the way to QGC before it's discovered. Look at https://github.com/mavlink/qgroundcontrol/blob/master/src/FirmwarePlugin/PX4/PX4ParameterMetaData.cc#L78 to see...
Also a simple option is to remove min/max from the output bitmask metadata. In reality since this is a signed int they are both being set incorrectly.
All of those are just warnings and shouldn't causes any problems with flight.
This is still making me a bit crazy from the QGC side of things. Would be nice to be fixed so I could get cleans runs of QGC without warnings.