We still remember our first day out in the field. The aircraft is sitting on the bench, props off, we send an arm command from the transmitter, and nothing happens. Motors silent, LED blinking orange, no feedback on the transmitter. The only information we have: "it doesn't work."

We opened the laptop, plugged the telemetry radio into USB, and a single line appeared in the bottom corner of the screen: PreArm: Compass not calibrated. A five-second fix. But what got us to that five seconds wasn't the aircraft — it was the software on the ground.

A Ground Control Station (GCS) is the software we run on the ground to plan, monitor and configure the vehicle. It is the window into the flight controller's (FC) brain. In this post we cover what a GCS actually does, how Mission Planner and QGroundControl differ, MAVLink's role in that relationship, and why log analysis is non-negotiable.

What does a GCS actually do?

Treating a GCS as "the tool you use to drop waypoints on a map" is a common mistake. Mission planning is only one item on the list:

The ArduPilot documentation lists Mission Planner's functions under these headings: firmware flashing, setup and tuning, autonomous mission planning, log download and analysis, and hardware-in-the-loop (HIL) simulation with a PC flight simulator. QGroundControl is split into a similar set of five areas: Plan, Setup, Fly, Analyze, and advanced tools.

In our SUAS 2026 workflow, the GCS is the one interface shared between simulation and the field. The software we connect to the simulated vehicle in our SITL + Gazebo setup is the same software we connect to the real Pixhawk out in the field. That closes a lot of the distance between "it worked in simulation" and "it didn't work in the field."

MAVLink: the shared language between GCS and FC

The GCS and the flight controller talk to each other over MAVLink (Micro Air Vehicle Link). By its official definition, MAVLink is a "very lightweight" messaging protocol designed for communicating with drones and between drone components. It is optimized for narrow-bandwidth, noisy channels.

Why does being lightweight matter? Because framing overhead eats straight into your telemetry budget. According to the official docs, MAVLink 1 adds 8 bytes of overhead per packet and MAVLink 2 adds 12 (MAVLink 2 is worth the difference, because it is more secure and more extensible).

Here is a rough way to work out how many messages your telemetry link can carry:

1. Effective byte rate through the serial port (8N1 framing: 10 bits per byte) — byte_rate = baud / 10

2. Total size of a single MAVLink 2 message — message_size = payload_bytes + 12

3. Theoretical upper bound — message_rate = byte_rate / message_size

Example: with a classic 57600 baud telemetry radio and the ATTITUDE message (28-byte payload):

byte_rate = 57600 / 10 = 5760 bytes/s

message_size = 28 + 12 = 40 bytes

message_rate = 5760 / 40 = 144 messages/s (theoretical ceiling)

That is a ceiling, not a promise. In reality you aren't sending one stream but dozens at the same time (ATTITUDE, GLOBAL_POSITION_INT, SYS_STATUS, RC_CHANNELS...). On top of that, on SiK-class radios the air data rate is a parameter independent of the serial port baud, and error correction adds overhead of its own; check your radio's datasheet for real throughput. In practice we manage the budget by hand in ArduPilot, throttling each stream's rate in Hz with the SRn_* parameters.

The link itself is defined by parameters too:

The same protocol applies on the companion computer side — the link from the Jetson to the FC speaks MAVLink as well. We wrote that up in detail in our companion computer and MAVLink guide.

Mission Planner vs. QGroundControl

Both are open source (GPLv3) and both work with ArduPilot. The difference is philosophical.

When Mission Planner? If you're on ArduPilot, if you're going to dig deep into parameters, if you're in a tuning loop, and if you have a Windows machine on the bench. For SUAS 2026 we run Mission Planner as our primary station, and the reason is raw parameter access plus the fact that most of the ArduPilot documentation is written directly against Mission Planner's screens.

When QGroundControl? If anyone on the team is on macOS or Linux, if you also work with PX4, if you'll be operating from a tablet in the field, or if you're handing first-time setup to someone who just joined the team. Its interface is far less intimidating.

Using both together is fine too — parameters live on the FC, not in the GCS. A setting you change in one program shows up in the other.

Log analysis: tlog vs. dataflash

This is the least used and most valuable side of a GCS. There are two kinds of log, and they are not the same thing:

Post-crash root cause analysis almost always comes out of the dataflash log. The tlog tells the operator's side of the story: which command went out at which moment, and when the link dropped.

The ArduPilot parameters that govern logging:

LOG_DISARMED is a lifesaver when you're diagnosing a vehicle that won't arm — because the default behavior starts the log at the first arm, and a flight that never arms leaves no record at all. Note: a value of 3 on this parameter also deletes the logs in which the vehicle never reached the armed state; use it knowing what you're doing.

Our rule is simple: download the dataflash log after every flight, even when the flight went well. SD cards fill up, log numbers collide, and two weeks later when you say "there was something odd on that flight," the data is gone.

Alternatives

APM Planner 2.0 — a lighter desktop option, GPLv3 licensed, that runs on Windows, macOS and Linux. It doesn't go as deep as Mission Planner, but running natively on Linux is an advantage.

MAVProxy — a command-line GCS. It runs on Linux and is extensible in Python; the ArduPilot documentation recommends it specifically for "developers writing code." Its real strength is that it can duplicate MAVLink traffic: it fans the stream arriving on a single serial port out to multiple clients.

# Connect to the FC, open the console and the map, and also forward the stream over UDP
mavproxy.py --master=/dev/ttyACM0,115200 \
            --out=udp:192.168.1.1:14550 \
            --console --map

# Connect to the FC, open the console and the map, and also forward the stream over UDP
mavproxy.py --master=/dev/ttyACM0,115200 \
            --out=udp:192.168.1.1:14550 \
            --console --map

That --out pattern is critical for us: it's how we feed the same MAVLink stream to Mission Planner and to our own Python script at the same time. It's also how we run things on the companion computer we described in our Jetson setup guide.

Common pitfalls

• Messing with parameters without backing them up. Save the parameters to a file before you change anything. Forgetting which value you changed during tuning means starting over from scratch.

• Hanging two devices off the same serial port. The telemetry radio and the companion computer can't share one SERIALn. Separate port, separate SERIALn_PROTOCOL, separate baud.

• Mistaking a baud mismatch for a "bad cable." If the GCS won't connect, check the baud rate first; both ends of the radio pair have to match.

• Cranking the telemetry stream rates all the way up. Raising the SRn_* values makes the HUD look smooth, but it saturates the link, and at the critical moment your command ends up waiting in line.

• Calibrating the compass indoors. A metal bench, a power supply and a laptop distort the magnetic field and ruin the result. Do it outdoors, rotating the vehicle in your hands.

• Running calibration and motor tests with the props on. ESC calibration and the GCS motor test really do spin the motors. Take the props off. A spinning prop will take a finger off; that's not hyperbole, it happens in the field. Along the same lines, watch your power sequencing when you plug into the FC's USB with the LiPo connected.

• Updating firmware in the field. A new release can reset or rename some parameters. Updates happen on the bench, followed by a full ground test.

Practical summary

1. Pick one GCS and get the whole team fluent in it. Mission Planner if you're on ArduPilot and want deep parameter access; QGroundControl if you need cross-platform or tablet support.

2. Use SERIALn_PROTOCOL = 2 (MAVLink 2), and manage your telemetry budget deliberately with the SRn_* stream rates.

3. Download the dataflash log after every flight — the tlog tells you about the operator, the .bin tells you about the vehicle; the root cause is almost always in the .bin.

4. Back up your parameters and record every configuration change with its date.

5. Take the props off for every motor/ESC test. A command issued from the GCS spins a real motor.