I have been trying to track down the cause of the “Bad Logging” messages I keep getting, even though my DataFlash logs look fine. The message comes from FRSKY Telemetry, so not everyone will have this issue. I managed to track it down to the MAVLink backend. If the LOG_BACKEND_TYPE does not enable MAVLINK as a backend, no more “Bad Logging”. I’m trying to find exactly where the fail occurs, and why it does not get reset if it’s a temporary condition. I’ll update this post as I learn more, but at least I can now turn off the messages with LOG_BACKEND_TYPE.
Also, the message is really misleading. I spent lots of time and effort trying to find an SD Card that would work, when the Dataflash file wasn’t the issue at all.
That’s really interesting! I think you should raise an issue. I get this a lot and if its not actually to do with the storage of log files that’s a problem.
I have been trying to track down the cause of the “Bad Logging” messages I keep getting, even though my DataFlash logs look fine. The message comes from
FRSKY Telemetry, so not everyone will have this issue. I managed to track it down to the MAVLink backend. If the LOG_BACKEND_TYPE does not enable MAVLINK
as a backend, no more “Bad Logging”. I’m trying to find exactly where the fail occurs, and why it does not get reset if it’s a temporary condition. I’ll
update this post as I learn more, but at least I can now turn off the messages with LOG_BACKEND_TYPE.
The mavlink backend is not enabled by default.
By enabling it you are telling the autopilot you want to log data via
mavlink.
When it can’t, it goes unhealthy.
Also, the message is really misleading. I spent lots of time and effort trying to find an SD Card that would work, when the Dataflash file wasn’t the
issue at all.
In what way is it misleading? It’s trying to log and failing to.
I think I found it misleading due to SD Card problems in the past. I know others also just assumed it was an SD card issue, and tried to fix it with formats, new cards, etc. We can always look at the code to find a root cause, but not everyone can do that. If the message could somehow point the user to LOG_BACKEND_TYPE that would be fantastic. Its just really annoying when a message just keeps getting spammed every 10 seconds. I should just fix it and make PR, but the whole PR process is confusing and a little intimidating.
I cant really find any good documentation of what a mavlink backend is, what a file backend is, and how dataflash differs from both.
I realize this is a very very minor issue, and I appreciate you guys taking the time to respond.
I think I found it misleading due to SD Card problems in the past. I know others also just assumed it was an SD card issue, and tried to fix it with
“in the past”? Obviously you live in hope
formats, new cards, etc. We can always look at the code to find a root cause, but not everyone can do that. If the message could somehow point the user to
LOG_BACKEND_TYPE that would be fantastic. Its just really annoying when a message just keeps getting spammed every 10 seconds. I should just fix it and
I’ll see what we can do. The GPS driver does try to do something similar
in terms of providing information from backends on prearm failure.
make PR, but the whole PR process is confusing and a little intimidating.
Would it surprise you to say it gets easier / less confusing after you’ve
done it a few times?
I cant really find any good documentation of what a mavlink backend is, what a file backend is, and how dataflash differs from both.
That makes it a little puzzling / worrying about how the mavlink backend
got enabled in your case.
The “dataflash” story is confusing and lengthy. Suffice to say most users
should simply have the “file” backend enabled (a value of 1), and nothing
more. In fact, most users shouldn’t go anywhere near LOG_BACKEND_TYPE!
It’s not puzzling at all!! It is a simple matter of ignorance I could not get telemetry working, and not knowing which type of backend logging to use, I chose both. With FrSky telemetry finally working on both my hexacopter with a pixhawk, and my Convergence with a Matek F405-Wing, the Bad Logging message get really annoying. With a QX7 transmitter the screen is full of Bad Logging messages, and I was afraid I might be missing messages that might have more meaning during flight. Of course I just commented out the line of code sending the message, but I wanted to try to find a fix others could use as well. Ardupilot is such a great piece of software, and the hardcore devs spend so much time working on stuff that is free to everyone!! I want to help in whatever small way I can. Would it be better to allow turning off certain messages with a bitmask like logging, add a timer for any messages that keep repeating, or add an option to not trigger such messages until after arming? I don’t want to add too many parameters as that seems like a self defeating effort eventually.
It¢s not puzzling at all!! It is a simple matter of ignorance I could not get telemetry working, and not knowing which type of backend
OK, note that interacting with the vehicle via the USB connection to get
things like telemetry working is pretty standard.
that might have more meaning during flight. Of course I just commented out the line of code sending the message, but I wanted to try to find a fix others
OK, thing there is that you might silence the message - but you won’t be
able to arm in that case. Probably better to document ourselves out of
this hole than make changes to the codebase.
I could not get telemetry working, and not knowing which type of backend logging to use, I chose both. With FrSky telemetry finally working on both my hexacopter with a pixhawk, and my Convergence with a Matek F405-Wing, the Bad Logging message get really annoying. With a QX7 transmitter the screen is full of Bad Logging messages, and I was afraid I might be missing messages that might have more meaning during flight. Of course I just commented out the line of code sending the message, but I wanted to try to find a fix others could use as well. Ardupilot is such a great piece of software, and the hardcore devs spend so much time working on stuff that is free to everyone!! I want to help in whatever small way I can. Would it be better to allow turning off certain messages with a bitmask like logging, add a timer for any messages that keep repeating, or add an option to not trigger such messages until after arming? I don’t want to add too many parameters as that seems like a self defeating effort eventually.