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

Adolfo_Cobo · June 22, 2017, 3:24pm

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 1.3.48.3 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.
Adolfo.

FRED_GOEDDERT · June 22, 2017, 10:46pm

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.

X1Aero · June 23, 2017, 5:35am

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

Adolfo_Cobo · June 28, 2017, 8:13pm

Hello all,
I think I have found the problem, so I am replying to myself just for the record
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 http://ardupilot.org/copter/docs/common-sik-telemetry-radio.html , 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.
Regards!
Adolfo.

schutes · January 12, 2020, 4:48pm

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

Steviegeek · June 8, 2021, 6:28pm

My ECC is disabled, was by default, still terribly slow to connect by UMT (3DR copy) 433MHz Telemetry radio.
Should there be some specific SR(n) settings?

seattleiteFPV · June 10, 2021, 5:07am

I have the same issue with the latest Mission Planner and Copter 4.1.0-beta. Sometimes the connection is reasonably quick (though never very quick), but other times MP just loops endlessly like this, for hundreds of parameters:

already_got_param

Why am I seeing “already got param XYZ” if the param is already present? Why is time spent needlessly processing these params, when the initialization could simply focus on the missing params instead? Could someone please explain to a newbie?

This latest attempt to connect is over USB, and the loading loop above has been going on for 10 minutes. This seems crazy to me.

Michael_Oborne · June 10, 2021, 6:13am

please provide a tlog of one of the bad connects

seattleiteFPV · June 10, 2021, 8:29pm

@Michael_Oborne Thanks, I have sent you a private msg with the most likely tlog (based on the time stamp and size). Please let me know if there’s anything else that I can help with to get to the bottom of these endless connecting attempts.

Steviegeek · June 16, 2021, 12:47pm

I’ve partly resolved my speed issues. I had the port set for MAVLINK2, since read that these 3DR type radios can’t handle MAVLINK2 very well so changed to MAVLINK1 and now getting better success, it connects most times OK now
Steve

GregCovey · June 16, 2021, 1:01pm

I have used these settings successfully for years. They were originally optimized for the APM Antenna Tracker communication between the tracker, plane, and ground control station.

Steviegeek · June 25, 2021, 4:49pm

Thank you, I’m trying these in the morning at the club field.

But I really meant the SR values in MP for each UART port, sorry if I didn’t make myself clear…
I think they are called Mavlink streaming values

Cheers
Steve

GregCovey · June 25, 2021, 6:06pm

Got ya. Here is what the serial ports are set to on the AAT. Both SR1 and SR2 are telemetry ports on the ATT. I believe that they are defaults when this older firmware was used.

SERIAL1_BAUD,57
SERIAL1_OPTIONS,0
SERIAL1_PROTOCOL,1
SERIAL2_BAUD,57
SERIAL2_OPTIONS,0
SERIAL2_PROTOCOL,1

SR1_EXT_STAT,2
SR1_EXTRA1,4
SR1_EXTRA2,4
SR1_EXTRA3,2
SR1_PARAMS,10
SR1_POSITION,2
SR1_RAW_CTRL,1
SR1_RAW_SENS,2
SR1_RC_CHAN,2
SR2_EXT_STAT,2
SR2_EXTRA1,4
SR2_EXTRA2,4
SR2_EXTRA3,2
SR2_PARAMS,10
SR2_POSITION,2
SR2_RAW_CTRL,1
SR2_RAW_SENS,2
SR2_RC_CHAN,2

For one of my VTOLs using newer firmware, see below. It always seemed to be the SiK radios settings that were the culprit for slow or resending telemetry.

SERIAL1_BAUD,57
SERIAL1_OPTIONS,0
SERIAL1_PROTOCOL,1
SERIAL2_BAUD,57
SERIAL2_OPTIONS,0
SERIAL2_PROTOCOL,1

SR1_ADSB,5
SR1_EXT_STAT,2
SR1_EXTRA1,4
SR1_EXTRA2,4
SR1_EXTRA3,2
SR1_PARAMS,10
SR1_POSITION,2
SR1_RAW_CTRL,1
SR1_RAW_SENS,2
SR1_RC_CHAN,2
SR2_ADSB,5
SR2_EXT_STAT,2
SR2_EXTRA1,4
SR2_EXTRA2,4
SR2_EXTRA3,2
SR2_PARAMS,10
SR2_POSITION,2
SR2_RAW_CTRL,1
SR2_RAW_SENS,1
SR2_RC_CHAN,1

Michael_Oborne · July 12, 2021, 12:34pm

ill add a few things from my side

so by default you have 64Kbps over the air, now this is for both directions
if you use ecc, this halves the available bandwidth
if you dont use rts/cts on the air side, this can cause buffer issues and corrupt packets, as they need to be dropped to keep up. i say air side because the ground side doesn’t normally send a lot of data

so

disable ecc
enable rts/cts on the air side, and use the correct cable that has rts/cts
in MP settings screen change the stream rates down

when i look at the original posters log i see this
INFO MissionPlanner.MAVLinkInterface - 642 got param 0 of 819 name: FORMAT_VERSION
INFO MissionPlanner.MAVLinkInterface - 677 got param 3 of 819 name: SYSID_MYGCS
INFO MissionPlanner.MAVLinkInterface - 977 got param 6 of 819 name: SERIAL0_PROTOCOL
bps 1535 loss 0 left 33 mem 29.046875 mav2 False sign False mav1 47 mav2 0 signed 0
INFO MissionPlanner.MAVLinkInterface - 24 got param 9 of 819 name: SERIAL2_PROTOCOL
HUD 8 hz drawtime 0 gl True
INFO MissionPlanner.MAVLinkInterface - 145 got param 11 of 819 name: SERIAL3_PROTOCOL
INFO MissionPlanner.MAVLinkInterface - 178 got param 13 of 819 name: SERIAL4_PROTOCOL
INFO MissionPlanner.MAVLinkInterface - 709 got param 15 of 819 name: SERIAL5_PROTOCOL

as you can see we are skipping numbers 0,3,6,9,11,13,15 - so we are dropping every 2nd packet or there abouts. and given i dont see any packet loss notifications, this is a result of no rts/cts on the air side, and/or stream rates SR1_PARAMS being too high and flooding the link

Steviegeek · July 29, 2021, 7:27am

Thanks Michael
That’s very useful, looks like I need to change my airside controller, I don’t believe the Chibios boards i.e. Matek F405-WING have RTS/CTS facility.
Steve

PS, what do you suggest as a ‘starting value’ for SR1 ?

FIT-RS · March 31, 2022, 3:39pm

Greetings All, we are having the same problem with the slow download of parameters, and the repeating message of “already got param xxxxx”. Connecting takes up to 10 min. We are using ArduRover firmware V4.1.0 and Mission Planner 1.3.77. The telemetry radios are RFD900x radios with multipoint firmware V2.9. We are testing a multipoint setup, but right now we are only connecting one USV (boat) to the ground station. I have tried changing settings per the discussion in this thread, but to no avail. These are the settings I have installed on the RFD radios:

	Master (node 1) DELL Rugged	(node2) RED
FORMAT	53	53
SERIAL_SPEED	57	57
AIR_SPEED	64	64
NETID	0	0
TXPOWER	30	30
ECC	0	0
RXFRAME	1	1
OPPRESEND	0	0
MIN_FREQ	922000	922000
MAX_FREQ	928000	928000
NUM_CHANNELS	21	21
DUITY_CYCLE	100	100
LBT_RSSI	0	0
RTSCTS	1	1
MAX_WINDOW	80	80
ENCRYPTION LEVEL	0	0
RESERVED	0	0
RESERVED	0	0
RESERVED	0	0
RESERVED	0	0
ANT_MODE	0	0
GPO1_3STATLED	0	0
RESERVED	0	0
RATE/FREQBAND	0	0
NODEID	1	2
NODEDESTINATION	255	255
NETCOUNT	1	1
SERBREAKMS10	0	0
RESERVED	0	0
MAX_PACKET	380	380
BUFFSIZE	631	631
TARGET_RSSI	0	0
HYSTERSIS_Rssi	5	5

I can do a screenshot from RFD tools if that would be easier to view. ECC is disabled, rts/cts is enabled on all “rover” radios, and base radio. The SR1_PARAMS is currently set to 10. Here is an image of the Planner window. How do the Telemetry rates look for a surface boat?

Do you think it is a RFD radio setting or a Ardupilot parameter setting?
Tlog from today is 1.4 MB I’ll email it or PM it as it is too large to attach to this message.

FIT-RS · April 19, 2022, 7:11pm

crickets…chirp chirp

xfacta · April 21, 2022, 3:27am

Can you show your serial settings, SERIALx
You should have something like
SERIAL1_BAUD,57
SERIAL1_OPTIONS,0
SERIAL1_PROTOCOL,2
and
BRD_SER1_RTSCTS,0 for off, 1 for on and 2 for Auto.
I tend to set this specifically to 0 or 1 rather than let Auto decide for itself.

RTS/CTS can be a bit of a pain unless you really specifically need to use it.

FIT-RS · April 21, 2022, 3:23pm

Greetings Shawn, thanks for the reply! Here is a screenshot of my Serial 1 settings. Please note I am using a baud rate as recommended by RFD in their Multipoint manual.

Any ideas? Even when connecting to a single node it takes forever to connect. If I swap RFD radios to a point to point set, it takes less than a minute to connect and download all parameters even with the standard 57600 baud rate.

FIT-RS · April 21, 2022, 4:20pm

Here is the BRD_SER1_RTSCTS output: