Plane: Updated QTUN and NTUN units to modern multiplier #27875
Conversation
Did not change the format character, as pymavlink seems to need it, due to a bug.
| // @Field: TAsp: target airspeed | ||
| { LOG_NTUN_MSG, sizeof(log_Nav_Tuning), | ||
| "NTUN", "QfcccfffLLeee", "TimeUS,Dist,TBrg,NavBrg,AltE,XT,XTi,AsE,TLat,TLng,TAW,TAT,TAsp", "smddmmmnDUmmn", "F0BBB0B0GG000" , true }, | ||
| "NTUN", "QfcccfffLLeee", "TimeUS,Dist,TBrg,NavBrg,AltE,XT,XTi,AsE,TLat,TLng,TAW,TAT,TAsp", "smddmmmnDUmmn", "F0BBB0B0GGBB0" , true }, |
There was a problem hiding this comment.
the 'e' already has the * 100 built in, so if we added the B it would apply twice, and get the wrong answer
There was a problem hiding this comment.
we should probably change the '0' to a '-' meaning no multiplier (thanks @peterbarker )
There was a problem hiding this comment.
I don't think it applies twice. At least not in my testing. I vaguely remember that the MAVProxy logic is that if a format with multiplier is found, then the separate multiplier is not taken into account.
I would prefer changing the format e into i, but seeing this triggered some unwanted behaviour last time, I thought I'd double-dip and do scaling via both the format and the individual multiplier. Mostly because doing it right doesn't seem to work correctly: ArduPilot/pymavlink#965.
It's not a big deal, let's discuss live.
|
need to get this fixed first: |
2 participants
Did not change the format character, as pymavlink seems to need it, due to a bug: ArduPilot/pymavlink#965
Before:
After:
