Arducopter doesnt check SYSID_THISMAV with "target_system" in mavlink packet telemetry

Hello,

I’m trying to establish connection through telemetry 868MHz (HM-TRP on Sik Radio) as a secondary (backup) channel, when first channel on WiFi will crash due to its short range). I’m using 3 drones at the same time, so I need connection with all drones in GCS with mavlink.
All drones has unique SYSID_THISMAV value (1,2,3) to allow send command into specific drone. Sadly, sending command packet with ID included in packet gives result that every drones received and executed command. For example having 3 drones on the ground connected I’d like to change flight mode through telemetry into one specific drone - it doesnt work. It works like broadcast, so I assume arducopter firmware (tested all versions 4.x.x) receive all packets and doesnt check if it message for him or for other drone without checking “target_system” in mavlink message.

By reducing air rate I’ve disabled all SRx params and I’m asking for statuses which I’m only interested in (I dont need all params) using request method.

This problem doesnt exist on WiFi connection, since all WiFi modules has unique UDP port (14550, 14551, 14552). The network layer on TCP/IP model sends packets into specific host (by unique UDP port). The 868MHz telemetry module doesnt have any OSI model in layer network to validate datagram like in WiFi connection. I think the arducopter firmware “believe” that all data received through telemetry is for execute without checking/comparing it’s SYSID_THISMAV with “target_system” in mavlink packet. Thats why all my drones changed flight mode at the same time by one command.

I’ve tested on SiK 2.2 multi point firmware radio with HM-TRP module and from this topic where friend @VRquaeler gives me his modified firmware 2.6.

for example, I send: set_mode: COMMAND_LONG {target_system : 1, target_component : 0, command : 176, confirmation : 0, param1 : 1, param2 : 0, param3 : 0, param4 : 0, param5 : 0, param6 : 0, param7 : 0}

RAW frame: fd1f00000bff004c00000000803f000000000000000000000000000000000000000000000000b0000198d2

Here is my setup parameters with firmware 2.2 2.6 from friend’s @VRquaeler firmware:

GCS:
NODEID: 0
NODEDESTINATION: 65535
NODECOUNT: 4

drone #1

SYSID_THISMAV: 1 //arducopter

NODEID: 1 //telemetry
NODECOUNT: 4
NODEDESTINATION: 0

drone #2

SYSID_THISMAV: 2 //arducopter

NODEID: 2 //telemetry
NODECOUNT: 4
NODEDESTINATION: 0

drone #3

SYSID_THISMAV: 3 //arducopter

NODEID: 3 //telemetry
NODECOUNT: 4
NODEDESTINATION: 0

Try QGroundControl to see if similar behavior also occurs, as it will come down to a misconfiguration of the drone. I tried it on the original software only change SYSID_THISMAV

I wants to use this module in a similar way and I am also struggling with its limitations