...
- Even if things work 100 % on ground after several tests don’t assume it will in orbit.
- You can’t see the S/C anymore
- Allow to improvise
- Prepare to reset
- Debug a lot.
- Send raw data as baseline, do processing on ground – many things can go wrong in orbit
- Downlink raw data then automate each processing segment at a time and see what you get. Finally ‘L4’ data when others work.
- If processing pipeline works 100% on ground, this does not mean it will in orbit.
- Perform segment-to-segment processing to see if each block works as it should. Debug a lot.
- Radiometric calibration: makes sense, though there will be dead pixels and pixels that will look different from each other (different intensity/radiance wrt to time), SNR will decrease in some pixels. First week will be ok, but expect the “bad” pixels to happen after a couple of weeks.
- Hard to do geo-referencing on-board.
- Synchronization is difficult since there will be processing delays and timestamps do not represent the ancillary data taken perfectly. Good that we use PPS for synch. Constant offsets in timestamp is just theory. Many random disturbances that will affect data synch (magnetic residuals, electronics, place in orbit).
- EstCube-1 had time drift of up to 2 seconds. This accumulates to a delay (not constant) and will compromise the “scheduling of events”.
- Use a “sequential events” algorithm/script to perform operations (timer)
- Automate each step at a time (after we have understood what goes on in each phase)
- ADCS (NavData) synch may have overhead but perfectly doable with milliseconds of delay
- Do the following at first (with each phase having a timer):
- Orbit 0 - Establish contact
- Next orbit +1 - Uplink
- Next orbit +2 - Prepare slew maneuver
- Next orbit +3 - Imaging (capture only)
- Next orbit +4 - Imaging (capture + storage)
- Next orbit +5 - Data processing to L1a
- Next orbit + 6 - Downlink at S-band
...