Present: Hendrik Ehrpais (UTartu), Umesh Bhat (UTartu), Andri Slavinskis (NASA Ames, UTartu), Mariusz
Mission Operations of EstCube-1
- Mission control system used on EstCube-1 was developed together with some engineers from a commercial company CGI Estonia
- They did commissioning for 1 year
- Only 1/2 year operations
- Had a lot of problems with payload and ADCS (residual magnetic dipole disturbances) that affected the subsystems and detumbling
- A lot of debugging in commissioning but still a fun experience (a lot to learn)
- They have 1 in charge of operations but all 8 subsystems representatives participate in operations (for uplink and downlink). Total operators: 8.
- Daily communications
- Resets to LEOP-mode if does not communicate 1 time per day (something is wrong).
- For EstCube-2 they are currently coordinating with AGI STK how to simulate real-time the satellite in orbit as well as attitude maneuvers
- Acquire TLE (from launcher) and do orbit propagation
- Use GPredict for estimating where the satellite is prior to tracking it with Ground Station (uplink/downlink)
- They have open downlink anywhere, identifying the ground station from s/c is tricky
- Downlink data has thumbnails (JPEG2000 product) together with TM
- Thumbnails inform the operator whether they want to downlink full data products or not
- Uplink also open, very difficult to hack because then the commands and script structure must be known perfectly, difficult to change anything onboard because the commands
- No encryption: more processing power and delay in time
- They get packets of data in XML on ground and visualize them with graphing (much like OpenMCT – but their own)Comms. UHF HAM Radio uplink
- AMX25 protocol
- XML formats are read on the S/C
- EstCube-2 will be at 550 km SSO, launched in Q3 2021 or Q1 2020
- Lessons learned: test, test, test
- Train on operations prior to launch
Recommendations
- 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
- Get ICDs from NanoAvionics quickly
- See how payload will interface with Flight Computer, GPS etc.
- Clock inputs/outputs
- This will tell us how we want to operate and how we should coordinate with NanoAvionics such that we can get access to as much as possible
- Ok with NA’s CSP client but
- Make sure the overarching software/interfaces are understood perfectly
- Or else it can risk your operations
- Scripts through CSP is ok, but make sure this integrates well with the Flight Computer’s software/structure/architecture
- Visit them at University of Tartu in spring 2019 together with Alto University?
- Hold a workshop
- They are also developing a radiometric processing imager
- Learn from their operations in-person
- Alto Univ. in Finland flies a hyperspectral camera, much to learn
Contact:
- Hendrik Ehrpais (ADCS, mission operations): Hendrik.Ehrpais@estcube.eu
- Umesh Bhat (Software, mission control system): umesh.bhat@estcube.eu