Adding different signals to transmit to impact UAVs in different ways. (RTL, Force Land etc)

[Crowdedlight]

adding different signals that let you force UAVs to land, return to operator, or the option to hack any drone. Also make the list of drones you can hack and exclude customizable by isKindOf rather than specific class

Suggested by hpt_leiche on steam workshop

[Crowdedlight]

Require to also do: add options to the spectrum device that allow you to specify the type of signal to broadcast. Ie. Force drone to land, return to operator, hack

[b-mayr-1984]

adding different signals that let you force UAVs to land, return to operator

My two cents on this (from the perspective of someone that works in the C-UAS industry).

C-UAS jammers don't have this fine control over the behaviour of the drone. When jamming the remote control link you force the drone to go into the internal failsafe mode. But the jammer has no influence on what the drone does when in failsafe mode.

Failsafe actions could be:

• Return to home location
• Land
• Hover at current position
• Continue mission autonomously

When jamming GPS you can prevent some of these actions from being possible.

But if you don't take full control of the drone you can not decide precisely what the drone will do.

So I don't recommend implementing this as suggested (from a realism point of view) where the type of jamming signal transmitted defines what happens. IMHO it would make more sense if the mission maker and zeus could define the failsafe action that a drone is programmed to perform when losing connection to the UAV operator (e.g. being jammed). This could be part of the Set Jammable module.

[Crowdedlight]

I agree with you. It's Important to note that the issues created here are generally feedback and brainstorming when I receive any, so it is stored in a central place. Then, if I get the time and find a fitting feature, I revisit it and scope out what would make sense to do with it. :) (Always glad for feedback on these, just can't promise I will get around to materialising these new features!)

This issue in particular is somewhere between what would make sense from a game/arcade standpoint and what is realism. And I think a good compromise could be to be able to set "failsafe" mods with the jammable module. Although any GPS jamming would typically get the typical drone to land where it is.

Thanks for typing the information out! :-) I also work as a drone engineer (R&D, civilian applications), so know a fair bit about the issues, attack vectors and communication. I have had some incidents with drones losing telemetry/communications due to noise and the like. ;-)

Typically as you say you would only gain that granular control over the drone if you breach the communication protocol and its signing/encryption, which is unlikely in most cases, even if we only talk civilian. (We don't have many Parrot like drones being sold anymore that is a flying open wifi-hotspot, with open telnet connections and executable shutdown.sh scripts :P )

For "game" purposes I have initially gone with GPS jamming not being a thing, as it would open up for also needing to influence other GPS devices in the area, which is not supported by ArmA. So going with unspecified "targeted" signals that overpower the enemy C2 link to the specific drone and disconnects its autonomy. And while not completely realistic I found it a good middle-ground to not make it overly complex, while keeping it useful and useable in the game.

As you suggest, I think an optional drop-down on "Jammable" module could be done to decide what happens when jammed. with default being the current behaviour, and potential options being RTH, Land, Loiter.