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.
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.
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!
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)
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.
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.
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.