I am having the same problem - weird thing is I have 2 pixhawks, and only one has this issue of counting up “Got param index ###” all the way to 375. My other pixhawk connects in 2 seconds over mavlink. All radio settings are default.
SR*_PARAMS is set to 10 as well - this is very frustrating.
iskess, what radios are you running?
So through a bunch of systematic changes of radios on the ground and “in the air” I’ve found that replacing my rfd900u in the airplane sped up my param download significantly. I can even switch it back and observe the same slow download that takes 8-10mins.
It is still downloading some “empty” parameters but not nearly as many as before and they go faster now.
I’ll test flight today to make sure that performance is better, but RSSI at 2m range was 51% (fluctuating) and yesterday at the field even when the plane was overhead RSSI would be at 21%. Hoping for 100% during today’s testing 
Michael, one thing to be aware of… when Telemetry would disconnect during that flight yesterday, sometimes it would come back but most times it wouldn’t re-establish. Not really an MP issue but get this: When I’d hit the “disconnect” button to shut the voice warning up, the “are you sure you want to disconnect” window would pop up and instantly telemetry would re-establish. So, I’d select “No” in order to leave the link intact. I reproduced this probably 6-8 times, maybe more, during that same flight. If you’re interested, I can get you the mp log.
…Josh
[quote=“JoshW”]iskess, what radios are you running?
…Josh[/quote]
So far I have only been operating the Pixhawk on the bench with standard 3DR radios. I haven’t tried my RDF900 yet. My last few connects have been fast, this issue is intermittent which makes it especially frustrating.
I was wondering if there is a solution for this. My pixracer with 3DR radio was fine until two days back but now is very very slow, just like people have reported in this thread. Can it be h/w issue with pixracer. I replaced radio but no effect. Same radio works fine in other system. Is it possible the pixracer has gone bad? I am tempted to create a cable and try FTDI serial port at 57600 baud rate at the telemetry port. Just to make sure that h/w is fine.
I think it may be MP’s problem. sometimes it is very slow when connect to pixhawk through RFD900+ or Microhard. but there is no problem using Qgroundcontrol
Hello Sunit_Pal.
I had the same problem and found this post looking for a solution. In my case, disabling the ECC in both radios did the job. My 3DR radios came configured for 57600bps baudrate, 64000bps air speed, ECC activated, and no flow control. My theory is that this configuration shouldn’t work, because data rate is doubled by the ECC , up to 115200, which is higher than the air speed, so tha radios, under heavy data traffic (for example, downloading parameters), have no other option that discarding packets, as there is no flow control. In my case, many parameters were missing and mission planner request all of them again, which explain the long time it takes and the many “already got parameter #” messages in the deubg window of Mission Planner.
Lowering the baudrate to 19200, or increasing the air speed to 128kbps, with ECC enable, should also work, if I am correct.
Hope that helps,
Adolfo
Mr. Oborne,
Can you give us some guidance as to how to diagnose slow/faulty/repetitive param fetching from aircraft? I am currently running 19.2k baud from latest Arduplane to MP via Dragonlink and Bluetooth. Download times aren’t horrible, but I see lots of “already got param _____” in the status box. Wondering what I can do to make this more efficient.
Kelly
do you have flow control turned on? rts/cts?
I am told that RTS / CTS is not possible in the pathway between Pixhawk telemetry ports and Mission Planner (that pathway being Telem1 -> Dragonlink Rx -> Dragonlink Tx -> Bluetooth -> MP).
So without flow control, I understand I need to chose the update rates of the various Mavlink telemetry categories carefully, otherwise too much data too frequently will overrun buffers. Are there any tools, diagnostics, etc., that one can look at in the system to see if buffer overrun is happening? Are the link stats a worthwhile indicator of a well-tuned system? Are there error messages logged anywhere, or anything in the flash logs that can provide insight?
The Dragonlink recommended settings for refresh rates are as follows:
BRD_SER1_RTSCTS 0
SERIAL1_BAUD 19
SERIAL1_PROTOCOL 1
SR1_EXT_STAT 1
SR1_EXTRA1 5
SR1_EXTRA2 5
SR1_EXTRA3 1
SR1_PARAMS 8
SR1_POSITION 3
SR1_RAW_CTRL 1
SR1_RAW_SENS 1
SR1_RC_CHAN 0
In the “PLANNER” option, the “TELEMETRY RATES” are recommended as follows:
ALTITUDE = 5
POSITION = 3
MODE STATUS = 1
RC = 0
SENSOR = 1
The complete instructions for setting up Mavlink telemetry via Dragonlink are here. There are also details on Bluetooth configuration here.
There is also a new OSD by Dragonlink that many of us are using, listening to the Mavlink stream from Pixhawk’s other telem port, and since that dialogue is local to the aircraft, it can likely run at a substantially higher baud rate, and focus on higher refresh rates on position, altitude, etc.
Welcome any advice you have for how one can tune this system for optimal efficiency, fastest possible parameter downloads upon initial connection, etc.
Thanks,
Kelly
in the tools directory of pymavlink there is a tool that allows you to calculate the total data rate:
https://github.com/ArduPilot/pymavlink/blob/master/tools/mavtelemetry_datarates.py
Regarding RTS/CTS I found that I can activate it on the 3DR radio on the copter and on the copter itself, but not on the ground module. To be able to have it active on both sides I need to use mavproxy instead of mission planner:
https://github.com/ArduPilot/MissionPlanner/issues/1640
If you want to get this fixed, vote for it 