Telem1 vs Telem2 getting messages from Pixhawk

We’ve been having an interesting issue when dealing with receiving MAVLink messages when using ArduPlane and a Pixhawk 2.1 Cube.

We have a device that we want to use essentially as an additional GCS. We want it to have the ability to receive all MAVLink messages and be able to send some MAVLink messages back as well. Typically we plug that device into the Telem2 port of the Pixhawk, but we do have some test devices plugged into Telem1. We are definitely observing a difference in functionality on the two different ports. Telem1 seems to receive MAVLink messages reliably and at the requested rate, but Telem2 does not always receive it reliably. Sometimes we do not receive messages at all on Telem2, and when we do, it usually does not come in at as high of a rate at Telem1. We have seen cases where even heartbeats are not received. We have tested multiple autopilot versions of both ArduCopter and ArduPlane. ArduCopter seems to generally work reliably, while ArduPlane gets different results. To experiment further, we plugged in two of our devices at the same time, one on Telem1 and one on Telem2. We flashed the Pixhawk with ArduPlane4. When one device sent a message to set the interval of the MAVLink messages, the other device would stop receiving messages entirely, and vice versa. This situation was not repeatable with ArduCopter.

In order to try to troubleshoot this as much as possible, we began diving further into the ArduPilot MAVLink documentation. The documentation says that messages sent to the autopilot should have the target system set to the system the autopilot is on, which typically defaults to 1. It does not actually say that the target component id should be set to the autopilot component id, but component id for the autopilot seems to usually default to one. It goes on to say the system id for the originating component messages should be set to the same as the autopilot but use a different component id, and that a value of 0 for the target system or component id is considered a broadcast id. Currently we set the target system and component id to 0, but have started experimenting with setting the target component and system ids to the same as the autopilots and the originating component id to 101 as a unique component id, and the originating system id as the same at the autopilot’s system id… It also says that “ground stations will not send command packets to a non-broadcast destination (sysid/compid combination) until they have received at least one package from that destination over the link. This is essential to prevent a flight controller from acting on a message that is not meant for it. For example, a PARAM_SET cannot be sent to a specific <sysid/compid> combination until the GCS has seen a packet from that <sysid/compid> combination on the link.” Because of this, we have also added sending heartbeats from our device with the more “correct” message ids, but this did not seem to affect any behavior.

Basically we are running out of ideas and are hoping the community here can give us some ideas on what could be the issue. We reached out the community as well, and a member there recommended we post here as well and tag @tridge as well. Thanks everyone!


what type of device are you using

We are experiencing what might be the same problem. We are using Pixhawk 2.1 (Black cube), firmware 4.0.2. For communication we use a Raspberry Pi with Mavlink Router on Telem1 and an mRobotics 433 MHz radio on Telem2. Both seem to work flawlessly while connecting only one, but together, the 433-radio on Telem2 is extremely unreliable to the point we cannot use it. We did not experience this problem with firmware version 3.9.11, and we have successfully tested after reverting to it from v4.

We have now tested with 4.0.4beta, and it does not seem to solve the problem for us.

Hi, we have a very strange behaviour with Telem1 and Telem2 on a PixRacer R15 together with a Wifi Telem. See: Pixracer ESP8266 arduplane log download timeout . The Wifi Telem on Serial5 only works when we switch off Telem2.

I tested 4.1 beta, and it seems to work nicely there, so I expect it to be fixed on a future release.

1 Like

I am having same problem here. What are the major differences to take into account when reverting from v4? Are there something would fail in 3.9.11 which is implemented differently?

I’m having problems with artificial horizons on OSDs on Telem2 While using Telem1 for GCS telemetry modem. I have tried MinimOSD (which used to work fine, possibly on earlier Arduplane version) and Pitlab OSD. I’m experiencing this issue with both Cube Black and PixHawk4 Mini with arduplane 4.0.5. I wonder if this is related?