How to really read logs & specific help with a log for an intransigent quad

I cannot read logs well, and I have a quad with problems.

Starting with reading logs. I have gone through the available instructional material I can find
(this for example
(please suggest more, hopefully there’s something I haven’t seen yet)
but it just isn’t getting me over the hump. I can pull up a log, I can find the particular data that might be relevant, but it still doesn’t mean anything to me. The error messages sit on top of each other so I can’t read them, and when I try to zoom in I just lose it all. I just can’t manipulate the viewer GUI properly. Don’t get me wrong, it’s awesome that a viewer GUI is built in to MP, but still it’s pretty clunky and I just can’t figure out how to “drive it”. I would love to be a master like those of you who can read off the entire flight history of the drone from the logs, but I don’t know how to get there. Staring at more logs isn’t going to do it, at least not the way I’ve been staring at them, because I’m not picking up anything at all yet. Is there a standard procedure you guys have evolved, looking at particular data first to get an overview, things like that?

Here are some specific current “real-life” :slight_smile: problems:

-AP V4.1.0-dev, MP 1.3.74

  • I’m linking to a .bin log of a short test flight.
    .bin log

  • This is a 7" FPV quad, with a cheap BN880 GPS/compass module on a short “tail” extension to push it away from the rest of the electronics. I had this setup working fine (e.g. this frame was flying with this FC and this cheap GPS/compass without errors), then I changed the motors, moved components around, changed battery, added LED lighting. I recalibrated the gyro and compass (a few times) but I can’t get it back into flyable shape. In my telemetry I see “bad gyro health” and “EKF variance” and “GPS glitch” and “compass… can’t remember what that one was.” But to me this sounds like either too much vibration or compass/GPS interference. Or both. So before I go changing things without knowing the problem, perhaps we could diagnose using the logs?

-I can’t find VIBE in my log. Am I blind? I may be. I have my logging bitmask set to 830 for default. Does the default logging not include VIBE? It doesn’t say anything about that here:
so I’m assuming that vibe should be in the default log info…

-I attempted to convert the .bin to a .log so that I could open it in different graphing software. However, upon clicking “convert .Bin to .Log” and choosing my .bin, I get no response. Did it do something? If so, where did it put the .Log? I went digging around for it and I can’t find it. So I’m not sure how to extract a binary into ascii that I can suck into different viewing software (with which I am more comfortable perhaps).

So, suggestions regarding the incomplete log I have, and where to go from here?
much thanks,


1 Like

It’s a bit difficult to tell what is going on since some log messages are missing - maybe you need to configure LOG_BITMASK?

Your yaw error gets quite big which I think prompts the EKF reset and the big throttle jump. My guess is its to do with the MAG - could be wrong - but you get a but jump in MAG innovations in the lead up to this. So maybe try recalibrating your compass and running compassmot

thanks for the compassmot recommendation, somehow I had never seen that page. I will plan on including that in the eventual mix. Still hoping I can do some sort of physical improvements to my setup though, if it’s the mag field interference. Perhaps some shielding somehow? I already have the compass physically as far from the motors as I can reasonably achieve in this build. I suppose I could buy a different gps/compass unit, if that would help. Do we know if the largest fields come from the motor wiring, or the motor itself? If it’s the wiring, I could conceivably shield the runs out the arms, small hit on weight for some foil shielding I think. Obviously if it’s the motors themselves there’s no easy way to shield those.

I have my LOG_BITMASK, 830 for default, do I need to include IMU in order to get the VIBE data? I am reluctant to just try it and see until I make some corrections to my setup, otherwise a more damaging result might ensue. But if the missing data could be essential, maybe I’ll take my chances with a second short flight and be ready to jump into stabilize (hopefully quickly enough).

holy cow, is pretty incredible. Just barely getting started with it, and I’m going to have to take some playing with it but thanks for the suggestion. This link should definitely be added to the documentation pages about viewing logs

Yes you need the IMU data. You should also include the compass data

This is a good catch-almost-all bit mask.

Okay I have collected additional data with my hot mess of a quad. I kept it in close, because it was definitely not flying properly.

My vibration isn’t the problem right? It stayed below 15 at all times, usually below 10, which isn’t good, but shouldn’t be catastrophic right? (aside: how do we know what the units for a particular piece of data are?)

The units are defined in the log. so shows them.

One problem is weight shifted to the rear, you can see motors 2 and 4 are always working harder than 1 and 2. It copes but this leaves less headroom for attitude and yaw control. It can be a lot less of a problem once tuning is completed and you expect this for example adding a payload. Good balance certainly makes tuning much easier.

There doesn’t appear to be current monitoring, that will be handy if you can get it working.
Voltage monitoring - hard to tell what’s going on there. Could be an issue with your flight controller, power brick or even the DEV version of firmware

Could your barometer be exposed and getting propwash?

Attitude control is OK for now, Some people would think that is good :slight_smile: You’ll be able to move onto Autotune if some of the above issues can be figured out. I suspect your INS_GYRO_FILTER is too low, and it should be at least 40. What did the spreadsheet say for your size props? Check the spreadsheet again and use all it’s calculated values (dont keep INS_GYRO_FILTER=20 like it suggests).
Download a new copy of the sheet if you have to, it’s been updated recently.

Yaw is doing OK for now too:

Compass is a little affected by throttle, but it’s not the worst. The Compass/Motor procedure will help.

fascinating. I thought I had voltage and current set up correctly finally. I’m seeing values in my stats:
The setup is a bit funky. I’ve got no power brick. I’m running a Kakute F1 V1.5 FC with a Tekko32 4-in-1 ESC. The FC has a built-in voltage monitor wired to pin 13 that is not calibrated well and I was avoiding using, and the FC has no current monitor. The ESC sends voltage over the BLHeli telemetry and I was using that (appears nicely calibrated) and it has a built-in shunt to send scaled analog voltage for current monitoring, and that’s routed to pin 12 on the FC. I’ve got batt1 set up to monitor current through the FC pin 12 (BATT_MONITOR, 4 for “analog voltage and current in”) but there’s no voltage on batt1, and then I have voltage coming in through my ESC telemetry on batt2 (BATT2_MONITOR, 9). I had thought it was functioning because I get good voltage and current telemetry back to the radio while flying. And I can see good values in the stats area, when connected via usb (got no telemetry radios for GCS connection).

I thought I had ESC telemetry working because I was getting a voltage back from the ESC, but now I’m thinking I was mistaken about that. How do I know when the ESC telemetry is working properly? I’m getting 4 separate escx_temp and escx_volt, but not current (because I don’t think the tekko32 passes individual current which is ridiculous) or any other fields.

I had enabled the harmonic notch filter using ESC telemetry, but without the telemetry that’s clearly not going to function. Should I disable the harmonic notch filter since my ESC telemetry is… not there? Does enabling the harmonic notch filter disable the low-pass filter?

In either case, my INS_GYRO_FILTER was set to 20. Your spreadsheet is awesome–yet another thing that I had never seen before, thank you for that. I had to search for it and the link I got is v1.4, is that the latest?

You’re absolutely right, the spreadsheet tells me it should be 57 (7" props+4S battery) so I updated that.

Certainly once this is flying well enough to permit auto-tuning that should improve things. Changing out the motors and battery definitely made a difference, and it hasn’t been tuned since then (got to get it flying reliably before I’ll trust it to tune itself that’s for sure).

this is my full parameter file:
parameter file

perhaps my funky setup is stumping the logging? I was having trouble figuring out which data fields could show me the motor thrust. I see you gleaned it from the RCout values, but ideally that would come from what, the individual motor current? Is there any other way, without ESC telemetry for individual motor current?

Good to see about the weight to the rear; I can shift that forward easily. It seemed as balanced as my finger and eye could tell.

the barometer is probably getting propwash, I’ve been dealing with that just by… living with it. that part hasn’t changed from the previous setup, so I’m assuming that it’s just as bad as it was before.

thanks for all the help

another flight.
another .bin log file
stayed close and hovered around in a 10kt headwind to collect more data. I was seeing all sorts of notices on the radio telemetry; where can I locate those same messages in the logs? (I’m using the UAV Log Viewer) Are those derived from the error messages? In the log I see some ekf_yaw_resets when I look at “events” and I see some 11 and 17 error codes. From here I see that those are GPS and EKF failsafe codes, respectively. The yaw resets appear to be associated only sometimes with the errors.

You are right, the ESC voltage and current is there, I missed it before. Probably remove that ordinary battery monitoring setting and move the ESC telemetry battery info to BAT1 instead of BAT2.
Then properly set

If you have ESC telem from each ESC they are recorded separately in the logs and you can see current and voltage from each ESC. Connect the Telem wire from each ESC all together and they figure themselves out as far as numbering goes. Arducopter averages the voltage and sums the current for “BATT” logging purposes. From other sensor types there is only the total current.

For the harmonic notch filtering with ESC telem use this:

Motor thrust is actually recorded in CTUN ThO

Use all the Filter, MOT_BAT, BAT and other settings from the spreadsheet.
You can round the filters up or down a bit, like make them 50/25 or 60/30.
Your ATC_ACCEL values looks standard for example…
MOT_BAT_* helps with tuning and also attitude control

regarding the re-jiggering of the battery monitor setup: yes it would be great if it worked that way, but it doesn’t (not for me, anyway). That’s the battery setup I tried at first, but I couldn’t get ardupilot to read and sum the currents from the telemetry. I just modified my parameters to match your suggestions again, to double-check:

and sure enough, my current values disappear.

You commented in another question thread of mine about that issue as well, and the only solution I found was to separate the battery monitor functionality. As you mentioned there’s some confusing comment in the Tekko32 manual that says “The 4in1 has onboard analog current sensor, and TLM function(then no current reading over TLM)”. It doesn’t make any sense to me why I should be able to move it onto the second battery monitor and it starts working. I had thought that current wasn’t being reported from the ESC over the telemetry at all, but then we just noticed and talked yesterday about how it definitely was. So I don’t know what’s going on.

I already had most of those notch filter settings, just upped the bandwidth and attenuation some. Really 40dB on the attenuation? That’s above the recommended range (and it’s a logarithmic scale…).

Added in the MOT_BAT numbers, had missed those somehow, thanks.

I didn’t include the low voltage failsafe, because a) my quad is in no shape to perform a failsafe other than dropping out of the sky which I would prefer to do manually if necessary b) I prefer to monitor the battery and make my own choices. I’ll probably configure it eventually, once I can actually use this thing in an auto mode. thanks again for the help

My individual ESC telemetry current values are not showing up again, and all I did was revert to the parameter set when it was working. Man this is frustrating. Chasing my own tail.

You have the same Tekko32 ESC you posted about before? If so how did you ever have individual current via ESC telemetry? From what I can see it doesn’t have a shunt resistor for each section which is required to do that. Looks like it has a shunt resistor (2 in this case) for total current as analog out on the connector.

Tekko32 1 Tekko32 2

And with regards to the Voltage measurement on the Kakute F7 that can be easily calibrated using Mission Planners Battery Monitor (Measured calibration voltage). I suppose it was reading low? No big deal.

yes it’s the same ESC I posted about before, which is slightly different than the image you posted (I have the “metal” version) but I think it’s the same deal. If the shunt resistors are those two just above the battery pads, then I also have only two (they’re on the back side on mine).

I could have sworn I saw separate currents on the status tab for each of the ESCs, but now I think that I was either imagining it, or it was a different drone. So I’ll just backtrack on that.

Regarding the voltage onboard the kakute FC: yes I can calibrate it as soon as I get around to it, but the ESC was providing good-looking voltage over the telemetry anyway so I was just being lazy and using that. So in the end I am getting current and voltage both reported back to my radio for flying purposes, so everything is good except for voltage not showing up properly in my logs, which @xfacta noticed earlier in the thread.

What I don’t know is if you need battery voltage on Batt 1 for thrust scaling or voltage is used from any battery input where voltage is present. if it’s the former you will for sure want voltage on Batt 1.

IOW, if you have multiple battery monitors configured which one is used for thrust scaling. Not knowing the answer to that I would enable voltage on Batt 1.

“I cannot read logs well” Same here. Define what is not flying well. if the quad is shaking turn back the pid slider and reduce the pids in the axis that giving you issuess. Small quads require some love. showing a photo of your setup helps.

Hi Matt,
I now see what you mean, using those ESCs. So you could get voltage from ESC Telem and current from the analogue signal - using BATT and BATT2 params.
Or you could make a voltage divider circuit and use that (off the Vbat wire) and the analogue current sense wire all to BATT params, leaving BATT2 disabled for a simpler setup.
Without setting up BATT2, you’d still be able to get ESC telem logged, so after a flight you’d be able to check RPM, temperature and so on.

Here’s the original 3DR voltage divider circuit if you need it:
R1=13.7k, R2=1.5k, C2=0.1uF
In this pic “C_IN” is the battery B+ input, and “V_BATT” is the scaled voltage sense wire to the flight controller. It’s important to use metal film 1% resistors.