AC3.5 rc-11 BAD LOGGING errors

Perhaps. It seemed appropriate though, as the person I was responding to’s problem seemed to be rectified and he did refer to himself as a victim :). I do admit I have a tendency to return snarkiness back when it is dished out, and that is one of those occasions.

What bothered me immensely about this thread from the very beginning is coming in on the offensive blaming everyone, insulting the developers, and actually making themselves out to be “victims” of something. Like we all conspired to make their vehicles stop working or something. Everyone here loves nothing more than helping troubleshoot and resolve problems. And despite the bad attitudes that someone people come in here with (not just this thread), we still try to help. Sometimes, it is just never good enough though.

Hi all,
I am getting bad logging as well since I updated to 3.5.0.stable I tried everything in the book and outside but I am still getting bad logging.
Not right after arming but a few minutes into the flight.
it is a simple streight forward 3drX8 with new motors and ESCs

what do you need to ID the problem?

https://drive.google.com/file/d/0B3B3DBdgHDlqVEJ5dGNnOGdRNGs/view?usp=sharing - tlog
https://drive.google.com/file/d/0B3B3DBdgHDlqWm4yd29Wb1Jmdk0/view?usp=sharing - bin

What have you tried?

I am getting bad logging as well since I updated to 3.5.0.stable I tried
everything in the book and outside but I am still getting bad logging.
Not right after arming but a few minutes into the flight.
it is a simple streight forward 3drX8 with new motors and ESCs

what do you need to ID the problem?

A reproducible scenario would be awesome!

I’ve created this PR to add debug; I’m quite sure the call to ::write() in
the io thread is never returning.

just to be sure - you (anbd everyone else playing along) weren’t doing
anything to do with logging? Not trying to browse log files or the like?

Nope. I launched Mission Planner, plugged in the USB cable, and after the boot tones stopped I clicked Connect. MP connected, downloaded params, and immediately reported “Fail Safe Bad Logging”…

Nope. I kept it on default setting. In my case bad logging came several minutes in the flight each time.
Tomorrow I will put the 3.5.0 on a TBS Discovery quad. I wonder if I get the same behavior.

Gentlemen,
It looks like my Bad logging is solved:
Problem was bad sector on the SD card.
After a flight without bad logging on a regular quad I put the SD card of the quad in the x8 and started the same AUTO mission. The mission ended without bad logging.
Prior to coming to the test filed I did a CHKDSK on both SD cards and the one that gave bad logging there were some errors which I quarantined. On the other SD (the one without bad logging) there were no issues.
Just now, after the flight I redid the CHKDSK and the issues on the BAD SD card were visible again.
Since every theory needs a proof I went to a short flight with the Quad and the "bad logging SD card " and it gave BAD logging after a few minutes in the flight.
This confirms that the SD card is the source of my bad logging.
Sorry for blaming on the 3.5.0! Next time I will be more thorough before I jump to conclusions!
Is it possible that the 3.5.0 completely disregards these quarantines? Just asking to see if I need to throw away the SD cards with issues or not.

It looks like my Bad logging is solved:
Problem was bad sector on the SD card.

Thanks very much for the follow-up on this, and the great

After a flight without bad logging on a regular quad I put the SD card of
the quad in the x8 and started the same AUTO mission. The mission ended
without bad logging.
Prior to coming to the test filed I did a CHKDSK on both SD cards and the
one that gave bad logging there were some errors which I quarantined. On the
other SD (the one without bad logging) there were no issues.
Just now, after the flight I redid the CHKDSK and the issues on the BAD SD
card were visible again.

Ah, now that is interesting. It’s not chkdsk ignoring the quarantines
(Linux user here, sorry :wink: )

Since every theory needs a proof I went to a short flight with the Quad and
the "bad logging SD card " and it gave BAD logging after a few minutes in
the flight.
This confirms that the SD card is the source of my bad logging.
Sorry for blaming on the 3.5.0! Next time I will be more thorough before I
jump to conclusions!
Is it possible that the 3.5.0 completely disregards these quarantines? Just
asking to see if I need to throw away the SD cards with issues or not.

They’re cheap. Use another :slight_smile:

I should note that the chief difference between 3.4 and 3.5 here is that
problems with the logging system now blaze across any connected GCS’s
screen. Both the “IO thread dead” and “BAD LOGGING” errors (the latter
coming from a single bit in a particular mavlink message) are new in 3.5.
Prior to this you could have issues with logging and not know until you
landed - a serious problem if you’re flying to collect those logs to go
with photos, for example!

That’s not to say we don’t have a regression. If you could run your
tests against 3.4 that would tell us pretty definitively.

Thanks Peter,
Right now I have to concentrate on solving the inexplicable drop/gain in altitude of my big hexa. https://discuss.ardupilot.org/t/drop-gain-in-altitude-when-yawing/21101/2
Once that is done I will load the 3.4.6 onto the test quad which still gives me bad logging occasionally and let you know the results.

Hi All,

Ever since I moved to 3.5. -0,-1,-2 I have been having the BAD logging issue. Unfortunately it has been random re-occurrence so I could not pinpoint the problem nor could I help anyone ID the problem. I had it on 4 different copters: 2 octa-quads, 1 quad and 1 hexa. this morning I loaded the 3.4.6 and did a short test.
Impressions from the test:

  1. Log file numbering is xx.bin. with 3.5 it was 000000xx.bin
  2. While reading 3.4.6 BIN there were no errors in Mission Planner or APM Planner - with 3.5 there were always errors and I could only review them if converted to .log. I have to realize that there may be a correlation.

Error execting index: NKT1 UNIQUE constraint failed: INDEX.idx Unable to fetch row. (APM Planner)

  1. I know EK2 and AHRS have not been heavily modified since 3.4.6 but IN MY OPPINION copter flies better and smoother with 3.4.6 than with 3.5.x in high winds.

Since I have another issues that could very well be caused by the same source. (drop in hight when copter 0rientation is 0 deg) I will try to put the 3.4.6 on the big hexa and see what happens.

sorry it’s probably a silly question but i am kind of stuck by what is NKQ, NKT. And you are the only result when i search.Could you tell me what does NKQ, NKT mean or where i can find the explanation?