Content uploaded by Sebastian Rückerl
Author content
All content in this area was uploaded by Sebastian Rückerl on Aug 14, 2019
Content may be subject to copyright.
SSC19-WKI-07
First Flight Results of the MOVE-II Satellite
Sebastian R¨
uckerl, David Meßmann, Nicolas Appel, Jonis Kiesbye,
Florian Schummer, Markus F¨
ahling, Lucas Krempel, Tejas Kale, Alexander Lill,
Gonzalo Reina, Patrick Schnierle, Sebastian W¨
url, Martin Langer
Institute of Astronautics, Technical University of Munich
85748 Garching, Germany; +49 (0)89/289-16014
s.rueckerl@tum.de
Martin L¨
ulf
Institute for Communications and Navigation, Technical University of Munich
80333 Munich, Germany
ABSTRACT
MOVE-II (Munich Orbital Verification Experiment) is the second satellite of the Technical University of Munich’s
educational CubeSat program. On December 3, 2018, the satellite was launched on the SSO-A SmallSat Express
from the Vandenberg Air Force Base. The following paper shows on-orbit results of the first eight months of
operations. It includes analyses based on our own data as well as the open-source ground station network SatNOGS.
Lessons learned from mission operations and recommendations for future educational missions are provided. The
technical goals of the mission are verifying the satellite’s bus and the qualification of a novel type of quadro-junction
solar cells. Over 200 students have been developing and testing all components of the satellite since the beginning
of the project in April 2015. During the course of the project, the students designed all necessary technology for a
CubeSat bus, with the exception of the electrical power system and the on-board computer’s hardware. Furthermore,
the students developed ground station software as well as an operations interface from scratch. The technological
achievements of the mission range from a linux-based onboard computer software over a magnetorquer-based attitude
determination and control system to two novel transceivers for UHF/VHF and S-Band. A reusable mechanism,
based on shape-memory-alloys, deployed the four solar panels, providing the necessary power. Only hours after the
deployment, we received the first signals of the satellite. The commissioning of the ground station and the effects of
an insufficient power budget of the tumbling satellite preoccupied us during the first month, as well as frequent
watchdog resets. During the commissioning of the Attitude Determination and Control System (ADCS), a spin rate
of
200 °/s
was observed, although the actuators were not activated yet. Detailed analysis with the help of recordings
provided by our own ground station as well as the SatNOGS ground station network revealed a slow increase of the
spin rate since the launch. In the following weeks the spin rate further increased to over
500 °/s
. Afterwards we
were able to modify our ADCS actuation in a way to reduce the spin rate again. Currently MOVE-II is detumbled
and we are moving towards regular scientific operation.
After a presentation of the results, lessons learned from our mission operations are discussed. The paper discusses
the measured values and analyzes the reasons for the observed behaviour. Also the changes made on MOVE-IIb, a
slightly improved copy of MOVE-II, will be explained. The paper concludes with recommendations for designers of
upcoming educational satellite missions, especially regarding resilience against negative power budgets.
INTRODUCTION
In 2006 the development of CubeSats at the Technical
University of Munich (TUM) began with the first satellite
of the Munich Orbital Verification Experiment (MOVE)
called First-MOVE [1]. Members of the Institute of
Astronautics (LRT) built most parts of this satellite. First-
MOVE was launched into low earth orbit in November
2013 from Yasny.
The development of MOVE-II, the successor of First-
MOVE began in 2015. This satellite was developed and
built by an interdisciplinary team of over 200 students
under supervision of the LRT. The development process
of MOVE-II was highly influenced by the lessons learned
of First-MOVE [2]. This leads to a design with strong
requirements for testability, reliability and performance
[3, 4]. MOVE-II was launched into a sun-synchronous
orbit on December 3rd on-board the SSO-A launch, and
is since then operated by students in cooperation with
the LRT.
R¨
uckerl 1 33rd Annual AIAA/USU
Conference on Small Satellites
Figure 1: Fully integrated MOVE-II satellite before ship-
ment
THE MOVE-II SATELLITE
The MOVE-II satellite (see figure 1) is split up into
smaller subsystems. In this part the main developments
will be presented.
CDH
The Command and Data Handling (CDH) system is the
board computer of the CubeSat. It is connected to all
other subsystems. It handles communication between the
subsystems, storage of configuration and housekeeping
data, and commanding of the satellite. Also, the CDH
can either manually or automatically set the operation
mode of the whole system.
Hardware
The CDH hardware is a stack of three boards. First,
the carrier board is part of the satellite structure and
is connected to the PC/104 bus. Second, a processing
module is attached to the carrier board. Finally, a storage
module is stacked on top of the processing module.
The carrier board provides a GPS module, a Ferroelectric
Random Access Memory (FRAM), and a microcontroller
serving as a watchdog. The processing module consists
of a SAMA5D2 processor, a Random Access Memory
(RAM) and NAND flash storage. The storage module
provides an additional SpaceVault flash storage and two
micro-SD card readers. The specifications can be found
in Table 1.
Table 1: CDH Hardware Specification
Component Specification
Power Supply 5 V
Clock Frequency 400 MHz
RAM Size 512 MB
NAND Storage 512 MB
FRAM Storage 32 kB
SpaceVault 1.5 GB
Flash Layout and Boot
The NAND flash of the CDH board is divided in
multiple blocks. One block contains U-Boot, the boot
loader. Three blocks redundantly contain linux kernels
with an integrated rescue system, which is described as
“rawRESQ mode“ below. Another three blocks store the
system images. A system image contains all userspace
programs and default configurations. The FRAM stores
two types of values. First, it stores state variables needed
for communication with the groundstation when using
the rescue system. Second, it contains information about
the system images. The information is the time the image
was last booted and the uptime of the image. When
booting the CDH board U-Boot is started first. U-Boot
then randomly chooses one of the kernels. If the kernel
fails to load, the system will reboot until a working kernel
is chosen. The rescue system will then load the image
variables from the FRAM. Images that last had an uptime
under 10 minutes will be discarded for boot. If all images
are discarded, the satellite will stay in rawRESQ mode.
Software Components
The system image of the satellite consists of various
services running in the background, called daemons. The
daemons and their connections can be seen in figure 2.
There is one daemon for each subsystem and daemons
that control the state of the satellite, or collect data to
send to the ground. As not all subsystems are connected
to each other via a data link, the subsystems communicate
with their respective daemon in the CDH, which in turn
communicates with the other subsystems. The daemons
are connected with each other using a software bus (D-
Bus). The health monitoring system (HORST) of the
satellite is also implemented as a daemon. HORST will
receive sensor values from the other daemons via D-Bus
and change modes if required. Another component is the
Beacon Data Collector which constantly collects relevant
data and sends it to the ground.
The satellite can be in different modes that define the
behavior and current capabilities of the satellite. The
various subsystems of the satellite can be on, off or
sleeping depending on the mode.
rawRESQ mode
When booting the satellite the kernel will load a minimal
set of programs and services to operate the satellite. This
set is called rawRESQ. When all system images fail
to load the satellite will stay in this mode. The mission
control team is still able to contact and operate the satellite
in this mode. Most subsystems are either disabled or run
with less functionality. RawRESQ is used to analyze
problems and repair the satellite if neccessary. Once the
recovery is completed the system images will be flagged
as bootable and the nominal system can be started.
LEOP
Launch and Early Operations (LEOP) is the configuration
the satellite is in after first deploying the satellite in
space. After
30 min
the deployment mechanism of the
Flappanels and antennas will be activated and triggered
R¨
uckerl 2 33rd Annual AIAA/USU
Conference on Small Satellites
Figure 2: MOVE-II Software Architecture
regularly.
15 min
after deployment of the antennas the
satellite will also end its radio silent phase. Due to these
activations the satellite will consume more power than it
generates in this state. All other subsytems are disabled
in LEOP.
SCIOPS
The satellite can be set into Science Operations (SCIOPS)
manually from the ground. In this mode the satellite will
try to automatically point to the sun using the attitude
determination and control system (ADCS) and perform
payload (PL) measurements. If the satellite is not in
safemode all subsystems are enabled.
Safemode
The satellite is in safemode if HORST detects high
temperatures or low battery. In safemode Payload, ADCS,
GPS and S-Band are disabled. Also the CDH is only
awake for
10 s
every minute and suspended for the
remaining
50 s
(called sleepwake), and the ADCS is set
into sleep mode.
Manualmode
In the nominal state of the system, HORST will decide
which modes of the satellite to enter. If the mission
control team needs the satellite to be in different modes,
manualmode can be enabled. In this mode HORST will
not perform any actions for 30 minutes.
Maneuvermode
If the ADCS of the satellite is enabled HORST will
automatically enable its sun pointing mode. If the
mission control team wants to set it to another mode
maneuvermode can be enabled. The system will stay in
this mode until rebooting.
1 Toppanel (shared with payload)
1 Mainpanel (in stack)
4 Sidepanels
Figure 3: Overview of the ADCS hardware boards [5]
ADCS
The ADCS of MOVE-II uses active magnetorquer control
to achieve its two main control strategies: Detumbling and
sun pointing. It is a self-developed system with printed
circuit board (PCB) integrated magnetorquer coils and
commercial off-the-shelf (COTS) sensors. Physically, the
ADCS consists of a Mainpanel located in the center of
the stack and five outer panels: the so-called Sidepanels
and the Toppanel. The arrangement of these boards are
depicted in figure 3.
The Sidepanels share space with the solar cells on
the sides and the Payload on the Top. Each ADCS
panel features a magnetorquer, coil driver electronics,
a gyroscope, a magnetometer, a sun sensor (excluding
the Mainpanel) and a microcontroller.
The Sidepanel microcontrollers recieve commands from
the Mainpanel over a Serial Peripheral Interface (SPI).
They handle magnetorquer control, sensor interfacing,
R¨
uckerl 3 33rd Annual AIAA/USU
Conference on Small Satellites
sensor calibration and preprocessing. The Mainpanel
microcontroller is responsible for the attitude determina-
tion and attitude control calculations using sensor data
gathered from the Sidepanels. It also commands the
Sidepanels to actuate their magnetorquers. Additionally,
it handles commands and configuration received from the
CDH and responds with housekeeping and other sensor
data [5].
A simple and robust B-Dot control strategy is imple-
mented for dampening the initial satellite spin after
deployment. For scientific operations, a linear model-
based control strategy is used to point the Toppanel
towards the sun, ensuring adequate power generation
[6]. An Extended Kalman filter is applied for attitude
estimation [5].
The six available magnetorquers can be used in either
a single or dual magnetorquer per axis configuration.
Additionally only one of the six available gyroscopes
or magnetometers is required for ADCS operation. The
active magnetorquers and sensors can be configured from
ground, and are thus adding redundancy to the system.
All ADCS microcontrollers can be flashed by the CDH
allowing for in-orbit software updates or flash corruption
recovery.
COM
The communication (COM) subsystem consists of two
tranceivers for low and high data rate services. Low
data rate services, such as telemetry and telecommand,
are provided by the UHF/VHF transceiver (see fig. 4).
An additional S-Band transceiver can provide high data
rates of 3 MBit/s. Due to the high spinning rate of the
satellite, the operation of the S-Band transceiver could
not be verified at this point. The following will therefore
concentrate on the UHF/VHF subsystem. An overview
of the RF parameters is given in table 2.
The UHF/VHF transceiver uses a custom RF design
with discrete IC components for frequency synthesis,
mixing and D/A and A/D conversion. All VHF transmitter
components can be switched off or set to sleep, which
provides significant power savings. This was done as the
device needs to be very power saving, reliable and also
to keep the design modular.
After the analog RF path and digitizing, all further
processing is performed in an FPGA. The FPGA used
in the design is a Xilinx Spartan 6 LX45. The Spartan 6
series was chosen since it is reported to be sufficiently
radiation tolerant but also because it can be programmed
with a free Xilinx ISE license. To prevent bit flips in
the FPGA configuration memory, inherently radiation
tolerant magnetoresitive RAM (MRAM) is used.
Both up- and downlink use a phase-shift-keying (PSK)
modulation type. The downlink implements several
variants of 2-ary (BPSK) and 4-ary (QPSK) PSK and
Figure 4: Pictures of the UHF/VHF Flight Model
Property Value
Downlink Frequency 145.94 MHz
Downlink Bandwidth 18.75 kHz
Downlink RF Power 27 dBm
Downlink Modulation BPSK/QPSK
Downlink Symbol Rate 12.5 kBaud
Downlink Coding LDPC 1/2, 4/5
Uplink Frequency 437.8 MHz
Uplink Bandwidth 18.75 kHz
Uplink Modulation DBPSK
Uplink Symbol Rate 12.5 kBaud
Table 2: UHF/VHF Transceiver Parameters
offset-QQPSK (OQPSK). This gives the operators more
control over the radio link and allows higher data rates
if needed.
During the LEOP phase, only the downlink used BPSK
together with a (2048, 1024) AR4JA LDPC code [7]
because of its higher robustness. These codes provide
very high performance, but decoding is too complex
to use them on the uplink. The uplink uses differential
encoded BPSK (DBPSK), which significantly reduces
receiver complexity at the expense of slightly increased
BER.
In the main mission phase, the higher order QPSK
and OQPSK modulations will be used together with a
(5120, 4096)
AR4JA LDPC code. Modulation and coding
can be separately chosen by the operator. The maximum
possible data rate of the system is 20 kBit/s.
The data link layer protocol used on the radio links is
Nanolink [8]. Nanolink is a reliable, connection oriented,
packet based protocol for CubeSats and other spaceborne
assets with similar bandwidth and hardware resources. It
is designed for asymmetric links with small bandwidth-
delay product. The protocol operates efficiently and
R¨
uckerl 4 33rd Annual AIAA/USU
Conference on Small Satellites
S6
S5 S4 S3
S2S1
Figure 5: MOVE-II PL panel with one four junction solar
cell and the corresponding single junction cells
reliably in moderate signal quality due to a type-I hybrid
selective acknowledge automatic repeat request (ARQ)
scheme. Extensible header structures reduce the required
overhead, especially with regard to the ARQ return
channel.
A more detailed description of the COM Subsystems can
be found in [9].
PL
The payload (PL) of MOVE-II characterizes novel four
junction solar cells in space conditions. It is not possible
to obtain similar data on ground, as state of the art
air mass zero (AM0) sun simulators are not able to
reproduce the full solar spectrum in detail. Furthermore,
other influences such as thermal cycling and cosmic ray
impacts can not be simulated at the same time. Thus, the
PL will give an insight in the performance of the novel
four junction cells in realistic space conditions [10].
The PL is located on the topmost panel of the CubeSat.
This ensures optimal sun illumination conditions with the
satellite in sun pointing mode. The PL carries one four
junction solar cell and additionally the corresponding
single junction cells. Furthermore, one cell is added
without a cover glass. As the cell is lacking a protective
cover, it will undergo an accelerated degradation and
enables the prediction of the performance for protected
solar cells in a long-term mission. As the parameters
of the solar cells vary with temperature, each cell has
a temperature sensor attached on the back-side of the
PL panel. Additionally, the sun angle is evaluated by a
dedicated sensor on the same panel. An overview of the
PL panel with all six solar cells is depicted in figure 5.
The electrical characterization is done with a sweep
through the current versus voltage (I-V) curve from open
circuit voltage to short circuit current of the solar cell. For
01234567
0
0.2
0.4
0.6
0.8
1
time [s]
normalized value [arb.]
voltage current
Figure 6: Normalized open circuit voltage and short circuit
current measurements taken by the PL during the rotation
of the CubeSat
the sweep a controllable load is connected to each cell
and high-resolution analog to digital converters (ADC’s)
measure continuously voltage and current data points. To
ensure the functionality of the PL in space environment,
the key components were selected by reviewing publicly
available radiation test data. Additionally, a hardware
self-test is implemented to do in orbit accuracy checks
of the PL.
Before the CubeSat was sent into space, the PL was
tested in functionality and measurment accuracy on
ground. The absolute acccuracy of current and voltage
measurement was evaluated with a calibrated Keithley
2400 sourcemeter. The results of this tests yield a
maximum deviation in current measurement of
0.6 %
and for the voltage measurement only
0.04 %
. Further
tests included direct comparison of I-V measurements to
the standard method. As already mentioned, a hardware
self-test is included to determine any changes in the
measurement accuracy.
The PL is already active but due to the high rotational
rates, no full I-V curve could be measured until now.
The status of the PL was evaluated by executing the
hardware self-test which did not show any deviations in
the measurement accuracy. To do a functionality test, the
PL was switched to a specific mode, where it measures
continuously open circuit or short circuit currents of the
solar cells. The data received from these measurements
were as expected. Due to the rotation of the satellite the
short circuit current is changing rapidly over time as it is
directly correlated with the incoming solar radiation. The
open circuit voltage is only decreasing
15 %
from high
to low illumination. A graph of measurements taken by
the PL during the rotation can be seen in figure 6.
R¨
uckerl 5 33rd Annual AIAA/USU
Conference on Small Satellites
MOVE-II GROUN D SEGMENT
Ground Station
The primary ground station for the TM/TC link is a
ham radio station located on the roof of the LRT. The
antennas for the up- and downlink are mounted onto a
COTS component 2-axis rotator that points the antenna
towards the computed satellite position based on the
two line element (TLE) file for the satellite. The VHF
antenna is connected to a COTS low noise amplifier
(LNA) that is mounted onto the rotator and from there
on it connects to a software defined radio (SDR). For
the uplink the samples are sent to a SDR which is
connected to a high power amplifier which is capable of
providing enough power to reach the maximum allowed
transmission power in the amateur UHF band of
750 W
PEP. Previous satellite missions have found that there are
a lot of terrestrial radio sources –especially over western
Europe– that interfere with the uplink signals[11]. Since
our ground station is located in western Europe the high
output power capability of our groundstation allows us
to us reliably reach the satellite even in the presence of
strong interference from other terrestrial sources.
The (de)modulation and en-/decoding of the signal is
performed in software. For the downlink we use a
GNURadio flowgraph with custom blocks. For the uplink
we started with GNURadio as well but had to fight
growing latency and head of line blocking, so we switched
to a custom made software. Both the uplink and downlink
compensate the frequency shift caused by the Doppler
effect based on computed satellite position and velocity
from TLE orbits.
Operations Interface
The MOVE-II Operations Interface can be split up
into two major parts: the backend and the frontend
components.
The backend is responsible for parsing, storing and
providing the beacon, telemetry and housekeeping data
received from the satellite. It also acts as the counter-
part of the commanding interface on the satellite by
implementing our custom commanding protocol RESQ.
This is combined with a commanding queue and a
logging component that allows us to reproduce the
exact command sequence that was executed on the
satellite and prepare the command sequence for upcoming
overpasses. All these services are provided to any frontend
or automation implementation via a representational state
transfer (REST) application programming interface (API)
in combination with a WebSocket interface to update the
user interface whenever new data is available.
The frontend of the Operations Interface is a web based
graphical user interface that provides overview and
general monitoring functionality combined with a user
configurable data analysis tool. This way all the data can
be easily accessed and analyzed from any location using
a browser. Besides the data analysis the frontend also
abstracts the RESQ protocol from the user allowing for
simpler commanding of the satellite.
LAUN CH A ND EA RLY OPER ATI ON S
The commissioning of MOVE-II began with confirming
that the deployment of our solar panels was successful.
This was confirmed on June 4th, 01:30 UTC by observa-
tions of a SatNOGS groundstation in Australia [12]. We
observed that the satellite was regularly sending a carrier-
only signal and morse callsign, and thus the antennas
must have deployed. In the following days, this was
confirmed by received telemetry data from the electrical
power system (EPS) showing that our solar cells were
deployed.
TLE Detection
The main challenge during the first overpasses was the
accuracy of the provided TLE files, which at first was an
estimate based on the position of the deployer rather than
our satellite. An inaccurate TLE can lead to (1) a shift
in contact times, resulting in incorrect antenna pointing
and (2) an erroneous Doppler correction that will shift
the downlink signal out of the matched filter. Both issues
can cause a loss of communication with the satellite.
To mitigate these issues we simulated orbits that were
shifted locations of the deployer on the orbital plane and
prepared look-up tables for azimuth and elevation angles
based on these simulations. We pointed the antennas
ahead of time towards the position where the satellite
was expected to rise and waited for the satellite signal to
appear in the waterfall diagram. By observing the actual
time of acquisition of signal (AOS) we could identify the
simulated situation that best matched our observation.
We could then use the angles in the corresponding
look-up table to move the antennas by hand during
the first overpass. The automatic Doppler correction
was disabled during the first overpasses and instead the
operator could manually adjust the frequency offset using
a slider in GNURadio. In addition, the original baseband
signal was recorded and was replayed with an automatic
Doppler correction once the correct orbital parameters
were obtained.
This procedure together with the special signal structure
allowed us to identify the downlink signal of MOVE-II in
the waterfall and to obtain a first set of orbital parameters
during the first overpass.
In the following overpasses North American Aerospace
Defense Command (NORAD) continuously added new
objects to the TLE database and the elements of the
existing objects became more precise due to longer ob-
servation times. Rather than further varying the provided
R¨
uckerl 6 33rd Annual AIAA/USU
Conference on Small Satellites
Figure 7: Recorded waterfall of the MOVE-II satellite on the 8th of December 2018 overlaid with the computed Doppler
shifts from three different TLE objects.
orbital parameters we could now identify which of the
TLE objects belonged to MOVE-II. This was achieved by
comparing the observed Doppler shift with the predicted
Doppler shifts from the various TLE objects. Figure 7
shows the recorded waterfall of the overpass on the 8th
of December 2018 as well as the predicted Doppler shifts
for the objects 2018-099A, 2018-099Y and 2018-099L.
Today these objects have been identified as MINXSS-
2, MOVE-II and AISTECHSAT 2, respectively. With
time the objects drifted further apart. Each consecutive
overpass there where more objects that could be excluded
from the list of MOVE-II candidates. This analysis was
supported by booking overpasses of the TLE candidates
on several SatNOGS ground stations. The agreement
of the MOVE-II signal with the booked TLE data set
could be judged by looking at the frequency residual
in the Doppler corrected waterfall graphs that SatNOGS
provided. This allowed us to observe and match MOVE-II
orbits at locations around the world. Finally only object
2018-099Y (NORAD catalog number 43780) continued
to provide a consistent match between the predicted and
observed Doppler shifts and thus the TLE of MOVE-II
had been identified.
Commissioning of Subsystems and Early Operations
The next step in the commissioning procedure was to
deactivate the deployment mechanism. However, we faced
a few problems while trying to do this. First, our power
budget was slightly negative. The battery was drained
after two days. As a consequence, the satellite was
switched off in eclipse regularly. This also switches off
the battery heater, leading to temperatures down to
−5◦C
in the core of the satellite. Afterwards we observed several
CDH freezes, most likely due to some poorly understood
conditions resulting from the cold temperatures. This
triggered EPS watchdog resets, causing us to go into
the rawRESQ mode. Unfortunately even more watchdog
resets were observed in rawRESQ.
A further problem was that our COM link was not nearly
as stable as anticipated, most likely due to the high
spin rates of the satellite. Thus we had to command
our satellite without a stable link. This was achieved
by sending commands up repeatedly at a high frequency
until we got confirmation that the command was executed.
One major issue was that the command ID needs to
be increased by one for each subsequent command,
otherwise the command is dropped by the satellite.
The problem here was that there is no direct way to
find out this ID without a stable link. Therefore we
had to purposely change some telemetry values in the
beacon with each command in order to confirm that the
command was received. This way we could keep track
of the required ID. Because of some issues with this
commanding scheme (which was neither intended nor
tested), it took us until the 21st of January to deactivate
our deployment mechanism.
Normally we would then proceed with testing each
subsystem before going into SCIOPS, which turns on our
ADCS. However, because of the power budget problems
and because, at this point in time, we also noticed through
the signal fading that the satellite was turning quite fast,
we prioritized commissioning the ADCS. We first enabled
only the sensors on the 23rd of January, which showed
that we were turning at
201 °/s
. One week later, on the
30th of January, we enabled the ADCS with the actuators
for the first time.
To verify the functionality of the payload measurement
device, we triggered some measurements. The first
measurements were performed on 7th of May. This
R¨
uckerl 7 33rd Annual AIAA/USU
Conference on Small Satellites
data showed that the PL hardware was still working
as expected, although the data could not be used for the
intended scientific purposes because of a huge pointing
error and uncertainty due to the high spin rate.
FAST SP IN NING MOVE
Hypothesis
Several causes have been considered to explain the
increasing angular velocity of the satellite. The current
theory suggests electro-magnetic disturbance torques
caused by other subsystems. The most likely candidates
are the COM transceiver, the EPS and the solar cell wiring
of the Side- and Flappanels. From flight model testing at
an external facility, we know that the COM transceiver
and the EPS board indeed produce a dipole moment that
induces a magnetic disturbance torque on the satellite.
Since the dipole moment of the COM transceiver is not
modulated depending on the attitude of the satellite, we
assume its net effect on the momentum of the satellite to
be zero. The maximum power point trackers of the EPS
however modulate their dipole moment depending on the
solar array currents which vary based on the satellite’s
attitude towards the sun. So the EPS is a possible motor
that might have contributed to speed up the satellite. Since
we neither have the appropriate test setup for further
analysis nor know the proprietary schematics and board
layout of the EPS, we could not assess the effect that
our EPS has on the satellite’s velocity so far.
A closer look on the Flappanels has revealed that the
solar cell wiring forms a single-winded coil with an
area of
0.0018 m2
and a maximum current of
0.45 A
.
The current path and the resulting dipole moment (green
arrow) are visualized in figure 8 for a single Flappanel.
The magnitude of the dipole depends on the solar
incidence angle. Thus, no dipole moment is generated
for an incident angle over
90°
, nor in eclipse. Whenever
the solar cells are illuminated, a torque perpendicular
to the magnetic field of the Earth and the Flappanel
dipole moment vectors is generated. The Flappanel dipole
moments depend on the attitude of the satellite and can
add angular momentum to or remove angular momentum
from the satellite. We consider this theory the prime
candidate for explaining MOVE-II’s fast spinning motion.
The Sidepanels also produce a small dipole moment
due to their solar cell wiring. However, it is negligible
compared to the Flappanel dipole.
In order to get a better understanding of this disturbance,
several simulations of a spinning satellite without any
actuation have been conducted. A model of the solar
magnetic disturbance caused by the Flappanel solar
cell wiring was integrated into the simulation. By also
adding a constant residual dipole moment, we can see
an increasing trend of the spin rate and a characteristic
oscillation depicted in figure 9. A similar phenomenon
Figure 8: Magnetic Dipole Moment induced by current flow
of the solar cell wiring
0 10 20 30 40 50
100
120
140
160
simulation time [d]
spin rate [°/s]
Figure 9: Simulated solar magnetism disturbance
as seen from the real data depicted in figure 11 could
be reproduced. Although these first simulation results
are plausible, we do not fully understand the complete
phenomenon that causes the characteristic curve yet.
Further investigations are planned in the future.
Attitude Control Strategy
The ADCS has been designed to reliably work for
rotational speeds up to approximately
20 °/s
. For very
high angular rates, the timings of the implementation will
strongly affect the control performance. We distinguish
three different effects on the control performance:
1.
Length of the actuation interval: For both detumbling
and sun pointing the coils are actuated for a specified
amount of time with a constant current. If the
actuation time equals the revolution time of the
satellite, there will be no net-torque. This effect is
R¨
uckerl 8 33rd Annual AIAA/USU
Conference on Small Satellites
periodic with the angular velocity and influences the
efficiency of the controller.
2.
Time between sensor measurement and actuation:
This shifts the actuation period to a moment in time
after the actual measurement. The time difference
with the angular velocity translates to an angle shift
of the controller. Every
180°
the actuation direction
of the controller will invert and so determine if the
satellite accelerates or decelerates. Between those,
there are boundary regions where the controller is
unstable.
3.
Sensor measurement buffering: A buffer for magne-
tometer measurements to compute the time deriva-
tive of the magnetic field (B-dot) is implemented.
If the satellite rotates too much in this time period,
the derivative can not be considered linear anymore.
The overall stability regions result from all effects
explained above. In order to determine the location of
these stability regions, several simulations, calculations
and hardware tests have been done. The plot in figure 10
illustrates the stability regions determined from several
simulation test runs. In each simulation the initial spin
rate, which is shown on the x-axis of the plot, is varied.
The angular rate difference after the simulation has
ended, is given on the y-axis. A controller in the red
domain will spin-up and in the green domain spin-down
the satellite. The simulation results form curves which
are characteristic for each controller. The curve for the
state-feedback sun pointing controller is depicted in red,
whereas the result for the B-dot detumbling controller is
depicted in blue. For rotational velocities above
10 °/s
,
the sun pointing controller behaves like a detumbling
controller. Therefore, it can be also used to slow down
the satellite and, since this controller has a different
length of actuation interval, the stability regions differ
from the actual detumbling controller. A software-in-the-
loop simulation employing the space environment and
sensor simulation from [13] produces the result that the
first stability boundary for detumbling is at
290 °/s
and
for sun pointing
219.5°/s
. These simulated numbers are
very close to theoretical calculations.
As the exact delays are not exactly known, the real
stability boundaries may differ. In a real hardware test
within a Helmholtz coil environment, the boundary is
continuous as efficiency towards it decreases and noise
becomes dominant. For the sun pointing controller, the
upper limit where actuation can be seen is
160 °/s
. The
lower limit of the inverse sun pointing controller is
180 °/s
. The boundary must be between those limits and
is thus much lower than the simulated value of
219.5°/s
.
Also for the detumbling controller, the boundary is lower
than the simulated value and efficiency decreases towards
the detection limit already at around 230 °/s.
In order to use controllers in the unstable regions, in
0 200 400 600 800 1 000 1 200
−4
−2
0
2
initial spin rate [°/s]
angular velocity difference [°/s]
Detumbling
Sun Pointing
Figure 10: Results of simulation showing stability regions of
the ADCS controllers. The green region indicates a stable
controller, the red region an instable controller.
2018-12
2019-01
2019-02
2019-03
2019-04
2019-05
2019-06
0
200
400
527
Date
spin rate [°/s]
Figure 11: MOVE-II tumbling rate as estimated based
on observed signal fading. Green dots indicate successful
ADCS actuations
which the satellite would be normally accelerated, the
sign of the controller gains can be inverted resulting in a
180°
phase shift. With this change, the unstable regions
become stable and vice versa. For practical reasons, we
rather invert the sign of the magnetometer measurement,
which is identical to inverting the sign of the controller
gains for the applied control laws.
Detumbling success
MOVE-II only measures its spin-rate with the embedded
sensors if ADCS is active. As ADCS was turned off
for most of the time, we estimated the spin rate based
R¨
uckerl 9 33rd Annual AIAA/USU
Conference on Small Satellites
on the observed signal fading in the recorded signals.
To get more data points, we combined our own data
with the audio recordings generated for each overpass
recorded with SatNOGS. More than 8000 overpasses for
MOVE-II have been scheduled on SatNOGS so far [14].
Within each recording, we selected a part where several
fading cycles could be observed and calculated the spin
rate based on the average length of a cycle within one
recording. Comparing the estimated spin rate to the norm
of the angular velocities gathered by the ADCS sensors
revealed an error of only a few °/s.
After initially getting aware of the high spin rate in
January 2019, we did some first experimental ADCS
actuations to gain knowledge on the behaviour of MOVE-
II. This also included some actuations with incorrect
controller settings, leading to an even further increased
spin rate of MOVE-II to the overall maximal value of
527 °/s
. End of February we finally managed to find
a regular actuation sequence. This command was then
executed once per day for about 3 months. In the early
phase of the detumbling process a more frequent actuation
pattern was not possible due to the limited power budget.
Mid of May we were able to switch to a more frequent
actuation scheme, leading to a faster decline of the spin
rate. MOVE-II was finally detumbled (spin rate less than
10 °/s
) on May 29th. Since that day we continue with the
actuations to keep the spin rate low while also stabilizing
the temperatures and the power budget of the satellite.
Figure 11 depicts the observed spin rate of MOVE-II
over the first 6 months in orbit, each green dot refers to
one successful ADCS actuation.
NEG ATIVE POW ER BUDGET
In this chapter we discuss the factors making MOVE-II’s
power budget negative and how we can still utilize the
satellite effectively, which hopefully provides guidance
to other teams on how to make their missions resilient
against a negative power budget.
Expectations
According to prior analyses, the power budget for MOVE-
II was expected to be very tight before the satellite reaches
its nominal sun pointing configuration. Depending on
the temperature of the solar cells and the battery in
orbit, as well as the tumbling mode, the budget was
considered to just be sufficient or slightly too tight for a
tumbling satellite in safe mode, i.e. all subsystems except
for the UHF/VHF Transceiver, the CDH and the EPS are
switched off [15, 13]. The reason for the tight margin are
an oversized UHF/VHF transceiver consuming
1 W
on
average, a higher than expected EPS idle consumption of
0.65 W
, and the CDH consuming an additional
0.23 W
continuously.
During the launch and early operations phase, the shape
Figure 12: Hardware-in-the-Loop setup for power budget
verification of MOVE-II
memory deployment mechanism consumes four
20 s
long pulses of
11 W
every three hours until receiving
the deployment confirmation from ground. Due to this
additional factor, the
20 W h
battery of the satellite was
expected to be drained over the course of the first days
until successful two-way contact is established. Once the
satellite is commissioned and points towards the sun, the
power budget was expected to be more than sufficient.
Verification
The ADCS simulation environment described in [16]
was extended, so the solar irradiation of the satellite
both with active and inactive ADCS could be studied
in detail culminating in a Hardware in the Loop (HiL)
simulation that could assess the performance of the
maximum powerpoint trackers and all subsequent power
conditioning circuitry of MOVE-II’s EPS.
The solar array simulator described in [15] can simulate
the realistic IV-curve of a solar array in real-time based
on the solar irradiation and temperature of the array
which the space environment simulation calculates. The
whole engineering model of MOVE-II was embedded
in a HiL setup shown in figure 12 where both the
ADCS as well as the EPS received inputs from the
space environment simulation. This HiL setup closely
resembles the real power consumption of the satellite due
to all subsystems being present and operating in flight
configuration. Additionally, it allows us to assess the
power generation depending on the ADCS sun pointing
performance with a realistic simulation of the dynamics
and disturbances in orbit.
R¨
uckerl 10 33rd Annual AIAA/USU
Conference on Small Satellites
0 5,000 10,000 15,000 20,000
0
20
40
60
80
100
simulation time [second]
battery charge level (blue) [%]
0
5
10
available power (red) [W]
Figure 13: Power budget verification using the HiL simu-
lation in a tumbling scenario
Two power budget test runs were executed with this
setup covering the nominal SCIOPS phase with active
sun pointing and the safe mode with only EPS, CDH, and
the UHF/VHF transceiver turned on, while the satellite is
freely tumbling at
10 °/s
[15]. These runs were executed
at room temperature at which the battery had an internal
resistance of
0.42 Ω
and its heater was turned off. While
the SCIOPS phase clearly showed a positive power budget
with a surplus energy of
3 W h
per orbit, the safe mode
simulation resulted in a slightly positive power budget
indicating that every orbit generates a surplus of
1 W h
or 5 % state-of-charge on average, shown in figure 13.
Preparations for a Resilient Power Budget
Not knowing if the satellite would stay power-positive
during its flight, the under-voltage protection (UVP) of
the satellite’s battery was modified to ensure the satellite’s
proper restart in low-power conditions.
The UVP’s original function is to protect the battery from
deep-discharge. Once the UVP’s trigger voltage
Utrigger
is reached, the UVP turns the whole satellite off. Only
the maximum power point trackers remain connected to
the battery for charging. After the UVP has triggered,
it resets upon reaching the reset voltage
Ures
. In the
original configuration,
Ures
was only slightly higher than
Utrigger
. Therefore the satellite would have turned on
again with a nearly empty battery. Turning on so early
bears the risk of ending up in a boot loop where the
startup current of the satellite systems multiplied with
the internal resistance of the battery drop the battery
voltage below
Utrigger
and therefore prevent the satellite
from reaching its ground station.
We modified
Ures
to
8 V
instead of
7 V
, while keeping
Utrigger
at the original value. According to our simula-
tions and tests it should take several orbits for the satellite
to reach the new
Ures
. Testing on ground showed that
we thereby should gain around
2 W h
before the satellite
switches on. This should be sufficient for multiple orbits.
The battery’s high internal resistance prevents charging
the satellite even longer before reaching 8 V.
The modified UVP is designed to give us a few extra watt
hours after draining the battery, so that we can operate
the satellite for an orbit or more even if the power budget
would be negative. The price that we pay for this extra
energy are long phases in UVP shutdown where the
UVP lets the satellite recharge and all its subsystems are
completely turned off.
Flight Experience
Due to calibration issues with our ground station, the
confirmation of successful deployment could not be sent,
before the battery ran low for the first time.
MOVE-II’s flight data clearly shows that the safe mode
power budget is negative and the satellite usually turns
off during eclipse. Several factors contributing to this
behavior are listed below.
•Low temperature of the satellite
–Battery heater consuming additional power
–Increased battery resistance
•
High power consumption of the essential subsystems
–Oversized COM transceiver
–
High EPS idle consumption and misleading
datasheet
•In-homogeneous solar cell placement
The temperature of the satellite is lower than anticipated.
It was expected to tend towards the upper limit of the
battery and therefore the team did not add multi-layer
insulation to the battery. The minimum temperature of
the satellite was simulated with the safe mode’s heat
dissipation of
1.88 W
and not with the heat dissipation
of the UVP shutdown, which is nearly zero. The safe
mode was expected as power neutral, and therefore as a
realistic cold case.
The low temperature results in the battery heater turning
on during eclipse, creating an additional power draw
of
0.2 W
and thereby consuming about
0.15 W h
of the
1 W h surplus measured during the verification run.
The effect of the cold battery on the power budget is
expected to be even higher, although the team does not
have a sufficient test setup for characterizing the battery
at different temperatures. The internal resistance was
measured to be
0.42 Ω
at room temperature which is a
high value for lithium-polymer batteries and should rise
significantly at temperatures of around
0◦C
, which is the
usual average for MOVE-II during most of its past flight.
The EPS data that we could extract in May hints at an
internal resistance of
0.8 Ω
. It is unclear to what extent
the increase in battery resistance is attributed to the low
temperature and to what extent we see degradation in
R¨
uckerl 11 33rd Annual AIAA/USU
Conference on Small Satellites
this number. A higher battery resistance results in higher
losses while charging and discharging the battery.
The in-homogeneous placement of MOVE-II’s solar
cells also contributes to battery degradation. Figure 13
shows the available power from the solar arrays in red.
Whenever the top of the satellite with the Flappanels is
illuminated, the available power rises to almost
10 W
,
resulting in battery charge currents in excess of
1 A
.
Charging lithium batteries at temperatures below
0◦C
is
not recommended and should be limited to low currents
to prevent degradation [17]. Since MOVE-II’s EPS does
not consider the battery temperature, it always charges
at the maximum available current. The combination of
MOVE-II’s in-homogeneous solar cell distribution and
its low temperature lead to degradation of its battery, a
higher internal resistance, and to an even more negative
power budget as long as the satellite stays in safe mode.
The UVP only charges approximately one fourth of the
2 W h
measured during ground testing due to the higher
internal battery resistance. The result are shorter reset
periods. Figure 14 shows the satellite in reset for one
minute during an overpass which might be triggered by
the UVP.
The problematic power situation described before pro-
vides a strong contrast to the successful commanding of
the satellite and the detumbling maneuvers. The main
reason that MOVE-II survives its negative safe mode
power budget is the modified UVP described in the
previous section. The main lessons that we learned from
the mission so far and should be considered by future
missions are:
•
Make your power budget positive by a wide margin.
•
Complement all values from datasheets regarding
power consumption with your own measurements.
•
Include a mechanism like the UVP that recharges
the satellite for quite a long time after draining the
battery. This element of circuitry saved the MOVE-II
mission.
•
Analyse the cold case scenario thoroughly. Is it
possible that the satellite stays off for a longer time,
creating a different cold case than the expected safe
mode?
IMPROVEMENTS ON MOVE-IIB
Within the last months we were building a second satellite,
MOVE-IIb. MOVE-IIb is a copy of MOVE-II with only
minor changes to mitigate the effects of a fast spinning
satellite. MOVE-IIb is already integrated in the CubeSat
deployer (see figure 15) and is awaiting its launch on
a Soyuz rocket in July 2019. The following part will
describe the changes made compared to MOVE-II.
Figure 14: Overpass showing MOVE-II reboot due to UVP
triggering. Shutdown happens 4.9 minutes into the overpass.
Reboot at minute 6.
Figure 15: MOVE-IIb Satellite integrated in the EXO-
LAUNCH CubeSat Deployer
Figure 16: Solar cell wiring on the Flappanel of MOVE-II
(left) and MOVE-IIb (right).
R¨
uckerl 12 33rd Annual AIAA/USU
Conference on Small Satellites
Adjusted Solar Cell Wiring
The investigation process into the fast spin of MOVE-II
overlapped the integration phase of MOVE-IIb so the PCB
design could not be adjusted. Luckily, only the wiring of
the Flappanel was identified as the main culprit of the
spinning as pointed out in the ”Fast Spinning MOVE”
section. The kapton tape of MOVE-IIb’s Flappanels was
removed, the cable to the cathode of the solar cells bent in
a shape where the generated dipoles will cancel each other
out and the cable was secured with kapton tape again.
A side-by-side comparison of the flight configuration of
both MOVE-II’s as well as MOVE-IIb’s Flappanels is
given in figure 16.
ADCS Controller Countermeasures
The timing issues mentioned in the “: Attitude Control
Strategy” subsection can be avoided by modifications in
the detumbling controller algorithm.
In order to compute the value of the time derivative of
the magnetic field (B-dot), the kinematics of the satellite
can be considered. Using a single measurement of the
magnetic field, together with the angular velocity value
measured by the gyroscopes, the magnetic field value
can be extrapolated for a given time. By evaluating a
simple vector kinematic equation with the extrapolated
sensor data, the B-dot value for the control law can be
obtained.
If this formula is used to compute B-dot instead of using
the buffer method, then the total time between sensor
measurement and actuation will be decreased, since only
one measurement is needed. Also, this formula allows us
to consider estimated measurement-actuation delays by
further extrapolation of B-dot. Additionally, it turns out
to be optimal not only to compensate for these delays,
but also to further extrapolate B-dot to get its value in
the center of the actuation interval.
With these modifications, the boundary angular velocity
of the algorithm implemented in MOVE-II could be
increased to a theoretical limit of
1200 °/s
. This modified
version of the detumbling algorithm was implemented
into MOVE-IIb, with the possibility of changing delay
estimations and actuation cycle timings from ground.
Figure 17 shows the results of the modified controller
test. In the figure it can be observed that the controller is
stable at least up to a spin rate of approximately
800 °/s
.
CONCLUSION
MOVE-II was operated in space for more than 6 months
until now. In this time we could verify most of the subsys-
tems and stabilize the satellite for regular operations. Even
though we had some problems with the unexpectedly high
spin rate of more than
500 °/s
, we could still find a way
to detumble MOVE-II. We are now looking forward to the
scientific operations phase of the satellite and performing
0 50 100 150 200 250
0
200
400
600
800
1,000
Time [s]
spin rate [°/s]
not actuating
actuating
Figure 17: Observed Angular Velocity during a Helmholz
Cage Test using ”Fast BDot” controller
regular measurements with our payload. At the same
time we are awaiting the launch of MOVE-IIb with the
improved wiring and the adapted controller. We hope
that we were able to mitigate the issue that caused the
satellite to spin itself up. At the same time we improved
the capabilities of the system to cope with high spin rates
to simplify operations of MOVE-IIb, if such high spin
rates should be observed again.
Acknowledgements
The authors acknowledge the funding of MOVE-II by
the Federal Ministry of Economics and Energy, following
a decision of the German Bundestag, via the German
Aerospace Center (DLR) with funding grant number 50
RM 1509.
The authors acknowledge the support and launch oppor-
tunity provided by EXOLAUNCH for the MOVE-IIb
satellite.
References
[1]
Manuel Czech, Andreas Fleischner, and Ulrich
Walter. “A First-MOVE in Satellite Development at
the TU-M
¨
unchen”. In: Small Satellite Missions for
Earth Observation. Springer, 2010, pp. 235–245.
[2]
M Langer et al. “Results and lessons learned
from the CubeSat mission First-MOVE”. In: Small
Satellite Missions for Earth Observation. Springer,
2015.
[3]
M Langer and J Bouwmeester. “Reliability of
CubeSats-Statistical Data, Developers’ Beliefs and
the Way Forward, AIAA”. In: USU Conference
on Small Satellites. 2016.
[4]
Martin Langer et al. “A reliability estimation tool
for reducing infant mortality in Cubesat missions”.
R¨
uckerl 13 33rd Annual AIAA/USU
Conference on Small Satellites
In: 2017 IEEE Aerospace Conference. IEEE. 2017,
pp. 1–9.
[5]
D Messmann et al. “Advances in the Development
of the Attitude Determination and Control System
of the CubeSat MOVE-II”. In: 7th European
Conference for Aeronautics and Space Sciences
(EUCASS), Milan, Italy. 2017.
[6]
David Messmann et al. “Magnetic Attitude Control
for the MOVE-II Mission”. In: 7th European
Conference for Aeronautics and Space Sciences
(EUCASS), Milan. 2017.
[7]
Consulative Committee for Space Data Systems
(CCSDS). TM Synchronization and Channel Cod-
ing. CCSDS 131.0-B-2, Blue Book. Issue 2. Aug.
2011.
[8]
Nicolas Appel, Sebastian R
¨
uckerl, and Martin
Langer. “Nanolink: A Robust and Efficient Pro-
tocol for Small Satellite Radio Links”. In: Small
Satellite Systems and Services Symposium – 4S.
European Space Agency, 2016.
[9]
Sebastian R
¨
uckerl et al. “Software-Defined Com-
munication on the Nanosatellite MOVE-II”. In:
69th International Astronautical Congress. 2018.
[10]
M. Rutzinger et al. “On-orbit verification of space
solar cells on the CubeSat MOVE-II”. In: 2016,
pp. 2605–2609.
[11]
Martin Buscher. All Power to the ISS: First Results.
2019. URL: https://marconissta.com/2019/02/08/
all - power- to - the - iss- first - results/ (visited on
06/07/2019).
[12]
Zath-VHF. SatNOGS Network - Observation
349561. 2018. UR L: https://network.satnogs.org/
observations/349561/ (visited on 06/09/2019).
[13]
Jonis Kiesbye. “Hardware-in-the-Loop Verification
of the Distributed, Magnetorquer-Based Attitude
Determination & Control System of the CubeSat
MOVE-II”. MA thesis. Institute of Astronautics,
2017.
[14]
Libre Space Foundation. SatNOGS Network -
Observations (MOVE-II). 2019. URL: https : / /
network.satnogs.org/observations/?norad=43780
(visited on 06/09/2019).
[15]
D
´
aniel Nagy. “3-Channel Solar Array Simulator
for CubeSat Power Budget Verification”. MA the-
sis. Institute of Astronautics, 2018.
[16]
M. Langer et al. “MOVE-II The Munich Orbital
Verification Experiment II”. In: 2017, pp. 441–459.
[17]
M. Fleischhammer et al. “Interaction of cyclic
ageing at high-rate and low temperatures and safety
in lithium-ion batteries”. In: Journal of Power
Sources 274 (2015), pp. 432–439.
R¨
uckerl 14 33rd Annual AIAA/USU
Conference on Small Satellites