AC3.5 rc-11 BAD LOGGING errors

@Lance_B and @oldgazer1 , do you actually have a companion computer? Setting LOG_BACKEND to 2 or 3 is only for when you have a companion computer that receives and stores the DF logs over mavlink in flight. If you set it for 2 or 3 without a companion computer to receive the logs, you will get the logging failure since the logging is legitimately failing. If you just have a Pixhawk and no companion computer, LOG_BACKEND is required to be 1 (file only).

The default is 1, which is probably why the “problem” went away when you reset the parameters to default. This is not a bug or a “known issue”. It’s doing exactly what it it is supposed to do. You’re telling it to log to something that doesn’t exist and it’s throwing an error as a result. Having the parameter set wrong is a very simple operator error. And it happens often when going from one major version to another that contains new features.

1 Like

I’ll add a note to the wiki about the new option to log to the companion computer. I hadn’t really though much about this parameter and wasn’t really expecting anyone to find and/or change it but I can imagine that it could be changed accidentally and we should explain it in any case.

1 Like

Well, that’s kind of bogus.

If the default is FILE, and if like another victim I knew nothing about the “new” logging options, why would I set logging to an option that I didn’t know existed?

As I have this sorted out now, for me the point is moot. I resolved the issue by blasting Helicopter firmware and then blasting Quad rc-11. I had to go back and redo the retracts, C&T telemetry, OLED, StorM32 BGC parameters and run all of the calibrations (ACC, Compass, Radio, and Battery Monitor) and tomorrow I will do the CompassMot calibration followed by a check flight.

For the time being think I’ll just chalk this up to a download glitch, because, quite frankly, nothing else comes even close to explaining why this happened.

You’re welcome… I hope you’re not further victimized by whatever travesty took place here.

Yes. Otherwise I wouldn’t have turned the parameter on. We ARE capable of reading and understanding.

Edison on the PH2.1 Cube -and yes, the APsync image is loaded, and correctly, and functioning.
Just haven’t wanted to mess any more with it, so it sits there and consumes power, and does nothing really. But I also don’t want to pull it all apart to remove it.

No longer have on the the Pixhawks, just too cumbersome. Was using a PI though.

EDIT:
FWIW, the arrogant and BS replies from you - Pedals2Paddles’ throughout this whole thread simply uncalled for. and seems to be the norm anymore by too many Devs, especially toward the the handful of people testing their software (which I fully realize is free for me, and I appreciate it, always have, and have always said so - even though I put my safety and that of my craft, and my money at risk doing so, to help the cause).

Most others might night feel comfortable calling you out on it but I do. I wouldn’t treat anyone that way, and i don’t expect to be treated that way in return : )

Your software and coding aren’t perfect, nor will they ever be, or we wouldn’t be testing it. Anymore than the work I do. So get off your mighty thrones and quit it with this crap, seriously. Randy is the only one I’ve ever seen appreciate the fact we’re doing this, sorry but it’s true.

This reason specifically is why I’ve quit participating and testing. That and the simple fact that most issues seem to fall on deaf ears, or simply aren’t even acknowledged. Like this one.

For the record, part of the wiki on installing the Edison / Apsync, is to enable this parameter.

Thanks Randy.

??? I asked for logs and further details to help evaluate the problem. I explained what it is supposed to do absent that further information and detail that was not yet provided to be more specific. And so did Randy, who is the lead developer for ArduCopter. And so did Peter who is the heavily involved with AP Sync. So the notion that you’re being ignored is quite untrue.

If this is all unsatisfactory to you, and you want instant answers for instant solutions to very vehicle specific problems without vehicle specific information, I’m not sure what else can be offered. I’m sorry I wasn’t able to meet your requirements, but I am not sorry I tried to help you. Hopefully someone else will still try to help if you still want to get it working.

I think THIS is the kind of snark Lance_B is talking about. You could be a little more tactful in your replies.

Just my two cents.

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?