How to Prepare for ARC Season: A 12-Week Training Overview

ARC qualifying flights typically happen between February and April. If your team forms in September, you have roughly 20 usable weeks before the launch window. Teams that plan those weeks intentionally almost always outperform teams that do not.

The following is a 12-week focused training arc that works whether you are coaching yourself, working with a mentor, or following a structured program. It assumes you have already read the contest brief and understand the basic structure of the American Rocketry Challenge. If you are still getting oriented, start with getting started with ARC before continuing here.

One upfront note on targets and deadlines: the official ARC rules define the target altitude, required flight duration window, payload specification, and qualifying timeline for each season. Those numbers change from year to year. This guide refers to "the target" deliberately rather than citing specific figures — always pull the current season's rulebook directly from the ARC website before you begin any design or simulation work. Build your team calendar around your competition's actual qualifying dates, not a generic estimate.

Weeks 1–3: Design and Simulation

Do not build anything yet.

The single most expensive mistake an ARC team makes is starting construction before the design is validated. A body tube you cut too short costs you a Saturday. A stability margin you did not check costs you a motor.

Goals for this phase:

• Read the current season's contest brief in full — every team member, not just the team lead. The scoring formula, payload requirements, and motor restrictions are details that every person on the team needs to understand before any decision gets made.
• Install OpenRocket and run your first simulation with a baseline design. Enter real component dimensions and materials from the start — do not use placeholder values and plan to fix them later.
• Build a simple CAD sketch or measured drawing so that tube lengths, nose cone geometry, and fin dimensions stay consistent between simulation and physical build. Dimensional drift between your sim and your rocket is one of the most common sources of altitude prediction error.
• Agree on a motor class. Check the contest brief for motor restrictions. Most teams in the competition fly F or G motors, but verify for your season.
• Produce at least three simulation variants — vary nose cone shape, fin planform, or fin size — and compare predicted apogee and total flight time across all three. Document every variant.

For a detailed walkthrough of how to build an accurate OpenRocket model and tune it toward the target, read simulate the design in OpenRocket. Pay particular attention to mass entry: forgetting paint, epoxy fillets, and egg packaging is the most common reason student simulations predict altitudes 50–100 feet higher than the rocket actually flies.

Common mistake: Teams pick a motor they like and design around it. Start from the target performance numbers instead — work backward to motor selection. The motor selection guide covers how to evaluate motors based on thrust profile and total impulse rather than name recognition.

End-of-phase check: You should have an OpenRocket model with accurate mass entries, a stability margin between 1.0 and 2.0 calibers, and a simulated apogee within a few percent of the target. If the model is still rough, spend another few sessions here rather than moving to build.

Weeks 4–6: First Build and Ground Tests

Now you build — but you document everything you do.

Goals for this phase:

• Build one complete rocket to your current best simulation design. Do not improvise dimensions; build exactly what the model says.
• Weigh every component before assembly and record it in a table alongside the mass you entered in OpenRocket. The gap between predicted and actual mass will identify where your simulation has drift.
• Assemble the altimeter bay carefully. Drill static ports at the correct size and placement before any paint or finishing work. Review the altimeter guide for port sizing and bay isolation requirements before you drill.
• Ground-test the recovery system before any flight. Pack the parachute, install a fresh motor with an ejection charge, and conduct a static ejection test (with the rocket secured, not in the air) to confirm the chute deploys cleanly. Do not assume it will work in the air because it looked fine on the bench.

What to document during this phase:

• Actual weight of each major assembly (nose cone section, body tube with electronics, fin can) versus the mass you modeled. Any component that differs from simulation by more than five grams needs to be corrected in the model before you fly.
• Any design changes made during assembly — tube lengths adjusted, fin attachment modified, egg compartment redesigned — and the reason for each change. These changes must be reflected back in your OpenRocket model before you run predictions for the test flight.
• Altimeter arming and data-download procedure, confirmed at least once before the first flight. On launch day is not the time to learn that your switch is inaccessible.

Recovery system decisions at this stage — parachute diameter, shroud line length, shock cord material and length — directly affect your flight duration score. The recovery systems guide covers how to size a parachute for a target descent rate and what failure modes to test for before the first flight.

Weeks 7–8: First Test Flights and Data Logging

The goal of these flights is not to hit the target. The goal is to produce reliable data that tells you how your rocket actually flies.

Goals for this phase:

• Fly your rocket with an altimeter on board. Every flight from here forward should produce a downloadable log.
• After each flight, record: date, motor lot number, total rocket mass (weighed at the field), apogee, time to apogee, total flight time, and ambient conditions (temperature and wind). Log these in a table that persists across the entire season.
• Compare logged apogee and total duration to your simulation predictions for that exact motor and mass combination.
• If your actual apogee differs from simulation by more than 50 feet, identify the cause before flying again. A 50-foot error at this stage suggests either a mass entry problem in the model, a static port problem in the altimeter installation, or a structural difference (a fin warped during epoxy cure, a parachute that partially deployed) that the simulation cannot predict.

Typical issues at this stage and what they indicate:

• Rocket is heavier than simulated → apogee is lower than predicted → audit your mass entries against the weighed airframe component by component.
• Chute is too large → total duration is too long, drift risk increases → reduce parachute diameter and rerun the simulation to confirm the expected descent time.
• Chute is too small or packed poorly → descent too fast, egg survival risk increases → enlarge the parachute or rework the packing procedure.
• Apogee prediction and measured apogee diverge consistently by the same percentage → your simulation's drag model needs calibration. In OpenRocket, increase the CD override by small increments until simulated and measured apogee match for a known flight. After that calibration, the model's predictions for adjusted designs will be much more reliable.

Do not change motor, mass, and recovery system simultaneously between flights. Change one variable at a time. Two flights with a single difference between them give you clean data. Two flights with three differences give you a guess.

Weeks 9–10: Revision and Second Build

Based on your first-flight data, you now have real numbers to work from rather than simulation estimates.

Goals for this phase:

• Update your OpenRocket model to match actual measured performance. If calibration flights showed the model was predicting 40 feet high consistently, that correction belongs in the model now, not as a mental adjustment at the field.
• Make targeted design changes. Move the simulated apogee toward the target by adjusting mass, parachute size, or motor. If the gap is small — within 20–30 feet — a mass adjustment (adding or removing ballast from the nose cone) is usually the cleanest lever.
• Build version 2, or modify version 1 if the changes are minor enough that the airframe can absorb them without compromising structural integrity. Rebuilding from scratch is worthwhile when a fundamental geometry change is needed. Rebuilding for a 15-gram mass change is not.
• Repeat the ground test of the recovery system if any part of the recovery bay was disassembled or modified.

Red flag: If you are still making major design changes at week 10 — changing body tube diameter, switching motor class, redesigning the egg compartment — your preparation schedule is slipping. The purpose of weeks 9–10 is refinement, not reinvention. A team that enters week 11 with a stable, characterized design has a meaningful advantage over a team that enters week 11 with an untested configuration.

Track your revision history. Every change to the design should have a line in your build log with a date and a reason. At qualifying, if a flight produces an unexpected result, that log is how you reconstruct what actually flew.

Weeks 11–12: Qualifying Prep Flights

These flights are simulations of the actual qualifying attempt, not further development.

Goals for this phase:

• Fly at least two official-format practice flights using the same rocket, the same motor lot, and the same recovery system configuration you intend to fly at qualifying. Same setup, no exceptions.
• Score each flight yourself using the contest brief's official scoring formula. Know what altitude and duration combination produces your best score — it is not always the flight that hits the altitude target most precisely if the duration also matters.
• After each flight, confirm that your setup is repeatable. A flight that scored well because of favorable wind is not reliable. A flight that scored well in calm conditions and then scored similarly in moderate wind is a setup you can trust.
• Identify your most consistent configuration. If version 2 consistently outperforms version 1 in your logged data, fly version 2. If both perform similarly, fly the one with more build hours on it — the one you understand better.

Pre-flight avionics checklist for qualifying prep flights:

• Altimeter battery is fresh — use a new battery for each qualifying-format flight, not a battery you used for three test flights.
• Altimeter is armed and the status indicator confirms it is active before the rocket leaves your hands.
• Static ports are open, unobstructed, and clean.
• Altimeter log from the previous flight has been downloaded and saved before it gets overwritten.
• Total rocket mass confirmed at the field against your last logged flight. If the mass has shifted by more than a few grams, find out why before launching.

Mental discipline at this stage: Qualifying is not a test flight. Do not try anything new at your qualifying launch — not a different packing method, not a different motor lot you have not flown, not a parachute you repaired the night before. The configuration that produced your best practice score is the configuration you fly.

---

Documentation and Competition Readiness

One element that separates teams in the middle of the standings from teams at the top is documentation. ARC does not explicitly score your build log, but documentation is how you reproduce a result, diagnose a failure at the field, and reset quickly if something goes wrong.

Your competition folder should contain, at minimum:

• A one-page flight summary: rocket name, motor designation, total mass as flown, simulated apogee, and the last three actual apogees with dates.
• A printed version of your recovery system packing procedure. Stress at the range causes mistakes; a checklist prevents them.
• The altimeter download procedure for your specific device. Alt reading retrieval is time-sensitive at some competitions.
• Your current OpenRocket file, either on a laptop or a USB drive you can access at the field.

If something goes wrong at qualifying — a shred, a hard landing, an altimeter that fails to arm — your documentation tells you what you flew and what changed. Teams that do not document their builds have to reconstruct from memory under pressure. Teams that do have a diagnostic record.

Where Coaching Fits In

Most teams benefit most from external review at two points: weeks 1–3, when the simulation and design are being established, and weeks 7–8, when real flight data first comes in and needs to be interpreted. These are the two stages where mistakes compound if they go unaddressed. A design with an unchecked mass error at week 3 carries that error through weeks 7, 9, and 11. A flight data interpretation error at week 7 produces the wrong design change at week 9.

If you want structured guidance on simulation setup, motor selection, altimeter interpretation, and competition-day preparation, explore our ARC coaching classes — SEALS Academy coaches ARC-track students competing in Orange County and across Southern California.