While scavenging through logfiles to check this post GPS glitch and short fly-away with Copter-3.4.4 , I’ve noticed something weird. There are spikes in my Hdop graph, with negative values. Weird.
Could someone explain to me why? Never have noticed that before. Same GPS that I’m used to fly on this machine.
Spikes:
Close:
Hi Fernando,
What GPS is it?
M8N from banggood. Been using this for the last 30 flights with this drone, but never seen anything like this. I can change it to an original 3dr if you think that it could be the cupid.
However no issues at all with the flight. Everything went normal
I had never seen it, looks strange.
@WickedShell any thoughts on this?
I’m thinking about enabling raw gps log. If it came from GPS that’s very weird.
Spikes are everywhere… gps alt and other values as well. Maybe the change of port speed to 115200 ? I’m thinking about lowering it to 57600 to see if it helps
I think the M8N can’t do RAW logging.
The baudrate change was tested in all u-blox series, but I’m not excluding that something is bad with that particular GPS with a higher speed.
yeah, you’re right… I’ve lowered the speed to 57600. Lets see if this helps. Tomorrow I’ll give a try.
@tabascoz How did you lower the speed? If autoconfig is enabled it will ignore any requested baud rate and force the desired rate regadless.
@tabascoz the log file you posted is corrupt, I can’t get it to open with anything here, and something worth noting is that your graph is of grabage data, as it isn’t possible to have a negative HDOP value, and we only log it as a unsigned value, so MP is incorrectly interpreting the data in what it is attempting to show you.
Strange… I can open the very same file in mission planner beta. Have you tried it in mission planner?
To lower, I disable gps save_cfg and enable autoconfig, mavserial-pass and changed it in ucenter, then rebooted pixhawk with reboot command and changed port speed.
For sure there is something wrong with this and pehaps all other logfiles generated with this drone , I have noticed that the minutes bar in the graph is corrupted, however all other data ( among gps ) are safe.
I’ll also format the SD now and try an offline log to see how it goes.
@tabascoz What I’m trying to say is that the graph mission planner is trying to show you is out of spec. We don’t record values with the range it’s showing you, so its created a bad graph because it interpeted the corrupted data wrong.
If autoconfig is enabled then we will always force you to the correct baud rate of 115200. I’d strongly recommend sticking with this baud rate though, it has been well tested on a number of systems and is not a recent change at this point. Its to early to be pointing at the baud rate as the problem until you can produce a non corrupt log to look through.
OK WickedShell, I’m reverting the gps change and sticking with the default. Since I haven’t messed with any LOG or whatever related from long time and in previous FW versions the log was fine ( I have never had a log issue before ) , what do you think that could be causing this ( corrupt log ) ?
I’m formatting and verifying the SD now ( dd copy and fsck ) and it seems OK. I’ll format it anyway in windows and will try do to some disarmed log to see if I get anything out of order.
Reverted everything, logged 10 mins of disabled data. GPS data was fine, without any hiccup. Sd is 100% ok, tested with dd, badblocks - solid transfer rate.
The “minutes bar” on mission planner graph is still crazy, however that is another issue issue. Plotted several graphs and the log seems really nice. Will fly tomorrow to observe.
Wow,
After two hours of corrupted logs and debug I figure it out. I´ve tried everything - changed SD, computer, cable, usb port etc. and always when I download the log from Mission Planner through the USB cable it got corrupted. However if I detach the SD card and insert it direct to my computer, the log was OK.
Started to play with conf and the culprit was that MAVLINK_protocol for serial0 ( usb ) was set to 2. If so, log gets corrupt. It could be a mission planner bug or firmware bug.
Back to mavlink version 1 and everything went fine!
Could you guys please test it to see if it happens to you as well? If so, I will open an issue. Thanks.
Windows 10 - Mission Planner 1.3.43.3 build 1.1.6220.13108
Com driver port from 3d robotics version 2.0.0.9
@tabascoz nice find/detective work
@Michael_Oborne have you ever tested downloading logs over USB with MAVLink2?
Thanks @wickedshell and sorry for the false alarm
Hijacking my own tread 
Michael, in addition:
When i switch to v1 all issues are gone.
can you tell me how to mavserial-pass?
@wyq200704 It’s hidden in the Ctrl-F menu, it will open a tcp port 500 on your localhost. You can check the instructions on the wiki here: http://ardupilot.org/copter/docs/common-ublox-gps.html#connection-option-1-mission-planner-and-pixhawk-as-passthrough
Ardupilot won’t be able to directly use the GPS after this has been setup until after you’ve rebooted the autopilot, as it will always be passing it to the GCS. I’ve had best luck with this using USB to the autopilot rather then a telemetry radio to the autopilot.
