MP reporting false packet loss beyond v1.3.37?

Ground Control Software Mission Planner
1

Michael,

There are reports on the ULRS thread on RCG that MP is reporting false negatives in packet loss, in the latest version, but not in 1.3.37. The thread is here: http://www.rcgroups.com/forums/showthread.php?t=2037442&page=466#post35591391

I don’t yet have a running ULRS system to confirm, but wanted you to know about these reports sooner than later.

Kelly

2

could I get a tlog to verify?

3

I will ask one of the ULRS-based pilots to post a tlog demonstrating the problem.

Kelly

4

Hi Michael, I’m the developer of the ULRS (Ultimate LRS), which is a RC + telemetry system.

I won’t be able to post a tlog today, but I described the issue with a screenshot here : http://www.rcgroups.com/forums/showpost.php?p=34972220&postcount=5307

With exactly the same hardware setup,in MP 1.3.37 there are 0% lost packets, and in MP 1.3.38 there are about 10% lost packets. The test is done at very short range, and the transmitter didn’t beep so I’m sure there were no real lost packets in both cases.

I’ll post a tlog tomorrow.

5

does the ULRS inject any mavlink packets into the stream?

6

It doesn’t inject mavlink packets, it’s even mavlink agnostic and acts as a transparent serial link.
I’m using Mission Planner with ULRS since a long time, so I used it with many different versions of MP and it was always working fine until version 1.3.38.

I’ve made a test with ULRS + MP versions 1.3.37, 1.3.38 and 1.3.39. For about the same quantity of data (±120 kB) :

with MP 1.3.37 : 1 packet lost over 4027 packets
with MP 1.3.38 : 661 packets lost over 4178 packets
with MP 1.3.39 : 118 packets lost over 4355 packets

Also notice that the max time between packets is quite different :
with MP 1.3.37 : 94 ms
with MP 1.3.38 : 331 ms
with MP 1.3.39 : 438 ms

And the last difference is that the throughput was much higher (not lower) with 1.3.37, so this can’t be explained by an excessive throughput with 1.3.38 or 39.
with MP 1.3.37 : 1.57 kB/s (ULRS can handle up to the full 1920 bytes/s, APM is connected at 19200 bauds)
with MP 1.3.38 : 1.09 kB/s
with MP 1.3.39 : 1.06 kB/s

The 3 tlog files are attached and are approx the same size. The test was done successively on the 3 MP versions, without changing anything to the ULRS, hardware or configuration.

I’ve uploaded 3 screenshots of the stats for the 3 versions of MP, and the 3 corresponding tlogs. The versions are in the filenames.

tlogs and screenshots.zip (824.7 KB)

7

?Ben,

Excellent rigor on methodical demonstration of the apparent problem in 1.3.38 and beyond. Hopefully Michael can nail this one. ArduPlane + MP + ULRS is a kick*ss system!

Kelly

8

could you upload the rlogs as well.

tlogs are filtered data, ie valid packets.
rlogs are raw, and have even bad data.

9

Here are the corresponding rlogs as well : http://www.itluxembourg.lu/site/wp-content/uploads/2016/09/mission-planner-tlog-and-rlog.zip

10

MissionPlanner.log (54.2 KB)
from what I can see it is all packet corruption. either invalid packet headers, or failing crc.

11

I personally would try a usb to serial device on the same port the radio is using, to first confirm packet loss in a setup that you know should be 0.

I cant think of anything in MP that would cause packets to be miss read, the only other factor is perhaps the packet send from MP is causing some issues, but this again hasn’t changed. (to test this, connect, then pull the tx line from what mp sees, so long as you are connected it will keep working)

12

Hi, I tried with a very simple setup : FTDI cable connected directly to Pixhawk (without ULRS or other radio system).

First test : connect to Mission Planner 1.3.37 at 19200 bauds : never a single lost packet.
Second test : connect to Mission Planner 1.3.43 at 19200 bauds : lost packets, even at very low telemetry rates (1 per second for position, attitude etc = 660 bytes per second). About 10% of lost packets.

I didn’t do the test for all versions between 1.3.37 and 1.3.43 but from my other tests I think something changed starting at 1.3.38.

13

please provide both logs.
the fact you are directly connected makes it interesting. you never mention what was installed on the pixhawk however? I’m wondering if its a packet being dropped that has changed between the 2 versions, and failing a crc check because of it.

14

I’m happy to investigate, but do need logs.

15

Clipboard01.jpg1283×615 62.9 KB

Here’s a screenshot showing the exact Mission Planner and ArduPlane version. I’m using a Pixhawk but when I opened the issue I was using an APM with ArduPlane 3.4 and observed a similar issue.

Here are the 2 logs, Mission Planner is connected to the Pixhawk directly via an FTDI adapter at 19200 bauds (no radio, no USB). Telemetry rates are visible in the screenshot and below the capacity of the serial link.

logs.ZIP (500.9 KB)

16

you don’t happen to have the missionplanner.log file that goes with this do you? “c:\programdata\Mission Planner”

I have found something, but now trying to track it down.

17

Here’s the file for yesterday, just notice that I tried successively 1.3.37 and 1.3.43, so maybe this log contains data from both versions.

Mission Planner.zip (86.4 KB)

18

could you try the latest beta MP? I have made a change, but not sure if its the cause or not.

19

Hi Michael, I tried the latest beta MP (version is visible in the screenshot) and it works !

So the test was as above, FTDI connected directly between Pixhawk and computer at 19200 bauds. No more packet loss observed.

Thank you !

1 Like
20

thanks for the confirmation. its definitely not something I would have suspected.

2 Likes