wrong MAVLink version error

[night-ghost]

this message can only be displayed only if no heartbeat packets have been received, but not in the middle of the session.

[meee1]

can you post the rlog for that connection?

[night-ghost]

here, change PNG extension to ZIP

[night-ghost]

and perhaps it would be better not to stop downloading the log on error but continue to download. Now downloading logs on through MAVlink via USB works disgusting (more than 20 tries and ~1 hour of my time), and not work at all by the radio - timeouts . But to get to the USB I had to disassemble the copter :(

[meee1]

did you download this log over usb? there is a massive amount of corruption in the rlog you sent.

[meee1]

also is this a custom firmware? with custom mavlink messages?

[night-ghost]

yes this is via USB (because via radio it not works at all), firmware can be seen on screenshot - Arducopter 3.4-rc3 uploaded via MP itself from official site

[meee1]

the rlog I'm looking at is suggesting that its via radio not usb, as I'm seeing radio status packets in the log. and the txbuffer is at 100% for almost all of it, which is causing massive packet corruption.

could you please retry and set the baudrate to highest? I assume this is a pixhawk?

[night-ghost]

Sorry this was a last RLOG in folder, tomorrow I'll try again. Baudrate is 57600, board is PixhawkLite from Aliexpress.

[meee1]

if you are connecting via usb, change it to the highest baud

[night-ghost]

I see this stats when not trying to download logs

[night-ghost]

but when I try to download log I got

[night-ghost]

pure experiment. Removed all the logs, it runs the MP and only one attempt to download the log. The result - a false diagnosis MAVlink version.
Attached screenshot - so I see stats via USB

[night-ghost]

screenshot
https://cloud.githubusercontent.com/assets/6255710/18553782/a7804cf4-7b83-11e6-82a3-89bca126467d.png

[meee1]

was this log downloaded via usb? I still don't know why you are getting packet corruption over a hard wire link. this should not happen. which makes me think this is a hardware issue.

[night-ghost]

Do you read my words? Downloading via radio DON'T WORKS AT ALL with timeout, downloading via USB - errors about MAVlink version.

which makes me think this is a hardware issue.

Yes the best way to not fix errors is to declare them as hardware problems :)

PS. Inability to download logs via radio is a hardware problems, too? ;)

[meee1]

I still stand by this is a hardware issue.
Mission planner internally preforms these steps.

1. request log data
2. wait for log data for up 3 seconds (will retry 3 times, and resets the 3 attempts if it receives a valid packet)
3. request next log packet
4. repeat

your board is failing at step 2. mission planner never received the log packet from the autopilot, or it starts, then stops responding.

as for radio, this is most likely because rts/cts is not enable on the pixhawk side, and the buffer is flooding, causing corrupt packets.

PS all this is just guessing, that and the Mission Planner user base are not having the same problems.

it could be
sd card
usb cable
pixhawk
drivers
radio settings
rts/cts

[qmayberry]

So is this error a bug then as nothing has changed other than upgrading to 1.3.39?

[meee1]

@qmayberry please try formatting the sd card, I would guess there is corruption on the sd card, causing the pixhawk to hang.

[qmayberry]

It's not a pixhawk, but an APM 2.6! I haven't used a pixhawk yet, it is my next project.

[meee1]

@qmayberry I don't have an answer then,
refer to this
#1356 (comment)

basically the autopilot is not responding to the request, I assume this hardware has worked in the past?

you may need to wipe the dataflash. losing the log.

[qmayberry]

Ok, I will see if I can find an earlier mission planner on one of our machines that used to work, just to make sure it is a hardware issue before losing the log.

Seems a bit coincidental that it was fine before the upgrade and now doesn't work when nothing else changed other than the mission planner!

[meee1]

@qmayberry please do test, I'm happy to be proven wrong.

[qmayberry]

It's not a case of proving someone wrong, it's just a case of trying to save a log file before wiping it out!

I got a no log list message on 1.3.35.

However, I was able to download the logs via the terminal logs, dump function. in 1.3.40.

How do I format the card of the APM 2.6 without having to take it all apart? Does log erase do the same task?

[meee1]

@qmayberry atleast the terminal worked, I would watch for log corruption in the log you downloaded.

[meee1]

@night-ghost could you please try the latest MP 1.3.40. just wondering if its still an issue.

[meee1]

@qmayberry just do a log erase

[night-ghost]

I still stand by this is a hardware issue.

Of course, it's much easier than to fix bugs and remade a bad solutions! You see, this bugreport was not about log downloads but about incorrect diagnosis "old MAVLink version", and I was immediately offered a solution - say a message about the wrong version of the protocol only for the first HEARTBEAT packet, and after receiving the correct packet any failure of HEARTBEAT to consider as glitch and skip without interrupting the download.

In ArduCam, team also proved the impossibility of further expansion of the firmware capabilities, referring to hardware limitations, however see what this OSD can do now :) And amount of bugs that I fixed in CT...

Mission planner internally preforms these steps.

Yes but EVERYTHING works fine - parameters status etc - all except logs. This is likely to be due to a wrong logic somewhere in MP or in Ardupilot itself.

as for radio, this is most likely because rts/cts is not enable on the pixhawk side, and the buffer is flooding, causing corrupt packets.

The question - but how many modems you have seen with rts/cts support? The reality is that the vast majority of modems are working only via RX/TX so that this reality is necessary to consider the software and prevent buffer overflows manually.

it could be
sd card

...from which logs was successfully loaded via adapter?

usb cable

all 4 available?

pixhawk

all 2 available?

drivers

in Linux?

radio settings

Really? then you forgot to mention interference from aliens not otherwise :)

[night-ghost]

could you please try the latest MP 1.3.40. just wondering if its still an issue

At the evening

[meee1]

@night-ghost Thanks.
here is the change that made it into 1.3.40
a7d75fd

to get the false positive 3 items had to be met
if (buffer.Length == 11 && message.header == 'U' && message.msgid == 0)

the change above removed this code.

[night-ghost]

a small note about false-positives: UAVtalk stream at 57600 treated as 1-2 valid MAVlink packets per second with correct CRC! Of cause with garbage inside...

[qmayberry]

I did try it on 1.3.40 as stated above, but it didn't work either.

Anyway files dumped and I'll see what happens after the next flight.

Thanks for the assistance :)

[qmayberry]

Well certainly something fishy going on with the apm. It works OK, but is now just showing garbage when connecting via the terminal over wireless. I tried our other apm 2.6 which was fine and downloaded it's log without issue.

I will take the suspect one apart when I am back from hols to get access to the sd card and will reformat that then look at it again.

[rmackay9]

@qmayberry, i haven't really read the discussion above properly but I think the garbage you're seeing is mavlink messages. If you're using a pixhawk you should be able to download the logs via mavlink. Instructions are here: http://ardupilot.org/copter/docs/common-downloading-and-analyzing-data-logs-in-mission-planner.html

I could be off base.. but perhaps this is what you're looking for.

[qmayberry]

Thanks Randy, yes a bit off base unfortunately!

I agree the garbage looks like mavlink messages and probably is, but what was strange is even disconnecting the apm 2.6, and rebooting it, still gets garbage that it wasn't doing before. I changed to another apm 2.6 and it worked fine, so something is up with this one that needs investigating further in due course.

I have a 3DR pixhawk bought a few weeks ago just before it was discontinued apparently, so that will be the next machine.

[night-ghost]

Just tested version 1.3.40. Downloading logs via USB now works fine, downloading via radio still fails with timeout.