I’ve been running AC3.5 rc’s for a while now and I’ve been eagerly awaiting the final release. In the mean time I’ve had to step away for a little while, so I fell behind and stopped at rc-7.
Today I discovered that rc-11 was out, so I took one of my two Pixhawk aircraft and flashed it with rc-11. HUGE mistake. Data logging is broken BAD… Its not my SD card. I’m using a 16 gig class 10, and it works just fine in the Pixhawk that is still running rc-7. I also tried the 4 gig class 10 from the good Pixhawk, same issue.
To further verify this is not a hardware issue I flashed the sick Pixhawk with AC3.4.6, and it works just fine. Of course my OLED display is non-functional, but at least Craft & Theory Flight Deck telemetry, retracts, and the STorM32 3 Axis gimbal still work.
What really trouble me is earlier today I read that AC3.5 final may be released shortly, and I sure hope Y’All get this logging issue resolved ASAP…
Data flash logging is not badly broken. Otherwise you would not be the only user experiencing such a thing. So it is likely a hardware or configuration issue on your copter. I suggest posting a telemetry log and parameters file to be evaluated and see what’s wrong on your copter. You should also list what you’re using for hardware and GCS.
It just do not work…
Latest log with default settings result in a Zero (0) sized log.
A short flight today with LogBitMask set to Allmost All show no log at all…
Here is an archive with my Parameter list
(3.5.0rc10-Hexa).Navio2_Hexa3.5.0rc10.Param.zip (4.0 KB)
OK, so nothing unusual in there.
strace output is probably the easiest way forward.
Can you provide a strace output file for the shortest session you would
expect to provide a dataflash logfile, please?
When you’ve armed, what does your ground control station say about the log
sensor health? This should appear with the other health bits like AHRS,
Rangefinder, airspeed and the like.
Well, from the responses I’ve seen I am not the only one having this problem.
However, I do belive this is some sort of data corruption/decoding issue.
The reason I’m saying this is because the Pixhawk works just fine with AC3.4.6 and every other platform specific released firmware version, because I tried them all, and the ONLY time the Pixhawk fails is with AC3.5.0 rc-11.
So on a hunch I flashed with rc-11 and then did a parameter reset. This seems to have resolved the issue. I am in the middle of a complete re-calibration and configuration and will report my results ASAP…
3.5 is another big step up, and as such it behoves us to get familiar with the new changes.
I was not even aware of the new feature of MavLink logging and will check for the parameters today to see where they are at.
I too have been guilty of just loading up a beta, rcX, version and going out and test flying it.
So now this thread can alert people to the new logging available in 3.5.
I’ve had this problem with my PH2.1 Cube since the end of February when I received it - and have commented about it quite a few times.
Actually, now that I think about it, I believe my Pixhawks do it too, if set to anything other than file only. 4 different FC’s 4 different SDcards.
I just set it to file only.
EDIT: Just want to say it’s on 3.5 although I think it started with 3.4 RC’s. AND that setting it back to “file only” corrects it, with correct DF logging.
@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.
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.
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.
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.
??? 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.