Mission Design & Payload Thinking

Payload Data Generation

Estimate how much data a payload generates and what that means for onboard storage and downlink.

High school
Time estimate
25–30 min
Complexity
developing
Maturity
concept ready
Simulator readiness
partial
Software available now
Available now as teaching calculation — Mission Design data budget cards; not a camera sensor or onboard storage simulator.

Student flow

1) Pick payload settings

Resolution, frame count per orbit, contacts/day, minutes per contact, downlink rate.

2) Read MB and utilization

MB/orbit, MB/day, downlink capacity, utilization %, backlog Y/N.

3) Choose a mitigation

If backlog, write the mitigation that fits your mission story.

Evidence and self-check are local-only. Copy/export or screenshot if you want to share.

Learning outcomes

Student can estimate data volume from a payload and relate it to downlink constraints.

  • Estimate data volume in MB for a given image resolution and number of frames.
  • Explain what happens if data generation exceeds downlink capacity.
  • State what 'data utilization' means as a mission risk indicator.

Concept primer

Estimate how much data a payload generates and what that means for onboard storage and downlink.

View data budget section in Mission Design; compare data utilization across templates.

Work out data volume for three image resolutions and check against a contact window downlink capacity.

Interactive lab

Teaching-grade software activity slot — not a flight simulator or certified propagator.

Payload + downlink settings

Teaching model: ~95 min orbit (~15.2 orbits/day). RF link is not simulated.

Data budget summary

MB per orbit

60.0 MB

= 3 MB/image × 20 images/orbit

MB per day generated

909.5 MB

= 60.0 MB × 15.2 orbits/day

Daily downlink capacity

480.0 MB

= 2.0 Mbps × 8 min × 4 contacts ÷ 8

Utilization

189%

Backlog growing — generation > downlink.

Pick a mitigation

Local self-check

Assessment (practice only)

Use this as a self-check and discussion starter. It is local-only and not a grade.

Optional: attaches a local summary (completed / quick checks / checklist count).

Quick check

Multiple choice self-check

This is a local self-check to support discussion. It is not a grade.

Quick check: How do you estimate payload data volume per orbit in this lesson?

Quick check: In the toy data model, when does a backlog appear over time?

Discussion prompt

Short answer (local only)

Write notes for yourself or your group. Nothing is submitted.

Short answer: If your generation exceeds your downlink, name one mitigation and explain why it works.

Checklist

Local checklist self-check

Use this to verify you covered key ideas. Nothing is submitted.

Checklist: I can interpret data generation vs downlink

0 / 4 checked

Local summary

Assessment summary (practice only)

Completion

0 / 4 sections complete

Quick checks

0 / 2 correct

Shown only to support self-check.

Checklist

0 / 4 items checked

Reminder

Local-only practice summary. Not a grade and not submitted anywhere.

What this preview is / is not

Assessment engine v0 boundary note

  • Student view (local practice): use this as a self-check and discussion starter.
  • Local-only preview/practice: your answers are not submitted.
  • No backend, no accounts, no roster, and no LMS integration.
  • Not a grade. No credential or official scoring is implied.
  • Teacher visibility into student answers is not implemented in MVPF8.
  • Evidence runtime engine arrives in Phase 9 (not in this preview).

Capture

Evidence capture (local-only)

Capture what you did, what changed, what you observed, and how you explain it. This stays in your browser unless you copy/share it manually.

Selected inputs

  • Resolution tier: Medium (≈3 MB/image)
  • Images per orbit: 20
  • Contacts per day: 4
  • Minutes per contact: 8
  • Downlink rate (Mbps): 2.0

Generated outputs

  • Per-orbit data: 60.0 MB
  • Per-day generated: 909.5 MB
  • Per-day downlink capacity: 480.0 MB
  • Utilization: 189%
  • Status: deficit
  • Backlog growing?: Yes
  • Mitigation: Lower active duty per orbit (fewer images per orbit). — Reduces generated MB/day below downlink capacity.

Checklist

Evidence checklist

0/4 checked

Evidence artifact (local-only)

Payload Data Generation

Captured: 2026-05-16T07:38:32.759Z · Level: middle_school · Track: mission_design_payload

Summary

Copyable class summary

Copy a readable summary for class notes, or copy JSON for a structured record. Local-only: nothing is submitted.

Evidence artifact (v1)
Activity: Payload Data Generation
Track: mission_design_payload
Learner level: middle_school
Captured: 2026-05-16T07:38:32.759Z

Mission brief:
Estimate payload data volume per orbit/day and compare to total contact-window downlink capacity. Decide on one mitigation if generation exceeds capacity.

Selected inputs:
- Resolution tier: Medium (≈3 MB/image)
- Images per orbit: 20
- Contacts per day: 4
- Minutes per contact: 8
- Downlink rate (Mbps): 2.0

Generated outputs:
- Per-orbit data: 60.0 MB
- Per-day generated: 909.5 MB
- Per-day downlink capacity: 480.0 MB
- Utilization: 189%
- Status: deficit
- Backlog growing?: Yes
- Mitigation: Lower active duty per orbit (fewer images per orbit). — Reduces generated MB/day below downlink capacity.

Checklist:
- [ ] I estimated MB per orbit from rate × active time.
- [ ] I compared MB/day generated to MB/day downlinked over contact windows.
- [ ] I named one mitigation if generation > downlink.
- [ ] I used teaching estimates (no claim of camera-sensor or RF link-budget simulation).

Observations:
(not provided)

Reflection:
(not provided)

Model boundary note:
Local-only teaching model. Not a requirements database, not CAD, not automated mission verification. Mission Design Lab is a teaching estimate. Evidence is not submitted anywhere and is not a grade.

Policy reminder:
- Local-only capture. Not submitted anywhere. Not a grade.

Boundary note

Local-only teaching model. Not a requirements database, not CAD, not automated mission verification. Mission Design Lab is a teaching estimate. Evidence is not submitted anywhere and is not a grade.

Evidence capture

Expected outputs learners should be able to show after the lab (Phase 9 evidence engine preview available).

  • Rate × time calculation checked against template utilization
  • Student explains backlog if generation > downlink

Reflection

Calculate data volume from image resolution and frame rate; compare to downlink capacity.

Responses are not persisted in this preview unless a specific activity component adds storage later.

Assessment / quick check

What happens to onboard storage if you collect data faster than you can downlink? Name one mitigation.

Teacher notes

Use round numbers first (MB/orbit) before introducing Mbps; keep RF link abstract.

Teacher guide

Payload Data Generation

Use this block as facilitation guidance for the Mission Design / Payload mini-course. There is no roster, submission, or teacher visibility workflow in this phase — evidence is shared manually.

Facilitation moves

  • Use round numbers first (MB/orbit) before introducing Mbps; keep RF link abstract.
  • Compare two settings: lower duty vs higher duty — which kept utilization < 100%?
  • Bridge to Activity 2.4: ‘image volume per day’ becomes a measurable success criterion.

Misconceptions to watch for

  • If we generate more, we just store it — no problem.

    If average generation > average downlink, the queue grows. Eventually onboard storage fills and data must be dropped.

  • 1 byte = 1 bit.

    Mbps is megabits/sec; MB is megabytes. Convert (×1/8) before comparing to MB/day. Keep one unit per lesson.

Boundary reminder: Mission Design / Payload is a teaching model (not a requirements database, not CAD, not automated verification) and the experience is local-only (no accounts, no submissions, not a grade).

Next activity

Suggested progression from the mission learning path. Links avoid missing activity routes.