CubeSat Information and Lessons Learned

Thank you for your interest in the CubeSat Launch Initiative (CSLI). Below is some information that will
help with the development of your CubeSat and includes some lessons learned from other entities as
they were designing, building, and operating their CubeSat.

The CubeSat 101: Basic Concepts and Processes for First-Time CubeSat Developers document provides
guidance and recommendations to assist in the development of your CubeSat. This document contains
invaluable information that should be reviewed. The document walks you through the development
process, requirement sources for launch, licensing procedures and more. There have been some
advancements since it was originally published so it is currently being updated and will be posted once
complete.

The Small Satellite Information Search includes the Final Reports from past CSLI missions. To search for
lessons learned for CSLI only, click on the down arrow for Selected Source(s) and click on All to deselect,
then click on SmallSat Reports and click on Search. These reports include valuable lessons learned that
the teams have experienced related to the development of their CubeSat, project management, testing,
etc. and may prevent similar situations from occurring and ensure mission success. In addition, if you
are looking to collaborate with another university you can see who has previously participated and what
their mission entailed.

In addition to the two resources identified above, below are some bulletized items that were identified
by previous CubeSat developers from their experience and are items to consider when
designing/developing your CubeSat.

• Be mindful of any light pollution generated by the CubeSat and state clearly the impact
on ground based astronomical observations. Reach out to the American Astronomical
Society (AAS) Committee on Light Pollution for advice on what is acceptable and
methods to minimize the impact. Another resource is the International Astronomical

2022-08-08 1
 Union Center for the Protection of the Dark and Quiet Sky from Satellite Constellation
Interference Payload website https://cps.iau.org/.
• CubeSats with drag devices for de-orbit will face greater scrutiny from the regulatory
community and may not be approved; design for demise and minimize the use of high
melting point materials (titanium, tungsten, ceramics, glasses, tantalum, etc.).
• CubeSats with propulsion should include GPS as well as the ability to share predicted
ephemeris data with the 18 SPCs and all other satellite operators. In short, know where
you are in space and where you will be at all times to minimize conjunctions with other
spacecraft or crewed vehicles.
• If you have any propulsion or any other means of modifying your orbit, consider
encryption for your spacecraft, preventing the ability of ‘bad’ actors controlling your
spacecraft and ramming it into another object.
• There are International Space Station (ISS) unique technical considerations/restrictions
(battery testing, toxic materials, propulsion, lasers, inhibits, additive manufacturing,
etc.). For the most comprehensive series of requirements that you will have to
consider, please review the following page on the Nanoracks website Technical
Resources - Download Nanoracks IDD & ICD Documents. Please pay close attention to
the Lithium-ion battery test requirements.
• If possible, design your spacecraft to accommodate the broadest range of orbits
possible. Orbit flexibility maximizes your launch opportunities while restrictive orbit
requirements can limit launch opportunities, thereby potentially leading to later than
desired launch dates. In short, if the bus is going to Pittsburgh, it can’t take you to
Seattle.
• Deployment altitudes should be in line with planned mission duration and de-orbit
capability. For example, designing a spacecraft without deorbit capability that will only
last a couple of weeks or requesting a 550 km deploy when the mission will end in six
months resulting in the spacecraft being a hazard to navigation for years to come.
• If you are a 3U or larger and are planning for an altitude of 540 km or higher ensure that
you have considered how you will passivate your batteries and reaction wheels. Also
consider the probability of explosion for all propulsion systems and reaction wheels
above this altitude, ensuring that the risk is small in all instances.
• Consider how far along the CubeSat development is prior to accepting a launch
assignment to avoid multiple schedule delays.
• In general, use an agile model for development so that you can get something working
early and then refine it as your knowledge increases. This will reduce risks of big failures
on large milestones late in the process.
• Having a team member and/or external reviewer with prior experience related to
CubeSat development can be beneficial when considering options at key decision
points.
• For Educational missions it is important that the Principal Investigator and Co-Principal
Investigators manage expectations as to what is truly possible for a student educational
mission with limited budget and schedule. Trying to do too much defeats the primary
purpose of an educational mission.

2022-08-08 2
 • Technical and Project leadership should be carried out as two distinct roles to prevent
the conflation of technical issues and project issues such as budget and schedule.
Systems Engineering students can help to bridge the gap between various sub teams,
technical requirements, budgets, and schedules.
• Gain a clear understanding of your mission objective(s) and the minimum functionality
necessary to allow you to achieve them. Eliminate unnecessary complexity, design in
easy assembly/disassembly to account for human factors and incorporate more
commercial components in the design to reduce the need to design from the ground up.
• Start hardware integration as early as possible to avoid the pitfalls of development
delays and last-minute integration issues. Develop strong validation and verification
standards early in the project. Understanding your spacecraft and managing anomalies
are effort well worth considerable time investment.
• Thermistor wires are prone to fatigue and breaking so covering them with epoxy and
heat shrink tubing can help however it may cause problems with fit. Start fit checking
early and do this often as it will reveal design issues.
• Plan to test early and often to reveal any design issues to prevent inoperability on orbit.
Test as you fly and fly as you test so you are prepared for what you will encounter on
orbit. For the aspects of the mission that cannot be “tested as you fly” should receive
extra scrutiny and design margin. Simulate and test every condition the CubeSat can
experience during on-orbit operations.
• Mission operations and planned duration needed to achieve mission success must
account for the aggregate probability that all required aspects of the mission are
functioning properly simultaneously.
• Implement back-up plans for subsystems much earlier in the design process and have
clearly defined gates for making those decisions. Establish parallel path for critical item
suppliers if there is evidence of an impending delay or of reduced performance.
• Close coordination with the integrator/CSLI team is crucial and don’t be afraid to bring
up issues early. Build an engineering unit in addition to the flight unit if possible. This
would be beneficial in the event of having to perform a failure review.
• Have a robust two-way communications design and add a redundant downlink if
possible. Do no rely on a single ground station for comms and ensure licenses account
for multiple ground stations. Ensure there is adequate power as well to detect the
beacon. Consider commercial off-the-shelf components vs in-house build.
• Team organization and continuity is vital. Long-running programs face substantial risks
due to student and staff workforce transitions. Proper documentation of all satellite
systems and assembly/test procedures is essential to allow rotating staff/student
workforce to successfully continue and complete project work.
• Document all project activities, decisions, methods used, formats, code, lessons learned
etc. Insufficient documentation contributes to the loss of experience and knowledge,
and difficulty in troubleshooting especially with software. Consider turnover and the
need for knowledge capture/mentoring. Configuration Management is essential;
maintain your documentation so you don’t have to reverse engineer if key personnel

2022-08-08 3
 leave the team; prevent scope creep. Someone who is not part of the project should be
able to read and understand it.
• Strong management of the project schedule and mitigation plans for anticipated and
unanticipated delays. Ensure experienced mentoring to provide guidance and support to
meet program objectives (i.e., hardware development will be challenging, and science
investigations will be difficult to achieve). When creating a schedule, set goals for larger
milestones which can drive the schedule, and define smaller, achievable milestones up
to two-weeks out.

2022-08-08 4