Open olliw42 opened 5 years ago
was your source a bin file or log file?
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
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
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
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.
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.
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