EIR-OPS-006.4: ADCS Health Check

Objective

To assess the health of the ADCS following launch.

Introduction

The ADCS health check procedure will verify the functionality of the sensors and actuators of the attitude control subsystem of EIRSAT-1.

Important

This procedure will require multiple communication passes.

Procedure

This procedure has five sub-procedures. Sub-procedure D is to be performed outside of a communication pass, as the communication passes are to be optimised for downloading data and performing real-time assessment of the state of the spacecraft.

A. Power On the FSS PDM
B. Enable the ADCS Debug Logger
C. Downlink ADCS Data
D. Assessment of the Downlinked Data
E.  MTQ Functionality Test
F. Disable the ADCS Debug Logger

Important

If ADCS data has not already been downlinked and assessed, for the first communication pass where ADCS Commissioning is to be carried out, only downlinking of ADCS data should be performed. The MTQ functionality Test (Section E) should not be performed until the health of the ADCS subsystem has been assessed.

A. Power On the FSS PDM

Important

You are about to send the first TC of this procedure - Have you completed the EIR-OPS-003: Start a Communication Pass procedure? A Communication Pass must be started prior to carrying out the operations planned for the pass. Don’t forget to open and set up the parameters/actions that will be used during the pass in MCS before the pass begins!

A.1.

Set the parameter platform.EPS.expectedSwitchStates with First row = Last row = 7 to 1 to turn on the FSS PDM.

TC Details
MCS Operation	`Set`
Action/Param Name	`platform.EPS.expectedSwitchStates`
Data Expected with TC	`First row`, `Last row`, `expectedSwitchStates`
Data Size	4 bytes, 4 bytes, boolean
Data Info	The first and last rows/indexes of t parameter to get + the value to set
Allowed Value(s)	0 - 9, 0 - 9, 0 - 1
Expected Value(s)	7, 7, 1
TM Details
Data Expected from TC	No ( + ACK )

A.2.

Confirm the Set in the previous step with a Get (i.e. confirm the value was set successfully).

B. Enable the ADCS Debug Logger

B.1.

Get the cdh.logging.ADCSDebugLogger.enabled parameter
Confirm it is 0 (i.e. disabled).

TC Details
MCS Operation	`Get`
Action/Param Name	`cdh.logging.ADCSDebugLogger.enabled`
Data Expected with TC	No
TM Details
Data Expected from TC	`enabled` ( + ACK )
Data Size	Boolean
Data Info	Enabled state of ADCS Debug Logger
Allowed Value(s)	0 - 1
Expected Value(s)	0 (i.e. disabled)

B.2.

Prior to enabling the Logger, we must first enable the ADCS High Resolution Sampler, which ensures the Logger has access to the most up-to-date ADCS data.
To do this, Set the cdh.telemetry.ADCSHighResSampler.enabled parameter to 1 (i.e. enabled).

TC Details
MCS Operation	`Set`
Action/Param Name	`cdh.telemetry.ADCSHighResSampler.enabled`
Data Expected with TC	`enabled`
Data Size	Boolean
Data Info	Enable (1) or disable (0) parameter sampling
Allowed Value(s)	0 - 1
Expected Value(s)	1 (i. e. enable)
TM Details
Data Expected from TC	No ( + ACK )

B.3.

Confirm the Set in the previous step with a Get (i.e. confirm the value was set successfully).

B.4.

To now enable the Logger, Set the cdh.logging.ADCSDebugLogger.enabled parameter to 1 (i.e. enable).

TC Details
MCS Operation	`Set`
Action/Param Name	`cdh.logging.ADCSDebugLogger.enabled`
Data Expected with TC	`enabled`
Data Size	Boolean
Data Info	Enable (1) or disable (0) logging
Allowed Value(s)	0 - 1
Expected Value(s)	1 (i.e. enable)
TM Details
Data Expected from TC	No ( + ACK )

B.5.

Confirm the Set in the previous step with a Get (i.e. confirm the value was set successfully).

C. Downlink ADCS Data

C.1.

During each of the following communication passes, the Operator can downlink more ADCS data from on-board storage according to the EIR-OPS-011: Downlink Data From Storage procedure.
The table below outlines an approach to the downlinking of data that Operators should initially take.
However, analyses will likely reveal that a particular data type is more useful and the priority of data downlink should be updated accordingly for each successive communication pass

Note

In this table the Operator is advised to downlink ‘some’ rows of a particular data type and whether the OLDest or NEWest rows of data in storage should be given preference. This is done with the assumption that the time constraint of the communication pass will not allow the Operator to get all the desired data downlinked in a single pass.

Priority	What?	Why?
Highest	Some NEW rows of `ADCS HK` data	to determine the current state of the ADCS of EIRSAT-1
Lowest	Some NEW rows of `ADCS Debug` data	to assess the state of ADCS sensors

C.2.

While the state of the ADCS is still being assessed, the Operator should return to Step C.1 and continue to downlink data from the above table as well as any additional data desired as a result of the analysis carried out in Section D.
Also, when Section E (MTQ Functionality Test) is completed in a pass, this Section should be returned to in the following pass to downlink data and assess the results of the MTQ Functionality Tests.

D. Assessment of the Downlinked Data

Important

This procedure should be performed OUTSIDE OF COMMUNICATION PASS times.

D.1.

Assess any ADCS HK and Debug data previously downlinked from the spacecraft and continue to assess the ADCS HK and Debug data that was downlinked as part of Section C. Some things to consider when assessing this data are:
- Confirm the ADCS Execution Count parameter is increasing.
- Check the Bus Currents (Expected Values and Conversions in Table below).
- Check the Bus Voltages (Expected Values and Conversions in Table below).
- Check the Temperature sensor readings (one for each MTM and Raw Gyro Temperatures X, Y and Z (Expected Values and Conversions in Table below).
- Check the FSS Communication Error Count is static and not increasing.

Parameter	Expected Values	Conversion
`platform.ADCS.busVoltages`	4.85V ≤ 5V ≤ 5.15V 3.135V ≤ 3V3 ≤ 3.465V	5V = COUNT × \(\frac{10}{2^{16}}\) V 3V3 = COUNT × \(\frac{6.2}{2^{16}}\) V
`platform.ADCS.busCurrents`	i(5V) \(\sim\) 100mA i(3V3) \(\sim\) 85mA	i(5V) = COUNT × \(\frac{0.394}{2^{16}}\) A i(3V3) = COUNT × \(\frac{2.5}{2^{16}}\) A
`platform.ADCS.mtm1Temperature`	Similar to reference thermometer	temp(mtm) = \(\frac{Count*5}{0.01(2^{16})} - 273.15\)
`platform.ADCS.mtm2Temperature`	Similar to reference thermometer	temp(mtm) = \(\frac{Count*5}{0.01(2^{16})} - 273.15\)
`platform.ADCS.rawGyroTemperature`	Similar to reference thermometer	temp(gyro X,Y) = \(\frac{(count-512) * 100}{275}\) temp (gyro Z) = \(\frac{(count-531) * 100}{275}\)

D.2.

The ADCS Engineer will need to be contacted for the anaylsis of the data that was downlinked from the ADCS Debug storage channel in Section C. Confirm with the ADCS Engineer that the following points are satisfied:
- Gyro sensors are functioning correctly: check both the raw and calibrated rate values correspond to a total rate between 0 and 30 deg/s.
- MTM sensors are functioning correctly: check both the raw and calibrated b-field values. Check that total magnitude is consistent with orbit and that Bdot is consistent with body rates.
- FSS sensor is functioning correctly: check the FSS error code always has one of the values (0, 10,11, 12) when powered.
- CSS sensors are functioning correctly: check that CSS raw values vary over time as the satellite rotates (Note it is possible that some sensors may not be illuminated at all depending on satellite configuration).

E. MTQ Functionality Test

Important

This sub-procedure will require multiple passes. The ADCS Mode timeout must be set up (i.e. Steps E.1 to E.14 must be followed) during each communication pass before the MTQs are driven for testing. Each test of individual MTQ will require its own pass (i.e. these steps must be repeated during at least 10 individual passes to test all MTQ modes).

E.1.

Get the parameter platform.ADCS.adcsModeState to ensure the ADCS is operating in Standby Mode/Nadir State (i.e. its default mode/state) prior to proceeding.

TC Details
MCS Operation	`Get`
Action/Param Name	`platform.ADCS.adcsModeState`
Data Expected with TC	No
TM Details
Data Expected from TC	`adcsModeState` ( + ACK )
Data Size	4 bytes
Data Info	The current mode (2 MSB) and state (2 LSB) of the ADCS
Allowed Value(s)	See tables below
Expected Value(s)	00000000

Where…

`adcsMode` (hex)	ADCS Mode
0000	Standby (Default)
0001	Detumble
0002	Spin Stabilised
5550	Test

`adcsState` (hex)	ADCS State
0000	Nadir (Default)
AAA8	Test

E.2.

Get the platform.ADCS.testModeMtq parameter, with First row = 0 and Last row = 5. If all 0s are returned, skip ahead to Step E.5.
Alternatively, proceed to the next step of this procedure.

TC Details
MCS Operation	`Get`
Action/Param Name	`platform.ADCS.testModeMtq`
Data Expected with TC	`First row`, `Last row`
Data Size	2 bytes, 2 bytes,
Data Info	The first and last rows/indexes of the parameter to get
Allowed Value(s)	0 - 5, 0 - 5
Expected Value(s)	0, 5
TM Details
Data Expected from TC	`testModeMtq` ( + ACK )
Data Size	sint16
Data Info	MTQ drive %
Allowed Value(s)	-100 to 100 (dec) for each row/index of `testModeMtq`

E.3.

Set the platform.ADCS.testModeMtq parameter, with First row = 0 and Last row = 5, to 0,0,0,0,0,0.

TC Details
MCS Operation	`Set`
Action/Param Name	`platform.ADCS.testModeMtq`
Data Expected with TC	`First row`, `Last row`, `testModeMtq`
Data Size	2 bytes, 2 bytes, sint16
Data Info	The first and last rows/indexes of the parameter to set + the value to set
Allowed Value(s)	0 - 5, 0 - 5, -128 to 127 (dec)
Expected Value(s)	0, 5, [0,0,0,0,0,0] (dec)
TM Details
Data Expected from TC	No ( + ACK )

E.4.

Confirm the Set in the previous step with a Get (i.e. confirm the value was set successfully).

E.5.

Warning

The second entry of the cdh.scheduling.TimeAction.entryTime parameter contains the time (in seconds) for the ADCS Mode timeout. This is the reason for setting the First Row = Last Row = 1. HOWEVER, this is only the case for the primary images. If this procedure is being used with currBootImage = 0 (i.e. failsafe), First Row = Last Row = 0 should instead be used for this and all following steps where “1” is used as a first row, last row and/or action argument!

To next ensure the ADCS Mode change TimeAction is ready for use, Invoke the cdh.scheduling.TimeAction.restartRelativeEntries action with the action argument = 1.

TC Details
MCS Operation	`Invoke`
Action/Param Name	`cdh.scheduling.TimeAction.restartRelativeEntries`
Data Expected with TC	`rows`
Data Size	1 byte
Data Info	The index of the relative entry to restart
Allowed Value(s)	0 - 255 (dec)
Expected Value(s)	1
TM Details
Data Expected from TC	No ( + ACK )

E.6.

To check the timeout duration to be used by the TimeAction, Get the cdh.scheduling.TimeAction.entryTime parameter, with First row = Last row = 1, to ensure the value returned is as desired
This is the time the satellite will wait before transitioning the ADCS into Standby Mode/Nadir State.
If the parameter is already set to the desired timeout, proceed immediately to Step E.9.
Else, proceed to the next step.

TC Details
MCS Operation	`Get`
Action/Param Name	`cdh.scheduling.TimeAction.entryTime`
Data Expected with TC	`First Row`, `Last Row`
Data Size	2 bytes, 2 bytes
Data Info	The first and last rows/indexes of the parameter to get
Allowed Value(s)	0 - 511, 0 - 511 (dec)
Expected Value(s)	1, 1
TM Details
Data Expected from TC	`cdh.scheduling.TimeAction.entryTime` ( + ACK )
Data Size	4 bytes
Data Info	Time (in seconds) for the ADCS Mode timeout
Allowed Value(s)	00000000 - FFFFFFFF (hex)

E.7.

Set the cdh.scheduling.TimeAction.entryTime parameter, with First row = Last row = 1, to the desired value.

TC Details
MCS Operation	`Set`
Action/Param Name	`cdh.scheduling.TimeAction.entryTime`
Data Expected with TC	`First Row`, `Last Row`, `entryTime`
Data Size	2 bytes, 2 bytes, 4 bytes
Data Info	The first and last rows/indexes of the parameter to set + the desired `entryTime` to set
Allowed Value(s)	0 - 511, 0 - 511 (dec), 00000000 - FFFFFFFF (hex)
Expected Value(s)	1, 1, > 0
TM Details
Data Expected from TC	No ( + ACK )

E.8.

Confirm the Set in the previous step with a Get (i.e. confirm the value was set successfully).

E.9.

Prior to enabling this TimeAction, Get the cdh.scheduling.TimeAction.entryEnabled parameter, with First row = Last row = 1, and ensure that it is 0 (disabled).

TC Details
MCS Operation	`Get`
Action/Param Name	`cdh.scheduling.TimeAction.entryEnabled`
Data Expected with TC	`First Row`, `Last Row`
Data Size	2 bytes, 2 bytes
Data Info	The first and last rows/indexes of the parameter to get
Allowed Value(s)	0 - 511, 0 - 511 (dec)
Expected Value(s)	1, 1
TM Details
Data Expected from TC	`cdh.scheduling.TimeAction.entryEnabled` ( + ACK )
Data Size	Boolean
Data Info	Whether the TimeAction entry is enabled (1) or disabled (0)
Allowed Value(s)	0 - 1
Expected Value(s)	0

E.10.

To then enable this ADCS Mode timeout, Set the cdh.scheduling.TimeAction.entryEnabled parameter, with First row = Last row = 1, to 1 (i.e. enabled).

TC Details
MCS Operation	`Set`
Action/Param Name	`cdh.scheduling.TimeAction.entryEnabled`
Data Expected with TC	`First Row`, `Last Row`, `entryEnabled`
Data Size	2 bytes, 2 bytes, boolean
Data Info	The first and last rows/indexes of the parameter to set + the desired `entryEnabled` to set
Allowed Value(s)	0 - 511, 0 - 511, 0 - 1 (dec)
Expected Value(s)	1, 1, 1
TM Details
Data Expected from TC	No ( + ACK )

E.11.

Confirm the Set in the previous step with a Get (i.e. confirm the value was set successfully).

E.12.

Set the parameter platform.ADCS.adcsModeState to to 5550AAA8 (hex) to operate the ADCS in Test Mode/State.

TC Details
MCS Operation	`Set`
Action/Param Name	`platform.ADCS.adcsModeState`
Data Expected with TC	`adcsModeState`
Data Size	4 bytes
Data Info	ADCS Mode and State to set
Allowed Value(s)	See table in Step B.1
Expected Value(s)	5550AAA8 (hex)
TM Details
Data Expected from TC	No ( + ACK )

E.13.

Confirm the Set in the previous step with a Get (i.e. confirm the value was set successfully).

E.14.

Get and note the value of the cdh.logging.ADCSDebugLogger.AbsRowsLogged parameter, with First row = Last row = 0.

Tip

This information will allow us to establish where the data generated during this section of the procedure is in on-board storage.

TC Details
MCS Operation	`Get`
Action/Param Name	`cdh.logging.ADCSDebugLogger.AbsRowsLogged`
Data Expected with TC	`First row`, `Last row`
Data Size	2 bytes, 2 bytes
Data Info	First and last rows/indexes of the parameter to get
Allowed Value(s)	0, 0
Expected Value(s)	0, 0
TM Details
Data Expected from TC	`AbsRowsLogged` ( + ACK )
Data Size	4 bytes
Data Info	The absolute number of rows ever logged to this channel
Allowed Value(s)	0 - FFFFFFFF (hex)

E.15.

Set First row = Last row = 0 of the platform.ADCS.testModeMtq parameter to 50 (dec). This should turn on MTQ 1 to 50%.

TC Details
MCS Operation	`Set`
Action/Param Name	`platform.ADCS.testModeMtq`
Data Expected with TC	`First row`, `Last row`, `testModeMtq`
Data Size	2 bytes, 2 bytes, sint16
Data Info	The first and last rows/indexes of the parameter to set + the value to set
Allowed Value(s)	0 - 5, 0 - 5, -128 to 127 (dec)
Expected Value(s)	0, 0, 50 (dec)
TM Details
Data Expected from TC	No ( + ACK )

E.16.

Confirm the Set in the previous step with a Get (i.e. confirm the value was set successfully).
If set successfully, the MTQ should be left in this state for the remainder of the pass (i.e. Do not set platform.ADCS.testModeMtq again during this pass).

E.17.

During subsequent passes, Steps E.1 to E.16 should be repeated with different First Row = Last Row and platform.ADCS.testModeMtq values being substituted in for Step E.15.
Each test of an individual MTQ/mode will need one pass to perform, meaning the entire procedure will need a minimum of 10 passes to complete.
The platform.ADCS.testModeMtq parameter row number and values to set during each pass are detailed in the following table.
The table assumes the steps have been completed once already during “Pass 1”.

Pass	MTQ	Row Number	`Set`
Pass 2	MTQ1 (+X)	`First Row` = `Last Row` = 0	-50 (dec)
Pass 3	MTQ2 (+Y)	`First Row` = `Last Row` = 1	50 (dec)
Pass 4	MTQ2 (+Y)	`First Row` = `Last Row` = 1	-50 (dec)
Pass 5	MTQ3 (-X)	`First Row` = `Last Row` = 3	50 (dec)
Pass 6	MTQ3 (-X)	`First Row` = `Last Row` = 3	-50 (dec)
Pass 7	MTQ4 (-Y)	`First Row` = `Last Row` = 4	50 (dec)
Pass 8	MTQ4 (-Y)	`First Row` = `Last Row` = 4	-50 (dec)
Pass 9	MTQ5 (-Z)	`First Row` = `Last Row` = 5	50 (dec)
Pass 10	MTQ5 (-Z)	`First Row` = `Last Row` = 5	-50 (dec)

F. Disable the ADCS Debug Logger

Important

Only proceed with this Section of the procedure when Section E has been completed in full or in the event that ADCS health checks are being postponed for a prolonged duration.

F.1.

Set the cdh.logging.ADCSDebugLogger.enabled parameter to 0 (i.e. disable).

TC Details
MCS Operation	`Set`
Action/Param Name	`cdh.logging.ADCSDebugLogger.enabled`
Data Expected with TC	`enabled`
Data Size	Boolean
Data Info	Enable (1) or disable (0) logging
Allowed Value(s)	0 - 1
Expected Value(s)	0 (i.e. disable)
TM Details
Data Expected from TC	No ( + ACK )

F.2.

Confirm the Set in the previous step with a Get (i.e. confirm the value was set successfully).

F.3.

We must also disable the ADCS High Resolution Sampler.
To do this, Set the cdh.telemetry.ADCSHighResSampler.enabled parameter to 0 (i.e. disabled).

TC Details
MCS Operation	`Set`
Action/Param Name	`cdh.telemetry.ADCSHighResSampler.enabled`
Data Expected with TC	`enabled`
Data Size	Boolean
Data Info	Enable (1) or disable (0) parameter sampling
Allowed Value(s)	0 - 1
Expected Value(s)	0 (i. e. disable)
TM Details
Data Expected from TC	No ( + ACK )

F.4.

Confirm the Set in the previous step with a Get (i.e. confirm the value was set successfully).

F.5.

The Operator should confirm with the ADCS Engineer that the current and voltage readings, which can be analysed from the downlinked ADCS Debug data, are as expected when the MTQs are enabled before continuing to the next Commissioning Procedure.
Once this is confirmed, the ADCS health check has been completed.
The Operator should then proceed with one of the sub-procedures listed in EIR-OPS-006: Commissioning that is yet to be completed.

Note

The sub-procedures listed in EIR-OPS-006: Commissioning do not necessarily need to be carried out in the order given. However, procedures ending in ‘Operation’ should only be completed after the relevant ‘Health Check’ procedure for that subsystem has been performed. The ‘EMOD Reprogramming’ procedure must also be performed prior to any EMOD activities. Lastly, ideally, payload operations should be the last item to consider in the commissioning of the spacecraft.

Alternatively, if all commissioning sub-procedures have been successfully completed, the Operator may proceed to the EIR-OPS-012: Set Up Nominal Operations procedure.

END OF PROCEDURE