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

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

3 Likes

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

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?

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.

please provide a tlog of one of the bad connects

@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. :slight_smile:

1 Like

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 :slightly_smiling_face:

1 Like

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.

1 Like

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

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 :slightly_smiling_face:

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

2 Likes

ill add a few things from my side

  1. so by default you have 64Kbps over the air, now this is for both directions
  2. if you use ecc, this halves the available bandwidth
  3. 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

  1. disable ecc
  2. enable rts/cts on the air side, and use the correct cable that has rts/cts
  3. 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

1 Like

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 :slightly_smiling_face:

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

Servers by jDrones