Operational Modes

1. Communication with ARO (ham radio operator)

   1. Based on orbital parameters, MCC should have sent a time-delayed command to our satellite telling it to turn on receiver when we're roughly over ARO's area
   2. ARO themselves will uplink selfie-sat pass → this will initiate TCP/IP server, etc
   3. Take the picture, downlink → all while continuously maintaining a connection with the ARO

2. Communication with MCC (ground station)

   1. If satellite knows it's own orbital parameters, it will start pinging as it goes over the ground station (this is called beacon tracking)
   2. Establish a connection, set up TCP/IP server
   3. Transmit/receive data, correct error packets
      1. For our mission, it probably makes more sense to value transmitting telemetry data down rather than serving an ARO with uplinks (plus, uplinks are likely going to be less data anyway), so we will always transmit all telemetry down before accepting any uplinks

3. Idle (when we're not over ARO or MCC)

   1. Literally doing nothing

4. Emergency mode:

   There shall be two emergency modes: transmit emergency & receive emergency

   Transmit Emergency Mode - The more commonly used emergency mode - if no link has been established within the last 72h, continuously ping the ground station at a frequency of 2 times the shortest MCC window → go into receive mode otherwise

   Receive Emergency Mode - Mainly used for low power emergency - if no link has been established in the last 72 hours, periodically turn the receiver on based on EPS capabilities

   Both modes shall communicate with unencrypted UDP commands.

   Reasons:

   • Low power from satellite
     • Satellite did not receive signal from ground station in 72 hours, periodically turn the receiver on as possible based on EPS
   • ADCS pointing errors (e.g. spinning out of control) → if it's software we can potentially correct for it, but mechanical errors we have no control over ("we" as in comms)
     • If it's spinning around like crazy, there's not much we can do because we just won't be able to transfer the data → best we can do is switch over to UDP communication, non-encrypted on both ends of the comms link
     • If it's stuck in one position or something, we can still do the same, switching to UDP + non-encrypted
   • SETs causing CDH failure → but at that point there's not much we can do
     • If it's still possible, switch receiver to an always-on mode to listen for unencrypted UDP commands
   • Tracking error
     • How do other teams react to tracking error? → need to research this
     • How will we be able to identify that we're experiencing a tracking error?
   • Too much noise
     • Is this an error that will even occur?
       • Perhaps we miscalculated values in our link budget and that could be the cause of this error
     • Potentially switch modulation technique within the software → this case is low priority, so probably not too important to implement

5. Unencrypted mode: if satellite has not received any encrypted uplink commands in 48 hours, it can accept unencrypted commands

6. Startup - deploy antennas, don't transmit signals for at least 5 mins

   1. Should we be pinging on startup?
      1. No, we'll rely on GPS or TLE to make first contact, unless we run into a case where there's been no contact for 72 hours, in which case we start pinging

Summary

We need to:

• Implement emergency UDP
• Determine whether the satellite will be able to determine its own orbital parameters
• Look at the nuances of the send/receive flow