Servers by jDrones

Parameter download in Mission Planner is very slow or takes forever, but only sometimes with no reason

Hello to all,
I am writing this post to ask for your help regarding an issue with Mission Planner that I have noticed since I started using it some years ago and never solved: when I connect to the autopilot using a 433MHz 3DR telemetry radio, the download of parameters takes a variable time, ranging from about 30 seconds to forever. And this download time changes randomly. I think it is not an issue of a particular software or hardware configuration because I have noticed that with several versions of MP, several autopilots (one APM, two 3DR Pixhawks, two Pixhawk-lite-32), several versions of Arduplane and Arducopter, and four models of telemetry radios (from 3dr and clones). I am using now Mission Planner beta and Arduplane 3.8beta5.
I decided yesterday to look at the messages at the debug window, and noticed that there is like two phases in the parameter download procedure. In the first phase, there is a constant flow of messages saying “got param 1 of 819 … got param 2 of 819 … got param 819 of 819”. This is what I see in the debug window:

HUD 7 hz drawtime 0 gl True
INFO MissionPlanner.MAVLinkInterface - 70 got param 64 of 819 name: THR_SLEWRATE
INFO MissionPlanner.MAVLinkInterface - 208 got param 66 of 819 name: THR_SUPP_MAN
INFO MissionPlanner.MAVLinkInterface - 240 got param 68 of 819 name: THR_FAILSAFE
INFO MissionPlanner.MAVLinkInterface - 903 got param 71 of 819 name: THROTTLE_NUDGE
INFO MissionPlanner.MAVLinkInterface - 908 got param 73 of 819 name: FS_SHORT_TIMEOUT
bps 1020 loss 1 left 0 mem 29.3173828125 mav2 False sign False mav1 33 mav2 0 signed 0
HUD 16 hz drawtime 0 gl True
INFO MissionPlanner.MAVLinkInterface - 171 got param 76 of 819 name: FS_BATT_VOLTAGE
INFO MissionPlanner.MAVLinkInterface - 187 got param 78 of 819 name: FS_GCS_ENABL

However, some of 819 parameters are missing. Then, a second phase starts, and the missing parameter numbers are downloaded, BUT, they appear sparsely between A LOT of messages saying: “Already got 287 ‘COMPASS_OFS3_X’ … Already got 336 ‘SR0_PARAMS’ .” Some lines as an example:

INFO MissionPlanner.MAVLinkInterface - 21/06/2017 20:31:24 6 ArduPlane V3.8.0beta5 (708b483d)
INFO MissionPlanner.MAVLinkInterface - 21/06/2017 20:31:24 6 PX4: 8d505a02 NuttX: 1a99ba58
INFO MissionPlanner.MAVLinkInterface - 21/06/2017 20:31:24 6 PX4v2 0039002A 3034510D 36353832
INFO MissionPlanner.MAVLinkInterface - Already got 1 ‘SYSID_SW_TYPE’
INFO MissionPlanner.MAVLinkInterface - Already got 3 ‘SYSID_MYGCS’
INFO MissionPlanner.MAVLinkInterface - Already got 5 ‘SERIAL0_BAUD’
INFO MissionPlanner.MAVLinkInterface - Already got 7 ‘SERIAL1_PROTOCOL’
INFO MissionPlanner.MAVLinkInterface - Already got 9 ‘SERIAL2_PROTOCOL’
INFO MissionPlanner.MAVLinkInterface - Already got 11 ‘SERIAL3_PROTOCOL’
INFO MissionPlanner.MAVLinkInterface - Already got 13 ‘SERIAL4_PROTOCOL’
INFO MissionPlanner.MAVLinkInterface - Already got 15 ‘SERIAL5_PROTOCOL’
INFO MissionPlanner.MAVLinkInterface - Already got 17 ‘AUTOTUNE_LEVEL’
INFO MissionPlanner.MAVLinkInterface - Already got 19 ‘GCS_PID_MASK’
INFO MissionPlanner.MAVLinkInterface - Already got 21 ‘KFF_THR2PTCH’
INFO MissionPlanner.MAVLinkInterface - Already got 23 ‘GLIDE_SLOPE_MIN’
INFO MissionPlanner.MAVLinkInterface - Already got 25 ‘STICK_MIXING’
INFO MissionPlanner.MAVLinkInterface - Already got 27 ‘TKOFF_THR_MINSPD’
INFO MissionPlanner.MAVLinkInterface - Already got 29 ‘TKOFF_THR_DELAY’
INFO MissionPlanner.MAVLinkInterface - 358 got param 30 of 819 name: TKOFF_TDRAG_ELEV
INFO MissionPlanner.MAVLinkInterface - 374 got param 32 of 819 name: TKOFF_ROTATE_SPD
INFO MissionPlanner.MAVLinkInterface - Already got 34 ‘TKOFF_PLIM_SEC’

And I think that is the reason of the parameter download procedure to take so long, it depends on the number of missing parameters in the first phase. And that changes randomly every time I connect to the autopilot. If the missing parameters in the first phase are just a few, second phase ends shortly. But if many parameters in the first phase are missing, second phase could take literally forever.
I have found a thread in these forum suggesting that slow download is due to the configuration of the SR0_PARAMS parameter, which is the stream rate in hertzs for parameter download. I have then change SR1_PARAMS (SR1 because I am using the TELEM1 port) to 1Hz, 4Hz, 6Hz, 10Hz (default) and 20Hz, with no differences (only at 1Hz it seems it takes a bit longer).
This behavior does not happened when connecting using the USB, which takes a mere 4 seconds, despite the fact that baudrate is just double than radios. I cannot blame the radios because I have tried 4 of them and the STATS window shows a 100% quality connection, about 70 packets per second and no packet loss.
The complete debug window output is attached.parameter download already got - 21jun2017.txt (136.8 KB)

I will appreciate any help to deal with this issue.
Thanks in advance.

I have the same experience as you.
For me it is quicker to restart my fast laptop and Mission Planner than wait for the final download.
After the restart everything is quick again.
I don’t know why that is but that is a new phenomena for me. Started a few weeks ago.

It’s luck of the draw it seems. Wish I knew why lol, but you’re not alone.

Hello all,
I think I have found the problem, so I am replying to myself just for the record :slight_smile:
All the SIK radios I have bought (4 pairs, so far) have the same default configuration:

UART baudrate: 57600 bps
Air speed: 64 Kbps
No flow control ( no RTS/CTS))
ECC on

But according to the Ardupilot documentation at , ECC error correction uses a 12/24 code, so it is duplicating the data rate to 115200, which is lower than the air speed (data rate at the radio level), so under heavy data traffic, air speed could be not enough. But, as there is no flow control, the pixhawk has no way of knowing that and probably some of the packets with parameter values are just discarded by the radio.
That could explain why some (or many) of the parameter IDs are not received by MP in the “first phase” and requested again in the “second phase”, but pixhawk send all of them again somehow, which coudl explain all the “already got …” messages and the long time needed.

So, I just uncheked the “ECC” in the configuration window for both ratios and now all the parameters are downloaded quickly in the first place, and, as a colateral effect, I have noticed that telemetry update (attitude, sensor readings…) are MUCH faster now. It should be a 4Hz update as requested by MP in my case, a refresh rate that I have never seen until now, it was always more like 1Hz.

Disabling ECC hast the effect of a lower range, though, so I have tried to active flow control (RTS/CTS) on both radios and pixhawk, but I haven’t been able to make it work. I have also tried to lower the baudrate to 38400bps but it has no effect and parameters are downloaded slowly also (this configuration would require 76800bps air speed, still not enough with 64kbps).

So, disabling ECC solve this issue for me. Hope that helps.


Thank you!!! This fix solved a very annoying problem!!!

Servers by jDrones