Starting point: assume ~ 1U volume and a camera sensor is fixed, what can we do? Performance Specs that we can anticipate to get, roughly. How it works in between.

At the end, provide a “contract format” for what to expect from each subsystem. Should read as concrete design goals like ECE295. External requirements given by each subsystem, who in turn figure out the rest.

Explaining payload performance specs: spectral range, responsivity / SNR, spatial and spectral resolution, ground swath width (along & across-track). I.e., take from FINCH EYE paper.

==⇒ what should each subsystem produce “at the end” of design phase…

optics - component sizing, roughly, and dimensions (assuming offner grating design). Mention other designs - VPH GRISM, Prism, etc. , all of which are clunkier / less efficient. Define what Optics produces - ZEMAX File.

Optomechanics - define what they produce. Challenges with making this - (again, based off FINCH EYE paper). Deliverables, SolidWorks file, FEA simulations.

PAY ELEC - build PAY PCB board. read datasheets & route traces. Microcontroller chip & peripherals to control sensor w/ I2C or other signal (bytes in) and collect DCMI output (frames out), and send onto storage.

PAY FIRM - writes firmware code that orchestrates this, and implements lossless onboard hyperspectral compression.

Data Processing - removes satellite motion artifacts and enhances datacube image quality. Data storage, processing, display pipeline and public visualization.

Science - scientific data processing. Literature review, processing algorithm development, comparison, benchmarking, application onto downlinked dataset.

The system design architecture should ideally be a flow diagram that gives an overview of how different components of the system (payload in this case) work together. At this stage, we only need a L0 (single block diagram of the entire mission which includes bus, pay, space environment, etc) and L1 (interfaces of the subsystems in payload) level of architecture; L1 is the level which shows how different subteams interact together for the payload system with some technical specificity (perhaps resolution specs, high level data processing pipeline, etc). If you remember Ben's slides on the levels of architecture, L0 and L1 are the top level system components and as you get further into the mission you trickle down to L2, L3 which include more specific technical requirements/components/interfaceds. Each subsystem will have its own architecture diagram in L2 and L3.

The subsystem specification ideally comes in L2 but if you're sure that the specifications will be the same for our new mission, you can include some of those in the L1 diagram as well. L2 and L3 architecture diagrams are usually done after the mcr. (edited)

something like this but for payload system at L1 with some technical specifications

something like this but for payload system at L1 with some technical specifications

For the last EDR this was the architecture diagram for the instrument, tho it's at a much later design stage I’d imagine

For the last EDR this was the architecture diagram for the instrument, tho it's at a much later design stage I’d imagine