What SDL’s First Flight Data Taught Me

The first SDL flights were not about proving a finished avionics system. They were about getting real data from a rocket, validating the basic hardware and firmware, and finding out what needed to improve next.

At this stage, SDL was still closer to a debug data logger than a polished flight computer. That was intentional. The goal was to get the board into a real flight environment, collect enough useful data to understand what happened, and use that data to guide the next version of the system.

Even with early firmware and limited logging rates, the first flights were useful. The data showed broad flight behavior, captured short launch events, revealed where the logging system needed to improve, and confirmed that real flight data is much more valuable than only testing on the bench.

SDL did not need to be perfect on the first flight. It needed to teach me what to fix next.

The goal of the first flights

The first flight tests had a simple purpose: get real data.

Bench testing can verify that sensors initialize, packets are generated, storage works, and values change in the expected direction. That is important, but it cannot fully recreate what happens during an actual launch.

A rocket flight has vibration, acceleration, wind, launch rail interaction, pressure changes, ejection events, and landing impacts. Many of those events happen quickly, and some are hard to see from video alone.

The first SDL flights were meant to answer practical questions:

Does the board survive launch?
Do the sensors continue reporting during flight?
Does the barometer show a clear pressure change?
Do the IMUs capture launch and rotation events?
Is the logging format usable after the flight?
Is the sample rate high enough to understand the data?
What needs to change before the next version?

The flight data did not need to be perfect to be useful. It only needed to be real.

What version of SDL flew

The first flights used an early version of the SDL firmware. The board was already capable of reading multiple sensors and producing structured log packets, but the system was still intentionally simple.

At this stage, the focus was on debug data rather than polished state estimation. SDL was collecting raw or lightly processed sensor readings and formatting them into packets that could be inspected after the flight.

The major data sources included:

IMU data
High-G acceleration data
Barometer pressure data
Power/system data
Board status information

Depending on the specific test, the board could output data over USB during development and log flight data onboard for later analysis.

The important limitation was logging rate. Early flights were run at a relatively low rate compared to what the hardware should eventually support. That was useful for reducing complexity during initial testing, but it also meant that very fast events could be missed or only partially captured.

That limitation became one of the biggest lessons from the first flights.

Barometer data: seeing the flight profile

The barometer data was one of the clearest results from the early flights.

A barometer does not directly measure altitude. It measures air pressure. As the rocket climbs, the surrounding air pressure drops. As the rocket descends, pressure rises again. Because of that, the raw pressure trace looks like an inverted altitude curve.

A simplified flight profile looks like this:

Pad idle       - pressure mostly stable
Liftoff        - pressure begins dropping quickly
Boost/coast    - pressure continues dropping as altitude increases
Apogee         - pressure reaches its lowest point
Descent        - pressure rises as the rocket comes back down
Landing        - pressure returns near the starting value

Even with early logging, this showed that SDL could capture the broad shape of the flight.

The barometer data is especially useful because it gives a clean way to estimate major flight events. The lowest pressure point is related to apogee, and the overall pressure trend can show ascent and descent. With better filtering and higher-rate logging, that data can eventually feed flight-state detection.

The first flights confirmed that the pressure sensors were useful, but they also showed why filtering matters. Real pressure data is not a perfectly smooth altitude curve. It can include noise, airflow effects, vibration effects, and sampling limitations.

For a simple data logger, the raw trend is already useful. For a future flight computer, that same data needs to be filtered and combined with other sensors.

IMU data: motion that video alone can miss

The IMU data was one of the most interesting parts of the first flights because it showed motion that would be easy to miss from video alone.

A rocket can look like it launched normally, while the onboard motion data tells a more detailed story. Short events during launch, small rotations, rail or lug interaction, and wind alignment can all appear in the gyro data.

One of the useful observations was that the gyro captured early launch behavior. This included a short initial event near launch and rotation as the rocket left the guide rail and aligned with the wind.

That kind of data is important because it helps separate what the rocket looked like from what it actually experienced.

A simplified interpretation might look like this:

Before launch  - low motion, mostly sensor noise
Liftoff        - sudden motion spike
Rail departure - short rotation or disturbance
Boost          - more stable motion trend
Coast          - slower changing rotation
Ejection       - sharp transient event
Descent        - lower-frequency swinging or tumbling motion
Landing        - impact spike or sudden stop

At low sample rates, not every event is captured cleanly. Some spikes may be underestimated, and very short events may be missed entirely. But even limited data showed that the IMU was capturing useful information.

That matters for future development. If SDL is going to do event detection or state estimation later, the firmware needs to capture these fast motion events at a much higher rate.

Acceleration data: why sample rate matters

The first flights also made one thing very clear: rockets contain fast events.

Launch, motor thrust changes, rail departure, ejection, parachute deployment, and landing can all produce short-duration acceleration spikes. If the logger is running too slowly, it may only catch a rough outline of those events.

For example, a 5 Hz logging rate records one sample every 200 milliseconds. That may be enough to see broad ascent and descent trends, but it is not enough to reliably capture millisecond-scale transients.

That creates several possible problems:

Peak acceleration may be missed
Short launch events may be underestimated
Ejection spikes may be captured poorly
Landing impacts may appear inconsistent
Sensor disagreements become harder to interpret

This does not mean the early data was bad. It means the early data showed exactly why higher-rate logging matters.

The first flights proved that the system could capture useful flight data, but they also showed that SDL needs to move beyond low-rate debug logging. The IMUs and high-G accelerometer are only valuable if the firmware reads and logs them fast enough to catch the events they are meant to measure.

That lesson directly feeds into the next firmware priorities: faster sensor reads, better scheduling, and more deliberate separation between high-rate onboard logging and lower-rate telemetry.

Comparing sensors

One of the reasons SDL includes overlapping sensors is to make the data more trustworthy.

A single sensor can be useful, but multiple sensors allow comparison. If two sensors report similar motion during normal flight, that builds confidence. If one sensor reports something very different, that does not automatically mean it is wrong, but it does flag that the data needs more attention.

This is especially useful with IMUs and accelerometers. Standard IMUs are good for normal motion, while high-G accelerometers are useful for launch and impact events that might saturate lower-range sensors.

The first flight data showed why this matters. Some events are easy to miss at low sample rates, and different sensors may catch different parts of a short transient depending on timing, range, noise, and read order.

That makes sensor comparison more complicated, but also more valuable.

Useful questions to ask after each flight include:

Do the IMUs agree during low-motion periods?
Do they show similar timing for launch?
Does the high-G sensor capture events the regular IMUs miss?
Are any axes stuck, saturated, or reporting impossible values?
Do suspicious values persist or disappear after the event?
Is the difference caused by the sensor, the sample rate, or the event itself?

This is also where future sensor health checks become important. A sensor reporting a strange value for one or two samples during an impact may be believable. A sensor reporting a fixed high acceleration for many seconds would be suspicious.

The first flights helped define the kind of checks SDL should eventually perform automatically.

What the first flights showed about logging

The first flights proved that the logging system was useful, but they also exposed the next bottlenecks.

The most important takeaway was that the data path needs to support higher-rate logging without letting slow operations block the rest of the system.

SDL has several different outputs, but not all of them are equal:

Flash logging  - high-rate onboard storage
USB serial     - useful for development and debugging
SD card        - useful for post-flight file recovery
LoRa radio     - useful for live status and lower-rate telemetry

Trying to send every sample through every output at the same rate is not realistic. The radio is much slower than onboard flash. USB is useful when connected, but it should not be required. The SD card is convenient, but onboard flash is better suited as the primary flight log.

The first flight data reinforced the need for a clear data strategy:

High-rate flight data should be logged onboard
Lower-rate status can be sent over radio
USB should remain a development/debug tool
SD should be used mainly for post-flight export

That structure allows the board to collect detailed flight data without being limited by the slowest output path.

What changed after the first flights

The first flights were useful because they changed the development priorities.

Before flying, the main question was whether the board could collect meaningful data at all. After flying, the answer was yes, but with obvious areas to improve.

The main lessons were:

The barometer can capture the broad flight profile
The gyro can reveal launch behavior that video may miss
Low sample rates are not enough for fast flight events
Overlapping sensors are useful for validation
The logging format needs to stay easy to parse
Flash should remain the primary flight log
Telemetry should not replace onboard storage
Future firmware needs better scheduling and sensor timing

This is exactly what an early flight test should do. It should turn unknowns into engineering tasks.

The next steps are not random improvements. They come directly from the flight data.

Higher logging rates are needed because fast events were visible but under-sampled. A scheduler is needed because not every sensor or output should run at the same rate. Better analysis tools are needed because the logs are becoming more valuable. Sensor health checks are needed because real flight data can include suspicious values that bench tests may never reveal.

Why imperfect data is still valuable

It is easy to look at early flight data and focus on what it did not capture perfectly. The sample rate was limited. Some events were under-sampled. Some values need better filtering. Some parts of the firmware were still built for debugging rather than final operation.

But that does not make the data a failure.

Early flight data is valuable because it shows what the system actually experienced. Even imperfect data can reveal launch timing, pressure trends, rotation, sensor behavior, and logging limitations.

A clean simulation or bench test can only go so far. A real flight exposes the system to conditions that are difficult to recreate: vibration, acceleration, airflow, timing constraints, recovery events, and impacts.

The first SDL flights provided the kind of feedback that only real tests can provide.

They showed that the board worked well enough to be useful, and they showed what needs to improve before the next round of flights.

How the data guides the next version

The first flight data points directly toward the next version of SDL firmware.

The major development targets are:

Increase IMU logging rates
Optimize slow sensor reads
Separate high-rate and low-rate tasks
Improve flash logging performance
Keep radio telemetry lower-rate and status-focused
Add better sensor validation
Improve post-flight analysis scripts
Prepare the data path for filtering and state estimation

This is where SDL starts moving from a basic logger toward a more capable avionics platform.

The board already collects useful data. The next challenge is collecting it faster, organizing it better, and turning it into more meaningful flight information.

The first flights helped define that path.

Closing

SDL’s first flights were successful because they turned the project from a theoretical avionics board into a real flight-tested data logger.

The data was not perfect, but it was useful. The barometer showed the flight profile. The IMUs captured launch behavior. The acceleration data showed why higher sample rates matter. The logs gave enough information to understand what worked and what needs to improve.

Most importantly, the flights changed the project from guesswork into iteration.

SDL now has real flight data to build from. Every future improvement — faster logging, better scheduling, sensor validation, telemetry, filtering, and state estimation — can be guided by what the board actually measured in flight.