The qground control can't received full set. of parameters

Ground Control Software QGroundControl
1

Hi, I use ULRS( ultimate long rang system) to improve the rang of RC and telemetry signal. Everything works fine except the qground control which is the mobile version. the qground control can’t received full set. of parameters.i gues
s the lost rate too high, but it’s not too much noise in the flight field, becase the other guy using this system have the same problem. is this bug of qground control? can anyone resolve this problem?!
Screenshot_20191102_001355|690x332

qgroundcontrol
Screenshot_20191101_180820_org.mavlink.qgroundcontrol.jpg2244×1080 433 KB

hardware: F405 wing
software: arduplane3.9.9 chibios
mission planner works fine
QGC of mobile version works fine with 3DR telemetry

2

This is almost always a noisy connection. Look at the Mavlink page in settings. It tells you your packet loss rate.

3

I can connect with 3DR telemetry, but can’t download the full parameters with ULRS connection, so it may not be the noise problem, the other guy have the same problem. the mission can be connect and works perfect. I like to use mobile Qgc, as it is much convenient, hope someone can resolve this issue.

—Original—

4

Did you do this? What was the packet loss rate when connected via ULRS?

5

Thanks reply,i still think the problem is due to ULRS not compatible with Qgroundcontrol,in fact ULRS is much stable than telemetry, why is it have so high loss rate?i fly away about 2 km without seeing any rssi signal decrease, the signal connected to Qgc is much stronger than telemetry connection, the telemetry will lost connection just 500 M Away, but it seldom have can’t download full set of parameters problems.

—Original—

6

QGC doesn’t care or have much of an effect on anything it is connected to for telemetry. It just expects mavlink packets over the link. If you are getting “Communication Lost” when 500m+ away then that certainly indicates some sort of hardware setup problem with the device. This means that it no longer getting any mavlink messages from the vehicle. When you get the “Communication Lost” what does the mavlink packet loss rate say? Are you still getting any packets through the link but the loss rate goes up to 100% (that would indicate possible corruption of data over the link) or do you just completely stop getting any packets over the link.

7

ULRS is the same thing as “telemetry”. Different ULRS systems use different modulation schemes, but that doesn’t mean it is immune to external radio interference that will corrupt packets. QGroundControl is not the problem. If your ULRS has a spectrum analyzer built into its software look at the signal to noise ratio on the link. The signal can be strong, but if the noise on the link is just as strong you will get dropped packets. This is a common problem with some ULRS systems that use a lower frequency where the bandwidth per channel is less than a higher frequency radio.

8

I mean if i use 100mw telemetry module to transfer mavlink signal, QGC normally will disconnect around 500 meters, but the QGC seldom have the message of can’t retrieve download full parameters , that seems normal becase of this hardware limitations,.That is why I used ULRS to improve both mavlink signal and PWM signal, and QGC never disconnect in long range but just degrade even on ground, meaning we can keep using QGC but can’t change parameters. The QGC never have communication lost with vehicle by ULRS, but just have the message of can’t retrieve full parameters, while the QGC seldom have message of can’t retrieve full parameters by 100mw telemetry module, but it will lost communication about 500 meters away. all of the plane works fine except QGC ,we do you recommend for hardware setup ?Thanks.

—Original—

9

my friend used the same hardware have the same problem, he changes the a lot of channel according to spectrum analyzer , he also changes the place , but still have the issue, so we would Thank the problem is due to QGC, we may be wrong, but we don’t know how to find out the problems.

—Original—

10

I get the same issue with any ground station and ULRS. The solution is to tune the SRn_ parameters (n being the serial port on your flight controller you are connecting ULRS over) and this will then allow the parameters (and mission data) to download just fine. The problem is, when QGC connects over the same port, (as is my case, using the Mav2TP software on an ESP32 board to give a wifi connection to ULRS using UDP), I see the SR1_ values being reset to default values by the QGC software itself. I have no idea where QGC has these stream rate values configured - in Mission planner you can configure these on the Planner screen (under config/tuning). If anyone has any ideas where these values are configured in QGC, I’d be grateful to know.
For info, these are the rates I have been advised to use which work with ULRS and Dragonlink (switch the number to reflect your com port):
SERIAL1_PROTOCOL 1
SR1_EXT_STAT 1
SR1_EXTRA1 5
SR1_EXTRA2 5
SR1_EXTRA3 1
SR1_PARAMS 10
SR1_POSITION 3
SR1_RAW_CTRL 1
SR1_RAW_SENS 1
SR1_RC_CHAN 1

Edit: I found how to configure stream rates inside QGC - its only available on the daily build (dev) version presently, info here: https://docs.qgroundcontrol.com/en/releases/daily_build_new_features.html

Seems that today’s daily version is a bit buggy on the Mac though, as it crashes as parameter load reaches the end. Fortunately I have windows and Mission planner, and have set the Telemetry rates on the planner tab. Now I can connect MP over Mav2PT wemos lolin32 wifi UDP to ULRS Tx board, and even on Mavlink v2 it loads all parameters and the mission waypoints successfully when requested.

1 Like
11

Hi paul, Thanks for your reply, it’s been several days without any reply.

can you explain more detail about that The problem is, when QGC connects over the same port, (as is my case, using the Mav2TP software on an ESP32 board to give a wifi connection to ULRS using UDP)?

What’s Mav2TP software and ESP32 board？My understanding is that if you change it according to your parameters,

The QGC will works fine. but we can’t connect to QGC and ULRS control center on the same computer at the same time using UDP, That will lead to just reset the below list parameters to default.

SERIAL1_PROTOCOL 1
SR1_EXT_STAT 1
SR1_EXTRA1 5
SR1_EXTRA2 5
SR1_EXTRA3 1
SR1_PARAMS 10
SR1_POSITION 3
SR1_RAW_CTRL 1
SR1_RAW_SENS 1
SR1_RC_CHAN 1

Am I right?

—Original—

12

OK, so on the flight controller, we have the USB port, which is port 0 in Ardupilot, so as SERIAL0_PROTOCOL=1 as a general rule (meaning mavlink v1 on this port) then the streaming parameters affecting this USB port all start with SR0_ and however these parameters are configured will effect how frequently mavlink streams are sent over that USB port. In QGC though (also with Mission Planner), when you connect up on USB, QGC configures default values for most of the SR0_ parameters, so effecting how much data flows over the connection. Given that all you have in this example is a cable with a piece of ground station software connecting over that to the flight controller port, its good that QGC is allowed to configure those values so that it works optimally.

Now looking at a second example, as in my case, I have the Telemetry 1 port (serial1) connected via my ULRS Rx wirelesly to a serial port on the ULRS Tx (attached to the back of my Taranis). This data link, I use for 2 purposes - all made possible by running Mav2PT (Mavlink to Passthrough firmware) on an ESP32 board. The first use of this system is to convert the incoming mavlink messages into FrSky passthrough protocol, which then feeds into the smartport telemetry pin inside the Taranis’ module bay. This then feeds the required telemetry to the awesome Yaapu telemetry script which displays on the Taranis screen. The second thing the ESP32 boards does is to logon (using WiFi) to my moibile hotspot (known as workSTAtion mode). I then connect my Windows tablet (running either QGC or MP) to the same wifi hotspot - which allows the ground station software to connect seamlessly over wifi using a UDP connection to the esp32 board, and then over that slow ULRS wireless telemetry link to Ardupilot (on the serial1 port as I described). Now, given that we are using a considerably slower for this ULRS portion (when compared with a USB cable), if we want to get a reliable connection to QGC or MP, then we need to reduce the amount of data that our flight controller sends over that link. We would normally do this by configuring the SR1_ values manually to send data less frequently on each stream, but if we then connect QGC, this takes over those parameters and reconfigures them for much more frequent data streams - this is not good for our slow ULRS connection!

In QGC (release version) we have no control over the default stream rates it configures - it simply configures those values to the rates it wants to work with, but this is too fast for our slow ULRS link. Mission Planner however does allow you to configure default values for some of those telemetry streams (SR values) in its configuration. Now also we see this feature in the development version of QGC - so this will likely come to the release version before long. This is a good move by the QGC devs. In QGC, I also note that you can turn off automatic telemetry rate configuration, which is even better, as it then allows you to set SR values for each serial port individually in the ardupilot parameters, and then whichever port you connect QGC to, it will not override those pre-configured values, so life is good - we have faster values for our USB connection, and slower ones for our Serial1 connection (for ULRS)! I found testing this on today’s dev release causes QGC to crash in my Mac (not tested on Windows yet), so its clearly not there yet in QGC. Setting slower telemetry rates on Mission Planner however (on my windows tablet) using the values I showed in my previous post, works well with ULRS and Mission planner using the above described wifi connection.

I hope this all makes sense now?

If you want more info on the Mav2PT project then look here: https://www.rcgroups.com/forums/showthread.php?3089648-Mavlink-To-FrSky-Passthrough-Converter
and here: https://github.com/zs6buj/MavlinkToPassthru
And for the awesome yaapu telemetry script, look here: https://www.rcgroups.com/forums/showthread.php?3020527-An-Ardupilot-frsky-telemetry-LUA-script-for-the-Horus-X10-X12-and-Taranis-X9D-E-QX7
and here: https://github.com/yaapu/FrskyTelemetryScript

Ad for ULRS CC - I don’t personally use it aside from the initial configuration of the Tx/Rx etc.
Cheers, Paul

13

This seems to have popped recently. Windows is crashing the same way. Hopefully have something figure out soon.

14

Hi Paul,Thank you very much for your explanation.

I just change the SR_3 parameters to the same as yours, but unfortunately the QGC still have message of unable to retrieve full parameters.

My flight controller is F405 wing, my UART Order is that:

SERIAL0 = console = USB, baud rate 115200

SERIAL1 = GPS= USART1

SERIAL2 = empty, USART2 used for PPM Input ( PPM PIN connect to sbus pin in FC)

SERIAL3 = ULRS（TX,RX,G,+5v）= USART3 baud rate 19200

SERIAL4 = empty = UART4 baud rate 19200

SERIAL5 = empty= UART5

SERIAL6 = empty= USART6

first I set the baud rate of serial 3 to 19200, but can’t connect to MP,

then I check the Manual of ULRS, There’s note that serial0= UART1, serial1= UART2 etc, so I change baud rate of serial 4 to 19200, it can be connect to mp right now.

I have always been confused about this, for some FC may be like this, but my circuit board serial port has been defined from 0.

and there’s only SRn_parameters from SR0to SR3,I try to change the SR4_parameters as yours, but it doesn’t exist.

Do you have any other advice about this issue,Thank you very much.

—Original—

F405-WING_C1-978x1500.jpg
F405-WING_C1-978x1500.jpg978×1500 237 KB

15

I also have the F405 Wing board in 2 of my planes running Ardupilot 3.9 (, an fx61 and a Mini Talon, and ULRS in 3 planes, the third here is also an fx61 but with the Pixhawk Lite autopilot) . I am just looking at my Mini Talon saved parameters file, and from memory the connections to ports. As for the missing SR4_ values, yes that is a pain for me also. I get around this by connecting my devices differently.

SERIAL0_BAUD,115     (this is the USB port 115200 baud)
SERIAL0_PROTOCOL,2   (this is the USB port Mavlink v2)
SERIAL1_BAUD,19      (this is ULRS Rx 19200 baud tx1/rx1 pins)
SERIAL1_PROTOCOL,2   (this is ULRS Rx Mavlink v2)
SERIAL2_BAUD,57      (unused tx2/rx2 pins)
SERIAL2_PROTOCOL,1   (unused)
SERIAL3_BAUD,38      (GPS 38400 baud tx3/rx3 pins)
SERIAL3_PROTOCOL,5   (GPS protocol=5)
SERIAL4_BAUD,38      (this would be used for a 2nd GPS if I had one tx4/rx4 pins)
SERIAL4_PROTOCOL,5   (GPS protocol=5)
16

Note to devs: would you please consider improving the code to better handle mission transfer over slower telemetry connections? I am specifically referring to Ardupilot here (as I don’t use PX4 stack).

Testing mission transfers again this morning I am once again finding transfer failures over ULRS (19.2k baud) telemetry link. I am seeing “Mission transfer failed. Retry transfer. Error: Mission read failed, maximum retries exceeded.” I am hoping there might be a better way available to cope with failed transfers, and retries - aiming for a more reliable download in slow speed telemetry connections. Would you please be willing to look into a possible improvement to this?

Edit: I have just tested the same upload/download of a similar mission using Mission Planner, and I do not see these transfer failures in MP at all. I would rather use QGC on a smaller windows tablet though - its just nicer to use with a touch screen than MP.

Thanks, Paul

17

The last time I was using a ULRS link MP did not actually check to see if it downloaded all the parameters and would just continue without it. QGC does the same thing, except it pops up the warning and then continues without displaying the parameter list because it’s incomplete.

Uploading or downloading missions and params on low-bandwidth, slow-speed ULRS links is a problem though on Windows. We were using it on high-end 4G-LTE connected Android tablets and didn’t have any problems at all. We also used it on Linux laptops and didn’t have a problem. Only with Windows. But that was several versions ago.

18

QGC and MP differ on parameter download. I believe MP keeps on retrying forever until you give up and cancel. QGC will retry a specific parameter which is missing 5 times and after that give ups and reports the error.

I don’t know how MP does mission transfer. The way the protocol works for a download the gcs is in control. For an upload the vehicle side is in control. QGC uses the same 5 times retry approach on the loss of an individual mission item.

My take on this is that retrying forever is not necesarily a good thing. It glosses over the fact that you are connected to your vehicle over a very crappy link which is losing a lot of packets. QGC Setup/Mavlink page will show you packet loss %. So crappy that to me flying with that kind of a link could be dangerous. You might not be able to get the vehicle to repond to commands from the gcs such as RTL or things like that. QGC also for example will retry an RTL command 5 times, but give up after that.

19

I should have also mentioned that the “slowness” has nothing to do with it. It’s all about packet loss rate.

20

Most of the ULRS I’ve worked with are narrow channel low-bandwidth links to get the range. That’s how they do it - don’t push a fat signal and you get more range. Those types of links are subject to packet corruption and loss on data links. And it depends on the modulation scheme used too. Traditional MavLink radio links are Gaussian Frequency Shift Keyed. Some of the ULRS are using proprietary modulation schemes and they don’t have much thru-put on the link, which again results in lost packets.

Windows does not have a very robust networking serial/link stack either. Add all those issues up and you have the problem. The ground station can only parse what it gets. If it don’t get it, it can’t parse it.