EIR-OPS-031: DTMF Reboot
Objective
To power-cycle the spacecraft via the DTMF reset tone in an effort to re-establish 2-way communications.
Introduction
Danger
This procedure should be used when no TM is received from the spacecraft by either the UCD GS or the amateur radio community and in this case, only after the Operator has already tried to re-enable RF Tx on the spacecraft as detailed in the NACK/Timeout/Unexpected TM procedure. Alternatively, this procedure should be used if the only TM being received from the spacecraft is TM from the CMC’s hardware beacon.
Using this procedure, the Operator will work to re-establish 2-way communications with the spacecraft following the DTMF reset tone.
Procedure
This procedure contains the following sub-procedures:
Note
A communication window with the spacecraft is required for Sections A, B, C and E.
A. Sending the DTMF Reset Tone
A.1.
The Operator should consult with the GS Team about transmitting the DTMF reset tones to the spacecraft.
When the tones have been sent, proceed to Section B.
Note
Sending the DTMF tones is not always successfully at resetting the OBC. Therefore, multiple attempts can be made to send the tones prior to proceeding to Section B. Alternatively, attempt Section B and return to this section if 2-way communication is not promptly established or if the previous DTMF reset attempt is believed to have failed.
B. Re-establishing 2-way Communications
Note
As the current state of the spacecraft is potentially uncertain after the fault that led to loss of communications and then the DTMF reset, it is advised that the Operator carry out the below steps to re-establish the state of the spacecraft prior to proceeding the Section C.
B.1.
GettheVersion.satelliteStringparameter.Repeat sending this
GetTC (as long as the pass proceeds) until TM is received from EIRSAT-1.
TC Details |
|
MCS Operation |
|
Action/Param Name |
|
Data Expected with TC |
No |
TM Details |
|
Data Expected from TC |
|
Data Size |
8 bytes |
Data Info |
the “EIRSAT-1” string. |
Allowed Value(s) |
|
Expected Value(s) |
|
B.2.
To determine which mission image is the current boot image on the OBC,
Gettheplatform.OBC.obc.currBootImageparameter.
TC Details |
|
MCS Operation |
|
Action/Param Name |
|
Data Expected with TC |
No |
TM Details |
|
Data Expected from TC |
|
Data Size |
1 byte |
Data Info |
the current boot image of EIRSAT-1 |
Allowed Value(s) |
00 - 02 (Hex) |
Where…
|
Image |
0 |
failsafe |
1 |
primary1 |
2 |
primary2 |
B.3.
To determine which state the Separation Sequence is currently in,
Getthemission.SeparationSequence.stateparameter.
TC Details |
|
MCS Operation |
|
Action/Param Name |
|
Data Expected with TC |
No |
TM Details |
|
Data Expected from TC |
|
Data Size |
1 byte |
Data Info |
Current state of the Separation Sequence |
Allowed Value(s) |
00 - 09 or 66 (dec) |
Expected Value(s) |
66 (i.e. the finished state), if initial AOS is complete |
Where…
|
State |
|---|---|
00 |
Init |
01 |
PostLaunchWait |
02 |
MinYPrimaryBurnStart |
03 |
PlusYPrimaryBurnStart |
04 |
MinXPrimaryBurnStart |
05 |
PlusXPrimaryBurnStart |
06 |
BurnTimeWait |
07 |
BurnOff |
08 |
BetweenBurnWait |
09 |
SecondaryBurnStart |
42 |
Finish |
B.4.
If
currBootImage= 0 in Step B.2, skip ahead to Section C as the failsafe image does not have a Mode Manager component.Else,
Getthemission.ModeManager.Modeparameter to determine which mode EIRSAT-1 is currently operating in.
TC Details |
|
MCS Operation |
|
Action/Param Name |
|
Data Expected with TC |
No |
TM Details |
|
Data Expected from TC |
|
Data Size |
1 byte |
Data Info |
Current Operational Mode of the satellite |
Allowed Value(s) |
0 - 4 |
Where …
|
Operational Mode |
|---|---|
0 |
Separation Sequence |
1 |
Commissioning |
2 |
Nominal |
3 |
WBC |
4 |
Safe |
C. Downlinking Data
C.1.
NEWEST rows of data from the
Event,HKandTEDdata logs should initially be given the highest priority for data downlink.However, the priority for data downlink should be re-assessed by the Operators between each pass following the analyses performed in Section D, as the analyses will likely reveal that a particular data type may be more relevant than another to fully establish the cause of this anomaly.
With the data downlink priority for a given pass established, during the pass, downlink data not previously retrieved by the ground segment from the relevant on-board storage channels according to the EIR-OPS-011: Downlink Data From Storage procedure.
D. Debugging the Issue
Note
As this is a failure/unexpected scenario, rather than a strict set of instructions, this section of the procedure instead aims to help guide the Operator in their fault analyses. The steps/analyses carried out in practice should be tailored based on the Operators findings.
Warning
TC authentication is disabled at boot to reduce the risk of loosing communication with the spacecraft. Therefore, TC authentication is now disabled after the DTMF reboot. The Operator should consider following the EIR-OPS-009: Enable TC Authentication procedure to re-enable TC authentication to prevent replay attacks.
D.1.
Assess the most recent data generated/logged by the OBC and downlinked in Section C to:
Determine if any TCs were accepted by the spacecraft that were not sent by the UCD GS.
Determine if the OBC was generating and logging data right up until the DTMF reset or if data generation/logging stopped at an earlier point in time.
Determine if reboots prior to the DTMF reset occurred whose timings are consistent with the time at which 2-way communications was lost.
Determine if any anomalous behavior is seen in the data prior to, or at the time at which, 2-way communications was lost. In addition to instantaneous values of each parameter in the downlinked data, check how the values changed with time. Use the Grafana Mission Monitoring System (MMS) to help with this. Pay particular attention to CMC-related parameters.
…
Note
If the hardware beacon is detected when communications are re-established, it is expected that there will be several logged events since last communication due to the OBC and CMC not being able to communicate with each other (i.e. the issue that led to the hardware beacon) and generating events.
D.2.
The Operators should consider if a time-related bug is potentially the cause. More specifically, the Operators should consider:
Has the spacecraft remained powered ON without interruption for this long of a duration before?
Has an image remained the boot image without interruption for this long of a duration before?
…
…
E. Resuming Nominal Operations
E.1.
Depending on the current Operational Mode and/or boot image of the spacecraft, the Operator should follow the EIR-OPS-007: Operational Mode Change and/or EIR-OPS-024: Boot Into OBC Image procedures, along with additional procedures in this manual (e.g. see EIR-OPS-012: Set Up Nominal Operations ), to resume nominal operations (i.e. Nominal Mode with the experiment running and data logging on-going) once the anomaly investigation in Section D is complete.
END OF PROCEDURE