LogBrowser: FMTU scaling not respected for integers

[olliw42]

Issue details

I believe that the scaling factors provided via the FMTU fields are not respected for integer values.

Two examples:

• I have a configuration where one BattMonitor sends cell voltages. ArduPilot by default stores them in the BCL field using the defines

  define CURR_CELL_LABELS "TimeUS,Volt,V1,V2,V3,V4,V5,V6,V7,V8,V9,V10"

  define CURR_CELL_FMT "QfHHHHHHHHHH"

  define CURR_CELL_UNITS "svvvvvvvvvvv"

  define CURR_CELL_MULTS "F00000000000"

  This makes a cell voltage of 4.123 V to show up as 4123 in the LogBrowser. I tried to correct that to a proper voltage by changing the last define to

  define CURR_CELL_MULTS "FCCCCCCCCCCC"

  with no effect, that is a cell voltage of 4.123 V is still shown as 4123 in the LogBrowser, and not as 4.123 as expected for the 'C'. In the log, the FMTU field related to the BCL log does indeed show up with FCCCCCCCCCCC, which demonstrates that my change made it into the log file.

• The magnetometer data are stored by ArduPilot into the MAG field using the defines

  define MAG_LABELS "TimeUS,MagX,MagY,MagZ,OfsX,OfsY,OfsZ,MOfsX,MOfsY,MOfsZ,Health,S"

  define MAG_FMT "QhhhhhhhhhBI"

  define MAG_UNITS "sGGGGGGGGG-s"

  define MAG_MULTS "FCCCCCCCCC-F"

  In the LogBrowser I however see for MagX,MagY,MagZ values on the order of -200, 100, and 400, respectively, which certainly can't be the correct values in uints of Gauss. If these values would be divided by 1e-3, as it should be if the 'C' would be respected, one would get the reasonable values of -0.2 G, 0.1 G, and 0.4 G.

It thus appears that the scaling factor is generally not taken into account for plotting integer data in the LogBrowser graph.

Version

MP 1.3.62

Platform

irrelevant I believe

Airframe type

irrelevant I believe

Hardware type

irrelevant I believe

Logs

easy to reproduce

[meee1]

was your source a bin file or log file?

[olliw42]

ah ... I actually never look at that ... I always see both on my disk and somehow got the impression they would be equal ... I believe I more usually select the .bin file, but I can't confirm

I will pay more attention to this and try both, and tell you ASAP

[olliw42]

so, here some info to digest for you .bin logfile: www.olliw.eu/drop/michael-mp/2018-12-23_20-06-59.bin .log logfile: www.olliw.eu/drop/michael-mp/2018-12-23_20-06-59.log some pics highlighting some points www.olliw.eu/drop/michael-mp/michael-20183012-bcl-log-bin.jpg www.olliw.eu/drop/michael-mp/michael-20183012-bcl-log-log.jpg

in short, neither the .bin nor the .log show anything reasonable, albeit the BCL data in the .log looks perfectly fine

the logs should allow you to get to the bottom and check fixes

THX

EDIT: as mentioned, similar issue you can see for the mag

[meee1]

the issue here is there are 2 systems in play. the storage format, and the display format. i do believe there are fundamental issues with the current implementation

The issue will be with the UNIT, FMTU and MULT messages

[olliw42]

many thx for looking at it

I must admit however that I don't really understand your comment: You're saying that the UNIT, FMT and MULT fields in the ArduCopter code should be different? If so, what should they be, i.e., how should they be changed?

In my simple view the FMT clearly gives the storage format, but I have interpreted the UNIT and MULT entries to be indications to any "user" of the data such as a GCS of how the data should be plotted/interpreted. In that view it wouldn't be an ArduPilot-sided issue. That's why I issued here. Sorry if that was the wrong place.

[rmackay9]

Similarly @bnsgeyer and I have noticed that the scaling is incorrect for the PM.load field. It is logged in deci-pecentages and the FMTU for the PM message says field 7 is "A" meaning it should be divided by 10 but it's not.