RFD communication stuck on 70%

Hello Arducopter Forums!
I have a problem I straggle with for some time and I would like your help.
I’m using a drone with two communications connected to Telem1 and Telem2. My main transceiver (telem1) works with Ethernet and has a greater bandwidth. My second transceiver (telem2) is RFDX900. I’m using Pixhawk black, version 4.0.5. My Pix parameter “SYSID_MYGCS” = 255. I have a somewhat complex set up, with a Mavproxy at home that opens both my Mission Planner at the sometime. My main Com MP has a GCS ID of 255, and my RFD MP has a GCS ID of 254. I monitor the link quality in two places, the HUD link quality and link quality I see when I click on “Stats”. The HUD link quality and “Stats” of my Eth communication is perfect on a 100%. However, when I look at the MP of the RFD at the same places, the HUD shows 100% as well but int the “Stats” its constantly on 70% even though everything is on the ground with no interferences. Moreover, if I switch the GCS ID’s between my Coms (254<->255), the RFD goes up to 100% and my Eth Com goes down to about 70%-80%. I even tried to open only the RFD MP and then my “Stats” is on 100% and the second I open my Eth Com MP, it goes down to 70%. (when the RFD is on GCS 254 and my Eth Com is on 255). My main theory is that both the Mission Planners are sending Mavlink messages to each other though the MavProxy which is screwing up the packet loss statistics of My RFD MP. Any further ideas to why it’s happening.

Hi Georgie,

Sounds like thanks to your Mavproxy, the ongoing messages between both your MP’s is messing with their packet statistics calculations. The stats’ link quality shows all the data on the link, perhaps 30% of it is coming from your main MP and hence is counted as lost since it has a different target ID. I would try and lower the telemetry rate of your main com and see how it affects your secondary link quality.

Thank you, I will try it but even if this is the problem is there a way to fix it?

It’s most likely a matter of system configuration. Are your serial1&2_protocol parameters configured the same? When the secondary mp receives mavlink packets from your primary mp, it could easily reject them for that reason and yet still count them in their stats. Try configurating them the same.