Lesson 4 of 4 · Turn a camera demonstration into a repeatable result
Turn a camera demonstration into a repeatable result
6 minute lesson · 3 checks along the way
Your goal for this lessonRelate sampling to task scale and distinguish received data from a validated, reproducible camera result.
In this lesson 3 sections · 3 checks
Read & understand
Match the image to the question
NARSSCube-1’s announced camera experiment belongs to a technology-demonstration mission. A coarse view can establish useful imaging functions even when it cannot identify small objects. A specification describes the intended capability; a validated result additionally needs the actual image, location, acquisition conditions and checks against the stated requirement.
For a fictional image sampled every 200 metres, a 1,000-metre-wide feature spans five samples along that direction. A 50-metre-wide object is smaller than one sample. It may affect a pixel’s brightness, but that does not mean its shape or identity is resolved. This simplified example uses the announced scale for teaching, not a measurement of returned NARSSCube imagery.
Check 1 of 3
10 pointsUse the reading above. You can try again without losing points.
Read & understand
Budget the data as well as the view
Imagine a separate toy camera producing a 200 by 100 pixel monochrome frame at 8 bits per pixel. Its uncompressed pixel data occupy 160,000 bits, or 20,000 bytes. A useful payload rate of 2,000 bits per second needs 80 seconds to transfer those pixels, before headers, retransmissions or waiting for a pass. No NARSSCube camera dimensions or radio rate are asserted by this calculation.
Reducing image size can shorten transfer, but changes what information reaches the ground. Lossy compression can discard detail; dropping pixels changes sampling. An engineering demonstration should state the transmitted product and its processing instead of treating every small file as equivalent to the original measurements.
Budget the data between camera and ground
Original teaching diagram. Fictional camera and rate; not NARSSCube dimensions, imagery or measured throughput.
Open full-size diagram in a new tab: Budget the data between camera and groundCheck 2 of 3
10 pointsUse the reading above. You can try again without losing points.
Read & understand
Make the experience usable by the next team
A repeatable result connects a planned requirement to the hardware and software configuration, test or flight data, processing steps and observed outcome. Keep unsuccessful trials too: they explain why a design or procedure changed. Another team should be able to separate what was demonstrated from what remains a goal.
Suppose a fictional camera trial delivers one complete frame, but its time stamp is wrong and the scene cannot be located. That shows useful capture and transmission behavior while leaving geographic interpretation incomplete. Correct the timing problem and repeat the affected checks. The value of a small mission includes the engineering knowledge preserved for its successors.
Check 3 of 3
10 pointsUse the reading above. You can try again without losing points.
Put it together
Your lesson progress
Each check connects to a part of the story. Complete all 3 to earn your 25-point lesson bonus.
Explore further · Optional
Go to the source
Explore the evidence behind this lesson. These optional readings and videos open in a new tab.
- Read: JAXA: NARSSCube-1 deployment and demonstration goalsRetrospective published 3 December 2019 describing deployment on 20 November. The 200-metre camera description is a demonstration specification, not an independent validation of returned imagery.
- Read: NASA: station operations on 20 November 2019
- Read: NASA: verifying a system against its requirementsGeneral verification methods used for original teaching examples; not documentation of NARSSCube’s undisclosed test procedures.