Questions, answered.

TacLink C2 is a desktop ground control station for drone operations, built around modern multi-drone workflows. It sits between the consumer apps that ship with mass-market quadcopters and the heavyweight enterprise platforms built for government contracts. The platform runs on open flight protocols (MAVLink, ArduPilot, PX4) and is designed to work with the aircraft you already fly, not lock you into a specific vendor's hardware.

Independent pilots, small commercial teams, public safety drone units, search and rescue groups, and prosumer operators who have outgrown consumer apps but cannot justify the cost or complexity of enterprise platforms. The product is built for people running real flights, not for slide decks.

Mission Planner and QGroundControl are mature, capable, and free, and TacLink C2 owes them a real debt: they have carried the open-autopilot community for over a decade. The trade-off is that they were built by engineers for engineers, and the interfaces show their age. TacLink C2 is a modern rebuild aimed at multi-drone operations, fleet awareness, and a workflow that fits the way teams actually run flights today.

TacLink C2 will offer a free Community tier with the core single-aircraft workflow, plus paid tiers (Plus, Pro) that add multi-drone coordination, advanced mission tools, and team features. Pricing is published at /pricing. Pre-launch, all access is via the early-access waitlist.

Yes. The Community tier is free and covers the workflow most independent pilots need: single-aircraft connection, mission planning, telemetry, flight log recording. Paid tiers layer on top of it. Details at /pricing.

ArduPilot and PX4 are first-class. Anything that speaks MAVLink 2.0 over a standard transport is intended to work. The current tested matrix lives at /compatibility and is updated as new hardware is brought up.

DJI aircraft do not speak MAVLink natively, so direct telemetry and command integration is constrained by what DJI exposes through its SDKs. Where supported, that integration sits behind the same operations interface as MAVLink aircraft. Specifics for your model are tracked on /compatibility.

Yes. Pixhawk-class hardware running ArduPilot or PX4 is the canonical target, and the supported board list is on /compatibility. If a specific board you fly is not listed, that usually means it has not been brought up on the test bench yet, not that it will not work.

Any telemetry radio that carries MAVLink: SiK-firmware 915 MHz radios, RFD900-family long-range modules, Herelink, USB serial, and TCP/UDP over an IP network. Specific tested hardware is on /compatibility.

Windows and macOS are the primary desktop targets at launch. A Linux build is on the roadmap. Mobile platforms are deliberately out of scope for the desktop application; a view-only mobile companion is planned later.

Not as the operator's GCS. The application is a desktop tool, not an SBC payload. A Raspberry Pi makes more sense as a companion computer onboard the aircraft, where it complements rather than replaces the GCS.

Specifics will be published as the closed alpha stabilizes. The general target is any modern laptop from the last five years: a 64-bit OS, an integrated GPU capable of handling map tiles smoothly, and 8 GB of RAM as a baseline.

No. The platform is local-first by design: connect to the aircraft, plan a mission, fly, review logs, all without the cloud. An internet connection is needed for things like downloading map tiles in advance, fetching NOTAMs, and pulling LAANC authorizations.

Yes, where the connected hardware supports it. Message signing is enabled and configured per-link, and authenticates the command channel between the GCS and the aircraft against spoofing and replay.

On your machine. Flight logs, mission files, and telemetry archives live in a local data directory on the operator's computer. Cloud sync is not part of the default workflow and, when it ships, will be opt-in.

No flight paths, no mission content, and no location data leave your machine without explicit operator action. The default workflow is fully local. Future opt-in features (cloud backup, team sync) will be clearly labeled and documented in the Trust Center.

Yes. The application reads and writes the standard log formats for the autopilots it supports (.bin for ArduPilot, .ulg for PX4), and exports them to whatever directory you choose. Your flight history is yours.

Pre-launch builds collect no analytics. When opt-in diagnostic telemetry ships (anonymized crash reports, feature usage), it will be off by default, clearly disclosed, and documented in the Trust Center before it lands in any release.

Delete the local data directory. Because the platform is local-first, removing the application's storage on your machine removes your data. There is no server-side account state to clean up.

No. Missions and flight history live locally on your machine and are not transmitted to TacLink or to any third party.

TacLink C2's architecture is hardware-agnostic and has no dependency on hardware from restricted-country entities to function. Operators flying NDAA-aligned hardware can do so without workaround. The full position is documented at /trust/compliance.

Request early access from the waitlist on the homepage. Invitations go out in cohorts as the closed alpha matures into a wider beta. Telling us a little about your aircraft and use case in the waitlist form helps us prioritize.

Paid Plus and Pro tiers are sequenced after the closed alpha stabilizes. The current and planned timing lives on /roadmap; pricing is on /pricing.

Yes, that is the intent. Specific programs and eligibility are still being designed and will be announced once the paid tiers go live. If you are part of one of these groups, mention it on the waitlist form.

Yes. The product is built for commercial drone operations, and the paid tiers are designed around commercial workflows. Specific licensing terms will be published with the EULA before paid tiers go live.

Not currently. TacLink C2 is a closed-source commercial product. The platform sits on top of open standards (MAVLink, ArduPilot, PX4) and the team contributes back where it makes sense, but the application itself is not open source.

In order: physical link (radio paired, USB cable seated, IP route reachable), serial port permissions, baud rate matches the autopilot configuration, MAVLink stream rates not throttled by another connected GCS, and firewall rules for TCP/UDP transports. Most "will not connect" issues come down to two GCS instances fighting for the same port or a baud-rate mismatch.

Map tiles need an internet connection unless you have pre-cached the area. Check connectivity, check that the configured tile provider is reachable, and confirm the application has permission to write to its tile cache directory. For field operations without internet, pre-download tiles for the operating area before leaving connectivity.

Telemetry latency is almost always a link issue, not a software issue. Check radio signal strength, check for RF interference from nearby transmitters, check the configured stream rates on the autopilot (over-streaming saturates the link), and check that no second GCS is connected and pulling its own streams. Long-range work needs RFD-class hardware, not a stock SiK pair.

During the closed alpha, report bugs through the channel you were given when you joined the program. A public bug reporting flow will go live with the wider beta. In the meantime, contact us directly.

Known issues are listed at the bottom of each release entry on /changelog. Active work and what is queued up next live on /roadmap.