BitSat

TM

The Next Generation of Cloud Computing

BitS

Conducted by Deep Space Industries Inc.

- - - -

Prepared Sergio Gallucci

Reviewed Craig Foulds

Signed off Daniel Faber

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 2 OF 98

BITSAT PRELIMINARY DESIGN REPORT

 DSI-BitSat-PDR-01
12 March 2015
Page 1/98

Deep Space Industries and Dunvegan Space Systems are working together to bring bitcoin to
space. BitSat™ will add satellites to the bitcoin network that act as nodes which broadcast
and authenticate bitcoin transactions continuously from orbit. Placing block chain
distribution nodes in orbit will help bitcoin remain a free currency that always remains up-
to-date and is safe from blocking by any party.

This document contains the material presented as the Preliminary Design Review of BitSat
Demonstration Mission, prepared by the Deep Space Industries under contract to Dunvegan
Space Systems.
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 4 OF 98

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 5 OF 98

1.0 Project Management ............................................................................................................................. 7

1.1 Document Purpose ............................................................................................................................. 7
1.2 Intended Audience ............................................................................................................................. 7
1.3 Technical Contributors ....................................................................................................................... 7
1.4 External Reviewers ............................................................................................................................. 7
1.5 Acronyms and Abbreviations.............................................................................................................. 7

2.0 Mission Overview ................................................................................................................................ 10

2.1 Mission Objectives ........................................................................................................................... 10
2.2 Project Scope ................................................................................................................................... 10
2.3 B1 Deliverables ................................................................................................................................ 11
2.4 Timeline ........................................................................................................................................... 12

3.0 Systems Engineering............................................................................................................................ 13

3.1 Mission Requirements ...................................................................................................................... 14
3.2 Concept of Operations ..................................................................................................................... 16
3.3 Satellite Overview ............................................................................................................................ 18
3.4 Operational Modes .......................................................................................................................... 19
3.5 Spacecraft Mass Budget................................................................................................................... 22
3.6 Spacecraft Power Budget ................................................................................................................. 23
3.7 Spacecraft Data Link Budget ............................................................................................................ 25
3.8 Spacecraft Data Budgets.................................................................................................................. 26

4.0 Subsystems.......................................................................................................................................... 28
4.1 Interfaces......................................................................................................................................... 29
4.2 Payload............................................................................................................................................ 30
4.3 Power System .................................................................................................................................. 32
4.4 On-Board Computer ......................................................................................................................... 36
4.5 Structure .......................................................................................................................................... 44
4.6 Attitude Determination / Guidance, Navigation, & Control .............................................................. 49
4.7 TT&C ................................................................................................................................................ 56
4.8 Antennae ......................................................................................................................................... 58
4.9 Propulsion ........................................................................................................................................ 59

5.0 Ground Segment ................................................................................................................................. 62

5.1 Requirements................................................................................................................................... 62

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 6 OF 98

5.2 Parabolic dish .................................................................................................................................. 62

5.3 Rotor and Controller ........................................................................................................................ 62
5.4 Demodulator.................................................................................................................................... 62
5.5 Timeline ........................................................................................................................................... 63
5.6 Price Breakdown .............................................................................................................................. 63

6.0 Programmatics and Financials ............................................................................................................. 64

6.1 Programmatics Overview ................................................................................................................. 64
6.2 Risk Log ........................................................................................................................................... 70
6.3 Expectations Management for Open Source Delivery ....................................................................... 79

7.0 Review Item Discrepancies .................................................................................................................. 81

7.1 Action Items Log .............................................................................................................................. 89

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 7 OF 98

1.0

1.1
The purpose of this plan is to define the scope of, and the approach to, the development of
the BitSat Demonstration Mission (referred to simply as “B1”). This project is the first phase
of a larger program to deliver an operational fleet capable of global BitCoin transaction
monitoring spacecraft. This preliminary design reviews the feasibility, requirements, and
solutions to the BitSat concept.

1.2
This document is intended for the following stakeholders:
Dunvegan Space Systems, Inc.
Deep Space Industries, Inc.

1.3
Daniel Faber, Deep Space Industries - Programmatics, Systems Engineering
Craig Foulds, Deep Space Industries – Subsystems, Systems Engineering
Sergio Gallucci, Deep Space Industries – Subsystems
Helen Lurie, BitBeam Technologies – Payload
James DiCorcia, Deep Space Industries – Subsystems

1.4
The following people were present at the Preliminary Design Review. Review Item Discrepancies
(RIDs) were submitted in writing.
Jeff Garzik, CEO and founder, Dunvegan Space Systems
Johnathan Corgan, Principal, Corgan Labs
Gary Barnhard, President & CEO, Xtraordinary Innovative Space Partnerships, Inc.
Ryan Nugent, Co-Principal Investigator, CubeSat Program at Cal Poly in San Luis Obispo
Samantha Infeld, Senior Project Engineer, Analytical Mechanics Associates, Inc.

1.5
The acronyms and abbreviations used in this document are defined in the following table.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 8 OF 98

Table 1: Acronyms used in this document

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 9 OF 98

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 10 OF 98

2.0
Bitcoin is a currency that aims to have no central administration, a true open-source and democratic
method of exchanging value between people. However, the exchange of bitcoins is limited by the
ability of servers to interact amongst themselves, lag-times between interactions, and the reliability
of data being transferred. Bitcoin relies on the network consensus concerning bitcoin “blocks”, which
users build by computing data on existing blocks. The network consensus is in regard to which blocks
constitute the true bitcoin block chain. Network lag, malicious denial of service, and other
miscellaneous causes of network disparity which would lead to a loss of network consensus, are all
problems that the BitSat network will address.
B1 is a technology demonstration mission to prove the BitSat concept on orbit. B1 consists of three
independent and identical spacecraft which will test state of the art COTS hardware as a preliminary
BitSat constellation. The fleet will perform orbit phase maintenance, attitude control, and
communication with a ground network to demonstrate software reliability and build operational
capability to maintain a larger BitSat constellation.
This mission, B1, is a feasibility test for the larger BitSat constellation mission, referred to as “B2”. B1
will be a scaled-down demonstration of the BitSat satellites’ station-keeping and orbital
maintenance, as well as bitcoin transfer algorithms and the maintenance of data aboard the
spacecraft. The satellites that make up the B1 space segment may be used as constellation satellites
in B2 depending on B1 mission outcomes, however this is an extended mission objective.
The B2 mission will place an entire constellation of BitSat satellites in orbit to provide minimal-
latency bitcoin data transfer between the peer-to-peer bitcoin network and remote corners of the
world or places temporarily isolated from the network.

2.1
The following are the B1 mission objectives, which define the scope of this project
1. Demonstrate and characterize the performance of the payload and the supporting satellite
bus
2. Demonstrate operational capability and systems management of the project
3. Perform limited constellation maintenance as a proof of concept for the B2 BitSat
constellation

2.2
A summary of the B1 project scope is provided in the following table.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 11 OF 98

Table 2: Tasks that fit within/outside of the B1 mission scope

- -
-

2.3

Figure 1: B1 hardware and software deliverable items with optional Engineering Model

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 12 OF 98

The complete B1 mission will deliver three Protoflight satellites, a ground segment (including designs
for salable units), and tentatively an EM unit for debugging while the satellites are on orbit. These
satellites will be accompanied by the necessary documentation for on-orbit operations. The scope of
B1 includes acquiring FCC licenses for transmission of bitcoin data and TT&C, securing three launches
and operation for the B2 constellation.
BitSat is particularly unique in its focus on the community, and in the end-user interface. B1 tests the
hardware and software required for the B2 mission, and designs but does not commercialize the
required ground equipment for a bitcoin user to receive transaction information from orbit. It is
important to refer back to the scope of the mission often, and recognize that B1 is three identical
experimental satellites, where the B2 constellation is a decentralized commercial fleet of arbitrary
size.

2.4
The table below shows a timeline of the milestones of the mission, including projected dates for
milestones following a contract signing for the B1 mission. This timeline is dependent on subsystem
suppliers delivering and launches being available in a timely manner.

Table 3: Milestone Timeline of BitSat project

Initial Contract May-July 2014
Kick-off Meeting May 14, 2014
B2 System Requirements Review May 23, 2014
B2 Concept of Operations Review June 4, 2014
B1 System Requirements Review June 4, 2014
B1 Concept Design Review June 16, 2014
B2 Concept Design Review June 16, 2014
B1 Concept of Operations Review June 26, 2014
B1 Preliminary Design Review July 27, 2014
Build Contract Signed Contract Sign Date
Major Parts Ordered CSD + 1 month
Critical Design Review CSD + 3 months
Subsystems Arrive CSD + 4 months
Assembly Complete, Test Readiness Review CSD + 6 months
Flight Readiness Review CSD + 8 months
Launch of Demonstration Mission CSD + 9 months

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 13 OF 98

3.0
The system engineering assesses requirements, operations, interfaces, and technical risks at the
system level. PDR-level system engineering attempts to show that the concept is feasible while
setting realistic milestones and timelines for the detailed satellite design, ultimately answering the
question, “can this preliminary design fulfill the mission objectives?”

BITSAT PRELIMINARY DESIGN REPORT

 DEEP SPACE INDUSTRIES BITSAT PRELIMINARY DESIGN REVIEW | PAGE 14 OF 98

3.1
Table 4: Mission Requirements Matrix
Req #

Verification
Title Requirement Comment Verification Overview Method

Analysis of latency. May also demonstrate

"distribution" in lab using setup
BitSat B1 system SHALL test
Distribute latest Latency across the network is the constraint representative of orbital geometries. If
M1 distribution of the latest block to Analysis
block on distribution time testing, ground terminals involved in
receiver stations
latency testing must maintain accurate
network time.
This is a useful but secondary goal. The
BitSat B1 system SHALL perform
Distribute recent scheduling algorithm will be developed with Demonstrate in lab using setup
M2 network tests of transmission of Demonstration
blocks community input after the space representative of orbital geometries
recent blocks or transactions
communications capacity is known.
BitSat B1 satellite transmission It may be in the economic interest of users
Block transmission SHALL not be interrupted during that interruption does occur. Address this at Prioritize transmit/receive order, ground
M3 Test
non-interruption block transmission, to start the same time that we look at the scheduling test of flight software
transmitting another block. algorithm.
BitSat B1 system SHALL test When the tail of the buffer is reached,
Continuous block Long duration test on ground, to make
M4 continuous transmission from transmission immediately begins anew at the Test
transmission sure it doesn't stop.
satellites buffer head

The BitSat B1 satellites SHOULD This makes the satellite a full trusted node,
M5 Satellite storage Ground test of flight software Test
store the entire blockchain which achieves the "hardening" requirements.
The BitSat B1 satellites SHALL
Most likely, we can store the whole blockchain
add new blocks to the tail of its
Satellite Block on the satellite. Scheduling algorithm should Ground test of "schedule buffer"
M6 buffer, dropping one or more Test
Retention determine which is sent when. The "buffer" components of flight software
blocks from the head of the
becomes a "schedule buffer".
buffer.
This requirement became unnecessary when
BitSat B1 system SHALL have
the spacecraft design achieved a true bitcoin
hardened uplink nodes that
Hardened* Uplink node, performing block verifications. It
M7 transmit bitcoin blocks to the Ground station authentication Inspection
Nodes continues to be useful to implement CDMA (or
satellite(s), as they appear on the
other anti-jamming techniques) + Com link
network.
Authentication

– CONFIDENTIAL –
DEEP SPACE INDUSTRIES BITSAT PRELIMINARY DESIGN REVIEW PAGE 14 OF 98
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 15 OF 98

BitSat B1 uplink nodes SHALL

Uplink nodes
have protections and gaps in These are not trusted bitcoin nodes; these are Design review of Ground station concept
M8 separate from P2P Inspection
place separating them from the hardened bitcoin nodes, of operations
network
primary P2P network
BitSat B1 uplink notes SHALL
Uplink send bitcoin blocks in a reliable, Note that having the entire block chain
M9 Uplink security verification Test
Authentication digitally authenticated data provides this authentication.
envelope to satellite
BitSat B1 downlink stations
Compatible with
SHALL be compatible with
M10 Inexpensive Review of Downlink Station point-design Inspection
personal use ground terminals
Downlink Station
using sub-$10,000 hardware
When one or more new bitcoin
Downlink station blocks appear in the data, the
Downlink station does not do processing. It is
M11 communication to BitSat B1 downlink stations Demonstrate in lab Demonstration
not a bitcoin node.
client SHALL submit this block to the
local client for data processing.
BitSat B1 system SHALL consist
Satellite
M12 of a constellation of satellites Design Review Inspection
Constellation
within one plane
BitSat B1 satellites SHALL be
B1 shall be operated by DSI/DSS, but B2 long-
built with commercial off the
Open-Source term philosophy is that the community is able
M13
Design
shelf (COTS) hardware and an
to design, improve, and manufacture new
Design Philosophy Inspection
available design report (CubeSat
BitSats.
parts when possible)
* “Hardened” uplink nodes are a customer-derived requirement intended to be secure from cyber-attack to upset operations without being
entirely secured and controlled by a single organization. This definition is non-specific by design, and the strict hardening features are to be
determined in the detailed design. This is addressed as an Action Item in Section 7.1.

BITSAT PRELIMINARY DESIGN REPORT PAGE 15 OF 98

 DEEP SPACE INDUSTRIES BITSAT PRELIMINARY DESIGN REVIEW | PAGE 16 OF 98

3.2
The concept of operations describes the spacecraft activities and behavior during different phases of
the project. Each phase of the mission can then be broken down into subcategories detailing at very
low-levels the status and progression of the spacecraft. These activities are strongly coupled to the
mission requirements, and at low enough of a level, the sub-phases of a good set of ConOps are
indistinguishable from an hourly Gantt chart.
For the purposes of the preliminary design, high-level mission phases have been defined, with some
sub-phase activities only described when details within them are essential to accomplishing the
mission objectives. Subsystem-level ConOps are shown in Section 4 Subsystems, with the parent
document containing mission level and subsystem level in parallel.

– CONFIDENTIAL –
DEEP SPACE INDUSTRIES BITSAT PRELIMINARY DESIGN REVIEW
 DEEP SPACE INDUSTRIES BITSAT PRELIMINARY DESIGN REVIEW | PAGE 17 OF 98

Table 5: Mission Level Concept of Operations Activities

Mission Level Activities
Phase Activity Description
1 Payload Manufacture and Engineering model and flight models, built and tested by BitBeam in California
Testing
2 FlatSat testing FlatSat (table-top satellite) built at integration station. Functional test (software upload) and limited payload test will occur during this phase
3 Integration into bus DSI will integrate the payload into the bus at its California facility
4 Environmental Testing Test philosophy: Three proto-flight models (PFM). Testing with NASA Ames environmental test facilities. Use worst-case of standard CubeSat test
specs and those provided by the launch provider.
5 Storage Upload blockchain to the spacecraft before shipping
6 Launch site testing Ship the CubeSat to the launch provider in a Peli-case. Check out and charge battery and upload blockchain at launch provider facility and put
satellite into the deployer. Launch provider ships to launch site. Check out and upload blockchain and charge at launch site.
7 Launch Any LEO will do. Three satellites total on three separate launch vehicles (for lowest reasonable risk). Design altitude at 750 km
8 Check-out and commissioning TT&C ground station by DSI (location TBD). Mission control at DSI office in California. Tracking by NORAD. Upload TLE's and time and missing blocks
mined since last upload. Download and check telemetry. Full functional check. Commission ADCS. Test small, mobile ground station for operations.
9 Operations Testing Uplink the block chain. Test with receive stations. Broadcast metadata. Test with uplink stations. Broadcast block chain. Test during sunlight and
eclipse with a "friendly user" on the other side of the world.
9a Station Keeping, Phase Periodic phase and altitude maintenance maneuvers over the operational lifetime of the spacecraft
maintenance
10 Transition to eclipse Solar power drops to zero and the satellite continues to operate from batteries.
11 Transition to day Solar power is available to charge the battery.
12 Telemetry collection Spacecraft telemetry is collected every 10 seconds, by default. Telemetry is downlinked only when requested from a ground station, on the TT&C
communications link. Spacecraft control is via TT&C link.
13 Uplink blockchain Uplink terminal uploads one or more blocks. Break the block into smaller packets and use heavy forward-error-correction to ensure packets get
through on uplink given lossy RF link. Satellite broadcast includes requests for the next/missing block. Blocks are verified on-board the satellite.
14 Blockchain broadcast One block is broadcast in 30 seconds, with sufficient link robustness/redundancy to handle lossy RF link. In a typical 8 minute pass a user will
receive up to 16 blocks. A typical user on a typical day can receive metadata for 64 blocks from one satellite; however there will be duplication in the
received data.
15 Blockchain Metadata Transmit blockchain metadata for a block (65 kb per block) in 2 seconds, with sufficient link robustness/redundancy to handle lossy RF link.
broadcast Interspersing 5 meta-data packets with each block, a typical user on a typical day can receive metadata from 320 blocks from one satellite; however
there will be duplication in the received data.
16 System Optimization Based on user feedback, increase or decrease the link robustness (trade-off is transmission speed) and change algorithm for prioritization of most
recent block.
17 End of Mission BitSat continues to operate until it is commanded to shut down its transmitter, or it dies from radiation damage or other causes.
17a Optional: Active De-orbit BitSat may, in the case that remaining propellant is onboard after mission critical systems have shut down, actively de-orbit to decrease orbital decay
lifetime.
17b Passive De-orbit After being in orbit for between 1 year and 25 years the satellite orbits will naturally decay due to drag and will burn up on re-entry into the
atmosphere.
18 Data Analysis Write a report recommending how to move to an operational system

– CONFIDENTIAL –
DEEP SPACE INDUSTRIES BITSAT PRELIMINARY DESIGN REVIEW PAGE 17 OF 98
 DEEP SPACE INDUSTRIES BITSAT PRELIMINARY DESIGN REVIEW | PAGE 18 OF 98

3.3

Figure 2: The BitSat Satellite (side panel removed)

The BitSat B1 satellites were initially intended to be partial blockchain distribution relays, but with
the capacity to hold the entire blockchain on orbit as designed, they will act as fully participating
nodes in the bitcoin distribution network. Each BitSat satellite will receive updated blocks and block
headers from the uplink station on an S-band uplink and will downlink a “transmission buffer”
information package back to the receiver module. The transmission buffer includes only information
on the most recent block and the block header metadata. The satellites will queue block chains and
add new information to the chain as it is received. Algorithms will determine latency and how many
blocks to send back to the receiver station module when the satellites pass over it.

The spacecraft are designed to be robust to failures, auto-recovering from a range of possible
software problems and requiring little operational maintenance. Each spacecraft will check that
received blocks are valid, error-free and up-to-date, and will make this status information available in
its broadcast. BitSat satellites will verify all new blocks, and can also be commanded to check the
entire block chain to determine if there is any data corruption in the Flash memory storage.

The satellite is designed for 256 GB of flash memory on two separate 128 GB SD cards. The current
blockchain, as of 8/10/2014, is just over 20 GB, with a difficult-to-predict-but-somehow-linear
apparent growth rate of 8 GB per year. At least for the next five years, it is likely that the BitSat
hardware will remain capable of storing and checking the blockchain without significant upgrades,
even while storing the blockchain with complete redundancy.

– CONFIDENTIAL –
DEEP SPACE INDUSTRIES BITSAT PRELIMINARY DESIGN REVIEW
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 19 OF 98

3.4
BitSat will transition through different modes during and after launch, with the possible steps
between modes shown in Figure 3. All modes can switch to OFF, but as an example, the spacecraft
cannot instantly transition from Safe to Pointing (i.e. it must go through Unpointed mode). This mode
diagram lays the framework for software development.

Figure 3: All possible spacecraft modes and their transition paths.

Table 6: Description of each spacecraft mode's function.

Mode Definition
Spacecraft is off (all power lines disconnected) during launch and when the EPS
Off
detects a battery voltage below the hard low-voltage limit.
Boot Default mode after a hard reset.
Load Code Ground control uploads of software to the OBC.
Deploy Deployable solar panels and whip antennae deploy sequentially.
Safe Default mode after a soft reset. Only essential systems online.
When the spacecraft is tumbling non-negligibly, ADCS actuators will slow the rate of
Detumble
tumble over several orbits.
Payload on. Actuators at rest. Attitude sensors may be turned on. The spacecraft is
Unpointed
free to tumble.
Payload on. The spacecraft points towards a specific direction, e.g. greatest profile for
Pointing
solar power collection.
Orbital The spacecraft performs station-keeping to keep in phase with the constellation.
Maintenance About 1-2 minutes of payload downtime may occur during this mode.

3.4.1
In the following table, shaded boxes are designated to components and subsystems that are on
during any given operational mode. Un-shaded boxes are for components and subsystems that are
BITSAT PRELIMINARY DESIGN REPORT
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 20 OF 98

off. Textured boxes indicate components and subsystems that are optional for Unpointed mode,
based on ground command.

Table 7: Graphical table showing on/off states of components during each mode.
Subsystems ADCS GNC
EPS OBC TT&C Payload Sun- Cold
MTM MTQ Gyro RWs
Modes Sensor Gas
Off
Boot
Load Code
Deploy
Safe
Detumble
Unpointed
Pointing
Orbit
Maintenance

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 21 OF 98

3.4.2
The satellite will transition between modes as required based on a set of different events. The table
below provides the definitions of the events or triggers that cause mode transitions.

Table 8: Definitions of mode transition triggers

Event Type Definition
Scheduled Scheduled tasks are run by functions running within the on-board
SCHD
Task computer and EPS that run in an interval.
Soft resets to bring the spacecraft into Safe Mode. This disengages it from
potentially harmful situations or behaviors, and allows for the system to
SRST Soft Reset
“get its bearings”. Examples include OBC-measured low battery voltage
and ground command.
If the OBC freezes, the EPS WDT will power cycle the spacecraft, returning
HRST Hard Reset it to Boot Mode. Ground Control can also hard-reset a spacecraft,
bypassing the OBC.
Attitude Determination and Guidance, Navigation, & Control sensors
SENS Sensor determine that an action should be taken by the spacecraft, e.g. the
spacecraft is tumbling uncontrollably.
Ground Control or flight software specifically tells the spacecraft to run a
CMD Command
command.

There are two one-time mode transitions:

DEP, for Deploy, happens when the spacecraft deploys from its deployer.
FLAG is a flag set in code that turns itself off once it is triggered. It is used to deploy the solar
panels and whip antennae sequentially. If the flag fails, it is also possible to command from
the ground.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 22 OF 98

Table 9: A tabular layout of how modes transition.

Maintenance
Unpointed
Load Code
To

Detumble

Pointing
Deploy

Orbital
Boot

Safe
Off

From
Off DEP,
- - - - - - - -
SENS
Boot CMD, CMD,
HRST SRST FLAG - - - -
SCHD SCHD
Load Code HRST SRST - - SCHD - - - -
Deploy HRST SRST - - SCHD - - - -
Safe SCHD,
HRST - CMD - CMD CMD CMD CMD
SRST
Detumble CMD,
HRST SRST - - - - - -
SCHD
Unpointed HRST SRST - - CMD - - CMD -
Pointing HRST SRST - - CMD - CMD - CMD
Orbital CMD,
HRST SRST - - - - CMD -
Maintenance SCHD

3.5
Components are selected to minimize mass, power, volume and complexity to accomplish the
mission requirements from Table 4. The margin philosophy ascribes a different margin depending on
the maturity level of the components, as follows:
Hardware which has previously flown will carry a mass margin of 5%.
Hardware which has been built at an Engineering Model will carry a mass margin of 10%.
Hardware which has yet to be fabricated will carry a mass margin of 25%.
With margin, the B1 spacecraft has an estimated mass of 3.984 kg. This is below the maximum mass
allowed by the CubeSat Standard1.

1
Revision 13, CubeSat Design Specification, 2-20-2014. Section 3.2.13: The maximum mass of a 3U CubeSat
shall be 4.00 kg
BITSAT PRELIMINARY DESIGN REPORT
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 23 OF 98

Table 10: Spacecraft mass budget

Without Contingency Including

contingency contingency
(kg) (kg)
% (kg)
Satellite Subsystems
Payload (S-band) MP/L 0.050 10.00% 0.005 0.055
ADCS/GNC Mgnc 0.723 6.23% 0.045 0.768
On-Board Computer Mobc 0.096 4.90% 0.005 0.099
TT&C Mcomm 0.280 8.48% 0.024 0.304
Structures Mstruct 0.580 5.00% 0.029 0.609
Power Mpower 1.452 5.00% 0.073 1.525
Propulsion Mpropulsion 0.350 25.00% 0.088 0.438
Wiring and Fittings Mwiring 0.150 25.00% 0.038 0.188
Satellite total mass Mtotal 3.681 8.29% 0.305 3.984

3.6
The power budget confirms that the spacecraft is power-positive in worst-case conditions in all
operating modes. There are several aspects to this:

The battery state of charge is maintained above 80% such that it does not experience a
decrease in capacity or efficiency from repeated deep cycles.
Recharging the battery from a worst-case eclipse is possible within one orbit.
Peak current never exceeds maximum power system current limits in any operating mode.

Table 11: Power Consumption in modes where ADCS/GNC and Propulsion are off
Subsystem Peak Power Safe Mode Payload-only Mode
Duty
(W) Cycle Average Duty Cycle Average
OBC 0.4 100% 0.4 100% 0.4
Power 0.1 100% 0.1 100% 0.1
TT&C - Rx 0.2 100% 0.2 100% 0.2
TT&C - Tx 1.7 15% 0.3 15% 0.3
ADCS 5.1 0% 0.0 0% 0.0
GNC 6.0 0% 0.0 0% 0.0
Payload 5.0 0% 0.0 100% 5.0

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 24 OF 98

Total
Power 18.5 1.0 6.0

Table 12: Power Consumption in modes where ADCS/GNC and Propulsion are on
Orbital Maintenance
Subsystem Peak Power Pointing Mode Mode
Duty Duty
(W) Cycle Average Cycle Average
OBC 0.4 100% 0.4 100% 0.4
Power 0.1 100% 0.1 100% 0.1
TT&C - Rx 0.2 100% 0.2 100% 0.2
TT&C - Tx 1.7 15% 0.3 15% 0.3
ADCS 5.1 100% 2.5 0% 1.2
GNC 6.0 0% 0.0 25% 1.5
Payload 5.0 100% 5.0 100% 5.0
Total
Power 18.5 8.5 8.6

Table 13: Battery Discharge Rates in different modes

Orbital
Payload-only Pointing
Battery Depth of Discharge Units Safe Mode Maintenance
Mode Mode
Mode
Worst case eclipse duration % 40% 40% 40% 40%
Worst case Orbit Period sec 6,300 6,300 6,300 6,300
Eclipse duration sec 2,520 2,520 2,520 2,520
Min Battery Voltage V 12.0 12.0 12.0 12.0
Eclipse current mA 82 498 704 720
Eclipse Discharge mAh 57 349 493 504
Battery Capacity mAh 5,200 5,200 5,200 5,200
Depth of discharge % 1% 7% 9% 10%
Margin (% of battery capacity) % 19% 13% 11% 10%
Design Depth of Discharge % 20% 20% 20% 20%

Table 14: Battery Recharge Rates in different modes with worst-case attitude for power production

Payload-only Pointing Orbital

Recharge Units Safe Mode
Mode Mode Maintenance

Average solar power (in sun) W 3.1 8.8 27.3 27.3

Time in sun sec 3,780 3,780 3,780 3,780
Converter efficiency (worst case) % 80% 80% 80% 80%
Available Power W 2.5 7.0 21.8 21.8

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 25 OF 98

Power available to charge batteries W 1.5 1.0 21.8 13.2

Battery efficiency (worst case) % 80% 80% 80% 80%
Energy deficit in eclipse J 3,087 18,837 26,624 27,226
Time to recharge sec 2,016 18,468 1,219 2,063
Margin sec 1,764 -14,688 2,561 1,717
Margin (% of time in sun) % 47% N/A 68% 45%

Table 15: Worst Case peak current

Subsystem Peak Power Units
/ Current
OBC 0.4 W
Power 0.1 W
TT&C - Rx 0.2 W
TT&C - Tx 1.7 W
ADCS 5.1 W
GNC 6.0 W
Payload 5.0 W
Total Power 18.5 W
Min Battery Voltage 12.0 V
Max Battery current 1.5 A
Battery Current Limit 12.0 A
Battery Current Margin 87%
Regulator Voltage 5.0 V
Max Regulator Current 3.7 A
EPS Current Limit 4.0 A
Regulator Current
8%
Margin

Deployable panels were necessary to provide sufficient worst-case, full-orbit power. Sufficient power
and current margin exists in all modes.

3.7
Bitcoin blocks will be received and transmitted by the payload, a BitBeam 2450 radio. The capabilities
of the payload determines how fast the spacecraft can send out bitcoin blocks, and thus how much
data can be transmitted to a receiver station during a satellite pass. As the BitSat spacecraft will be
placed in LEO, they will pass over each station in under 15 minutes, between 4 and 14 times per day
per satellite.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 26 OF 98

Table 19: Payload Downlink and Uplink Budgets

Downlink Including
Size Data Rate Contingency
Time in Mission time Contingency
(kb) (s) (kb/s) (%) (kb/s)
Block 1000 30 33.33 50% 50.00
Meta-Data 65 2 32.50 50% 48.75

Maximum (one downlink operation at a time) 50.00

Margin (% of downlink design rate) 50%
Downlink design rate 100
Including
Size Uplink time Data Rate Contingency
Time in Mission Contingency
(kb) (s) (kb/s) (%) (kb/s)
Block 1000 10 100.00 50% 150.00
Meta-Data 65 1 65.00 50% 97.50

Maximum (one uplink operation at a time) 150.00

Margin (% of uplink design rate) 85%
Downlink design rate 1,000
Considering acquisition times, B2 orbit configurations and other aspects of the B2 satellite
constellation, the BitSat data link budget allows for sufficient information to be sent across to clients,
protecting against network disparity. B1 will demonstrate operations at these same data rates.

3.8
The design philosophy with regards to processing is that very large hardware margins are desirable to
account for software growth. The approach to the spacecraft design uses margins with 100%
contingencies for every needed process.
The OBC will contain 256GB of flash drive space that will be used to store the bitcoin block chain as it
grows over time, as well as a number of back-ups that will be cross-referenced at intervals to ensure
that file corruption is avoided or repaired. It is noted that this is more than twice the design goal of
120GB.
Should future iterations of BitSat need more data processing power, the physical architecture, mass
and power budgets, all allow for the addition a daughter-board to the OBC or even additional radio
transmission hardware. While not an integral part of the design of this platform, the prospect of
upgradeability has been considered.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 27 OF 98

Table 20: OBC RAM Budget

Estimated Including
Contingency
Memory Usage Contingency
(kb) (%) (kb)
BootLoader 1,000 100% 2,000
RTOS 4,000 100% 8,000
Telemetry Gathering 100 100% 200
ADCS 100% 0
SGP4 orbit propagation 100 100% 200
IGRF magnetic field model 1,000 100% 2,000
Payload Handling 100% 0
Commuications buffer 1,000 100% 2,000
Block Verification 1,000 100% 2,000
TOTAL 8,200 16,400
Margin (% of OBC memory) 49%
OBC Memory Size 32,000

Table 21: Payload Flash Budget

Start (July
1 year 5 year
Time in Mission 2015)
(MB) (MB) (MB)
Block Chain 28,000 38,000 100,000
Telemetry (10 days storage buffer) 69.12 69.12 69.12
TOTAL 28,069 38,069 100,069
Margin (% of design flash size) 77% 68% 17%
Design Flash Size 120,000 120,000 120,000

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 28 OF 98

4.0
The BitSat spacecraft design is based on the 3U CubeSat form-factor. This section will primarily give
an overview of the major hardware components with regards to making BitSat a capable platform for
its mission. Requirements for each subsystem are given and addressed with subsystem components
that are determined to adequately fulfill the needs of the mission. Software flow schemes have been
developed, but PDR readiness does not necessitate fully documenting the final algorithms.
Each subsystem is presented with its own concept of operations (ConOps), which parallels the
Mission Level ConOps from Section 3.2.
The subsystem overviews will be presented in the following order, loosely matching the physical
“stack” of the components:
1. Interfaces Overview
2. Payload
3. Power
4. OBC (and revisiting spacecraft modes)
5. Structure and Thermal
6. ADCS/GNC
7. TT&C
8. Propulsion
9. Software and Payload Handling

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 29 OF 98

Figure 4: BitSat B1 CubeSat Stack Assembly

The BitSat B1 CubeSat stack assembly is shown in Figure 4, showing the layout of all the subsystems.
The gaps between the circuit boards are quite small, and during integration these will be occupied by
wire bundles, cables, tie-downs and such items.

CubeSats are inherently modular, although with certain caveats. In a sense, replacing a component or
subsystem is possible, even late in the design process. However the interfaces and interactions
between components and subsystems must be carefully considered, as it is common that one change
result will require several others changes and a much expanded and extended effort for assembly,
integration and testing.

4.1
CubeSat interface simplicity reflects the cost-savings of COTS spacecraft. Components are designed
to be compatible with each other to a reasonable degree, and the shared I2C bus (GPIO pair) through
the PC104 backplate attempts to provide straightforward communication between components with
minimal harnessing (resulting in small but non-negligible mass savings) at the expense of data
transfer speed and connector size. The data and power interfaces are shown in Figure 5.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 30 OF 98

Figure 5: BitSat B1 data and power interfaces diagram

Care must be taken with I2C and other data busses to avoid long cable or track lengths that lead to
excess capacitance and susceptibility to Electro-Magnetic Interference (EMI). Where I2C is not
suitable for high data rates (such as between cameras and computer), USB is used. The detailed
design will assess wire routings, capacitance and EMI.

Power supplied by the EPS is regulated at 5 V and 3.3 V, with unregulated power at battery voltage
(12 to 18V).

4.2
The payload transponder and software is at the heart of the B1 design. This transponder is the
BB2459 being developed by BitBeam technologies. Command and handling software will be
performed by the OBC at all times on orbit. The current design assumes S-band transmission on two
monopoles located perpendicular to the UHF and VHF monopoles used by the TT&C.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 31 OF 98

4.2.1

Phase Activity Payload Software Payload Hardware

1 Payload Test software developed. Documented Test reports generated and hardware
Manufacture delivered to DSI for integration.
and Testing
2 FlatSat testing Run and update flight software during Performance parameters tested. Data
FlatSat stage. throughput clocked between OBC and
payload. End-to-end blockchain
communications tests.
3 Integration into N/A N/A
bus
4 Environmental Update performance parameters to reflect Run block uplink, downlink, during T-VAC.
Testing safe operations in simulated space
environments
5 Storage N/A N/A
6 Launch site Upload new software at launch site if N/A
testing necessary
7 Launch N/A
8 Check-out and Run health check Check telemetry
commissioning
9 Operations Uplink the block chain. Test with receive stations. Broadcast metadata. Test with uplink
Testing stations. Broadcast block chain. Test during sunlight and eclipse with a "friendly user" on the
other side of the world.
9a Station
Keeping, Phase Power off during station keeping
maintenance
10 Transition to
Continue normal ops
eclipse
11 Transition to
Continue normal ops
day
12 Telemetry
N/A
collection
13 User uplink Uplink terminal uploads one or more blocks. Break the block into smaller packets and use
blockchain heavy forward-error-correction to ensure packets get through on uplink given lossy RF link.
Satellite broadcast includes requests for the next/missing block. Blocks are verified on-board
the satellite.
14 Blockchain One block is broadcast in 30 seconds, with sufficient link robustness/redundancy to handle
broadcast lossy RF link. In a typical 8 minute pass a user will receive up to 16 blocks. A typical user on a
typical day can receive metadata for 64 blocks from one satellite, however there will be
duplication in the received data.
15 Blockchain Transmit blockchain metadata for a block (65 kb per block) in 2 seconds, with sufficient link
Metadata robustness/redundancy to handle lossy RF link. Interspersing 5 meta-data packets with each
broadcast block, a typical user on a typical day can receive metadata from 320 blocks from one satellite,
however there will be duplication in the received data.
16 System Change algorithm for prioritization of most recent block, make software or parameter
Optimization changes to increase robustness
17 End of Mission N/A Turn off payload
17a Optional:
N/A
Active De-orbit
18 Passive De-
N/A
orbit

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 32 OF 98

19 Data Analysis N/A

4.2.2

Figure 6: Development board and PCB schematic of the BB2450 prototype, built and tested.

The BitSat payload is a software defined radio designed by BitBeam Technologies, providing 1-2
Watts RF output and built on a PC104 form-factor. The BB2450 will be launched on a satellite in
December 2014.

The power output can be varied by command from the OBC. To achieve best results using the power
available and considering variable weather attenuation, it is intended to increase transmit power
when the spacecraft is over the tropics and reduce it when it is over desert areas.

The B1 BitSat is designed to transmit on S-band because the payload for this band has been
developed, and the ISM band can be used without significant expenses in FCC negotiations.

4.3
The B1 power system takes power from the solar array, distributes it to the subsystems and manages
battery charging and discharging. The solar array configuration necessitates active pointing of the
spacecraft to obtain maximum power.
The GomSpace EPS (P31uS) was selected. A battery is required for operating in eclipse and during
peak power modes. To maintain the battery at above 80% start-of-charge, the battery pack consists
of four lithium batteries (GomSpace BP4).

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 33 OF 98

4.3.1
Phase Activity Power
1 Payload N/A
Manufacture and
Testing
2 FlatSat testing Power supplies for testing are high quality benchtop with low ripple current. Facility
ground to Earth verified initially then periodically. FlatSat is tested with wall power to
components. Flight power system itself tested independently. Solar panels tested in
external facility with 1 AU light source (i.e. take them outside)
3 Integration into Power system requires safe handling and a clean facility. Assembly performed with
bus sufficient anti-static surfaces.
4 Environmental Power supplies for testing shall be high quality benchtop with low ripple current. Facility
Testing ground to Earth verified periodically. Verify solar panels CAN charge batteries during
TVAC and functional test.
5 Storage Inspect connectors, mounting, panel wear, and battery charge. Disconnect flight battery
for storage. Disconnect main power
6 Launch site Batteries shall be charged at the launch site.
testing
7 Launch Pre-launch, check battery life and perform final testing. Ensure that ground is still ground.
Perform appropriate ceremony to the patron goddess of Babylon for the safety of B1
during launch. Solar panel deployment if and only if tumble is within safe rotation
threshold after launcher deployment
8 Check-out and Test nominal, minimal, and peak current power cycles. Peak test over short duration
commissioning during station keeping test. Orient panels for maximum output. Check operational
parameters. Functional test operational modes under reduced power output. If sun
synchronous (likely), confirm
9 Operations Check battery current/voltage during testing. Solar panel output changes over time. Log
Testing panel performance. Log electrical connector possible changes (ohm differences).
9a Station Keeping, Check that initial peak current is still the same as former peak current. Ground contact
Phase required for data comparison.
maintenance
10 Transition to Check battery voltage during thermal cycling and ensure safe operational limits are
eclipse maintained. Verify solar panel output from partial to eclipse and back to full sunlight. If SS
orbit, modify expectations.
11 Transition to day Monitor battery voltage and overall power performance with temperature changes
12 Telemetry Continue providing operational power to subsystems. Check power parameters on the 10
collection second cycle and transmit out of schedule if normal thresholds are breached.
13 User uplink Continue providing operational power to subsystems. Check power parameters on the 10
blockchain second cycle and transmit out of schedule if normal thresholds are breached.
14 Blockchain Continue providing operational power to subsystems. Check power parameters on the 10
broadcast second cycle and transmit out of schedule if normal thresholds are breached.
15 Blockchain Continue providing operational power to subsystems. Check power parameters on the 10
Metadata second cycle and transmit out of schedule if normal thresholds are breached.
broadcast
16 System Continue providing operational power to subsystems. Check power parameters on the 10
Optimization second cycle and transmit out of schedule if normal thresholds are breached. Update
expected power budge based on user feedback.
17 End of Mission Power output may decrease over time. Potential failure mode. This is a slow death most
likely. Transmit power may decrease over time. Power may not be able to run MTQ and
wheels, then S/C may die.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 34 OF 98

17a Optional: Active Power may be fed through propulsion and ADCS exclusively during this operational phase.
De-orbit Thermal overheat is not ideal. Some propellant should remain onboard in case B1 needs
to avoid debris, reorient, etc. Warm gas heatup will increase delta-v, so overheating may
be acceptable for this case.
18 Passive De-orbit Safemode or dead
19 Data Analysis N/A

4.3.2

The BitSat spacecraft is based on a highly-capable 3U CubeSat

platform, however the platform needs more power than 3U
satellites typically produce.
Clyde Space solar panels were chosen as they have a history of
reliability and are one of the standards for the field. They have to-
order deployable panels that deploy in the profile shown in Figure
6, with any deployment angle desired. For BitSat a deployment
angle of 90 degrees will be used.
The “Deployable Solar Panel” array consists of one face of panels
attached to the main structure, coving a face 300 x 100 mm2, as
well as one face that deploys outwards from the same side. Four
of these together, one on each long faces of the satellites, will
collect solar power from the sides as well as a main array of 28
cells on the deployable panels.

Figure 7: Deployed Clyde Space solar Customization of the panel to provide slots in the body-mounted
panels. solar panels will allow for antenna deployment. The power losses
from this modification are negligible and the cost is small.
Additionally, one 100 x 100 mm2 body mounted panel may be placed on the “top” surface of the
spacecraft (+z axis, opposite propulsion) if the additional 2W is required to close the power budget.
However it does not appear that this is necessary for this spacecraft.
The power budget is shown in in Section 3.6, Table 11 and Table 12, for various spacecraft modes.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 35 OF 98

4.3.3

The GomSpace P31us has significant flight heritage, and known reliability and robustness. DSI
personnel have these boards on CubeSats and cite the P31 series as “bulletproof”. Compared to its
competitors, the GomSpace unit outperforms in most categories, has lengthy flight heritage, and is
recognized as the best in the market.
The P31us can handle up to 60W of power from solar panels, and is designed to operate with
deployed solar panels.
It has been verified that this EPS can handle the worst-case peak current required by the system,
with details provided in Table 15.

4.3.4

GomSpace’s BP-4 battery pack contains four 1300mAh lithium-ion batteries. Analysis presented in
Table 13 shows that the expected depth of discharge is below the desired maximum of 20% (i.e. state-
of-charge remains above 80%). The recharge time after a worst-case eclipse is shown in Table 14 to
be shorter than the minimum time-in-sun, such that the battery will always be fully charged going
into eclipse.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 36 OF 98

4.4 -
The On-Board Computer (OBC) is implemented as a single, central processing board. This board must
have several data interfaces to support the BitSat architecture:
I2C
USB
SPI
Analog Inputs
GPIO
All computational modules are run as tasks on this computer, on a Real Time Operating System
(RTOS).

4.4.1

Phase Activity Computing CDH Software

1 Payload N/A N/A
Manufacture
and Testing
2 FlatSat testing Test software uploaded and verified with Upload FlatSat test software to OBC.
hardware-in –the-loop simulation, then Anticipate frequent software rewrites
integrated to flight hardware for functional during this phase.
ground disassembled testing.
3 Integration Flight computer shall be disassembled from Upload environmental testing
into bus FlatSat config to integrated config. Data and software
power lines removed, then rerouted and
installed during assembly of the other systems.
4 Environmental Flight computer will test on-board sensors. Update test parameters with
Testing Compare to external test sensors. Calibrate calibrated values.
hardware and update flight and test software.
Run wired upload and wireless upload of test
software.
5 Storage Duplicate on-board software during storage Save test/flight software. Store data
and check for parity after unpacking. on external HDD kept with B1. Track
updates post testing and determine
software upload schedule for launch
site testing
6 Launch site Upload new flight software at launch site if
testing necessary
7 Launch
8 Check-out and Calculate tumble rate. Detumble if GO. Ground control manages software
commissioning Perform all operational modes and test all distribution and uploads based on
sensors. Reboot additional software from check-out results. Anticipate 90
onboard memory and check against minute cycles for main upload
transmitted software for differences. contact. Rewrite software if bugs
Characterize all systems with functional test identified.
under operational modes (power cycles,

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 37 OF 98

eclipse, controlled tumble, simulated

uncontrolled tumble). Determine best solution
for detumble (MTQ, RXN wheel, propulsion,
and anticipated time)
9 Operations Process sensor data, upload blockchain over Anticipate decreasing re-upload
Testing several orbits. Broadcast metadata, chain frequency. Flight software will
length, test during eclipse, sunlight, partials. become more permanent after
Test with mobile uplink station for low-baud passing checkout and early stage ops.
data first. Upload software for high-baud data Update environmental sensor
(block). calibration to measured/calculated
values and reassess operational
thresholds through edge-case testing.
9a Station OBC checks all systems during burn. Confirm Software lock-out if commanded
Keeping, Phase that the minimal shock and increased thermal thrusting exceeds propellant
maintenance output does not put systems over safe levels. expenditure limits.
Close valves.
10 Transition to Update software if behavior in eclipse
eclipse differs drastically from expectations.

11 Transition to
day
12 Telemetry Process S/C health data and send to TT&C. Anticipate occasional updates but
collection Store on 10 second cycles and transmit nominal ops should be steady
package on request, plus per orbit single
packet.
13 User uplink Process payload blockchain uplink and store Anticipate occasional updates but
blockchain on flash memory with redundancy. Broadcast nominal ops should be steady
includes requests for the next block, and
blocks are verified in OBC.
14 Blockchain Broadcast block over the course of 30 seconds Anticipate occasional updates but
broadcast if data budget stays steady from test nominal ops should be steady
parameters. Broadcast includes requests for
the next block, and blocks are verified in OBC.
15 Blockchain Transmit blockchain metadata for a block (65 Anticipate occasional updates but
Metadata kb per block) in 2 seconds, with sufficient link nominal ops should be steady
broadcast robustness/redundancy to handle lossy RF link.
Interspersing 5 meta-data packets with each
block, a typical user on a typical day can
receive metadata from 320 blocks from one
satellite, however there will be duplication in
the received data.
16 System Based on user feedback, increase or decrease Anticipate occasional updates but
Optimization the link robustness (trade-off is transmission nominal ops should be steady
speed) and change algorithm for prioritization
of most recent block.
17 End of Mission Computer will degrade in performance over Software errors are most likely failure
time. Power cycling, reboots, redundant mode. Many ways for this to happen.
processor checking, will extend life. Power Reference Software Failure Mode
consumption likely to increase slightly. Lattice report for more detail.
damage may degrade OBC but B1 will fly
below hazard rad belt.
17a Optional: Engage valves on low flutter cycle (high thrust) Upload deorbit software if possible.
Active De-orbit Do not keep onboard during primary
mission.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 38 OF 98

18 Passive De- Safe mode or dead Safe mode or dead

orbit
19 Data Analysis N/A N/A

4.4.2

The iOBC, produced by ISIS, will serve as BitSat’s flight computer. It provides the necessary interfaces,
as well as SD Card slots for two 128GB Flash memory cards. The iOBC uses JTAG for programming and
debugging, and a UART port for on-ground testing and a console user-interface.
The MIPS budget needs testing of software on the actual hardware. This is an open item, and will be
done early in the detailed design phase. This has been added to the Action Item Log in Section 7.1.

4.4.3
Software is often a major cost driver for satellites due to the reliability and testing requirements and
the small production volumes over which to amortize the cost. This is overcome by tolerating faulty
(or even malicious) software through a robust system design, and through the ability to reprogram
the computer(s) once in orbit.
Tolerating any and all types of software errors, even malicious code, requires that it be impossible for
the spacecraft to “die” as a result of any action that the software may perform, or any command that
may be sent from the ground. This is a design driver that has been used throughout the design. Some
of the things that have been avoided include:
It is not possible to turn the spacecraft “away from the sun” such that there is not enough
power generated to run the spacecraft in Safe mode.
It is not possible to turn the satellite TT&C antennas to an orientation such that
communications cannot be established.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 39 OF 98

In any 24 hour period, it is not possible to open the valves of the thruster for a total duration
that would deplete more than 5% of the propellant.
It is not possible to lock up the OBC in such a way that the user cannot reset the spacecraft
and regain control
Providing the functionality to reprogram the OBC without the risk of disabling that same functionality
requires that a small code block be non-reprogrammable, namely the Bootloader. The Bootloader
functions are limited to uploading code and sending a simple beacon. Being the only immutable
software on the spacecraft, it must be tested thoroughly. Being so severely limited in functionality, it
is short and therefore easier to test. The bootloader will be written into a location in memory that
cannot be erased or disabled.
During the boot sequence the bootloader checks for requests from the ground to upload new
application code, and otherwise executes the existing application code. The Bootloader functional
flow diagram is shown in Figure 8.
The iOBC is provided with interface libraries for FreeRTOS and application code runs as tasks in this
environment. Seven tasks are identified:
Housekeeping (telemetry handling, health check and WDT monitoring)
TT&C handling
ADCS
GNC
Payload handling
Interface libraries written in C are available with the iOBC. The interface libraries provide the
following functionality:
Bootloader
Parameter database framework (for command settings)
Telemetry handling framework
Communications (TT&C) handling
Health Check & WDT monitoring
The existing software in these libraries will need to be verified against the functional and non-
functional requirements of the BitSat satellites. Tasks not included in the libraries will need to be
specified, written and tested.
The functional flow of the OBC software tasks are shown in the following figures.
TT&C handling has not been fully defined at this stage, and is an open item to be addressed early in
the detailed design phase. This has been added to the Action Item Log in Section 7.1.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 40 OF 98

Figure 8: Bootloader functional flow diagram

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 41 OF 98

Figure 9: Housekeeping task functional flow diagram

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 42 OF 98

Figure 10: ADCS task functional flow diagram

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 43 OF 98

Figure 11: GNC task functional flow diagram

Figure 12: Payload handling functional flow diagram

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 44 OF 98

4.5
The structure provides the physical interface to the satellite during build and launch. The ISIS 3U
chassis consists of a minimalist frame and lengthwise rods with spacers to contain regular CubeSat
PC104 geometry circuit boards. An important reason for selecting this chassis over others is the open
frame construction (i.e. it is easier to access circuit boards in through the side) verses plated chassis.
The satellite’s thermal requirements were verified using a steady state worst-case analysis, showing
that it will remain with the operating temperature range under all conditions. This method, while not
nearly as detailed as FEA, is adequate for the current level of design detail. Analysis was done for
both sun-pointing mode and “side on” mode.

4.5.1

Phase Activity Thermal Structure / Mechanisms

1 Payload N/A N/A
Manufacture
and Testing
2 FlatSat testing N/A Verify chassis meets spec and store hardware during
FlatSat testing.
3 Integration into Passive coatings are robust to ground Provide supporting jigs to simplify assembly.
bus handling Connector and fastener routing pre-defined in CAD.

4 Environmental Thermocouples will verify thermal Placement of accelerometers and spot (pulse) weld
Testing output during peak, nominal, and safe thermocouples to flight chassis.
operating modes in TVAC testing.
5 Storage N/A Ensure lock screws and permanent fasteners are
properly torqued. Cable-tie, epoxy and locktite all
fasteners, connectors and cable runs. Store handling
documents and information with assembled sat.
Store inside the CubeSat deployer
6 Launch site N/A Remove tags and constraints before launch.
testing
7 Launch N/A Launch inside the CubeSat deployer
8 Check-out and On-board temperature logged for Solar panel deployment.
commissioning several orbits. Test while powered,
unpowered payload. Check peak
current thermal output against model.
Update model if parameters off the
expected. Reassess operational safety
limits for unkillability.
9 Operations Periodic temperature checks. Transmit N/A
Testing if anomalous, otherwise only transmit
infrequent health checkups.

9a Station Keeping, Check full satellite temperature during N/A

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 45 OF 98

Phase station keeping. Anticipate peak

maintenance temperature for longer duration than
initial functional test.
10 Transition to Monitor cold operational temperature N/A
eclipse and check against electrical current.
11 Transition to Monitor temperature changes. Check N/A
day electrical current
12 Telemetry Monitor and modify alarm thresholds if N/A
collection S/C health checks change over flight
13 User uplink Monitor and modify alarm thresholds if N/A
blockchain S/C health checks change over flight
14 Blockchain Monitor and modify alarm thresholds if N/A
broadcast S/C health checks change over flight.
Check thermal output when payload is
on peak current against functional
flight test results.
15 Blockchain Maintain operation and modify if S/C N/A
Metadata health checks change over flight
broadcast
16 System Monitor and modify alarm thresholds if N/A
Optimization S/C health checks change over flight.
17 End of Mission Heat death is potential failure mode. Structure performance unlikely to change.
Health checkups should tell ground Mechanisms may degrade, but mechanisms are not
operators when S/C thermal is a mission-critical after initial checkout.
problem.
17a Optional: Active N/A N/A
De-orbit

18 Passive De-orbit N/A N/A

19 Data Analysis N/A N/A

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 46 OF 98

4.5.2 -
Several views of the CAD model are shown here

Figure 13: Angled views of the BitSat CAD model

Modifications to CAD in the future include the modifications Clyde Space will make to their solar
panels to allow antenna deployment. Horizontal slots will be made in the body mounted panels to
allow this.

Figure 14: Cut-away view of the BitSat CAD model to show internal components

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 47 OF 98

Figure 15: BitSat CAD model with body-mounted solar arrays removed to show internal components

Figure 16: BitSat CAD model with solar arrays and structure removed

The configuration of the stack will allow for wire routing to critical parts such at the OBC and
antennae from all parts of the spacecraft. The OBC and power systems at the very top allow for easy
BITSAT PRELIMINARY DESIGN REPORT
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 48 OF 98

routing of the ADCS and power lines. Visible on the left of the isometric image in Figure 16 is the
PC104 back-plate which handles the majority of power and data in the spacecraft. Additional wire
pass-throughs exist centered on several components (MTQ, antenna).

4.5.3 -

Figure 17: ISIS CubeSat structure shown with blank circuit boards

The ISIS 3U structure conforms to the CubeSat standard. The primary structure consists of the rails
and cross-members. The secondary structures holds the circuit boards into three separate,
integrated “stacks” roughly 90 x 90 x 90 mm3. The secondary stacks are slotted into the primary
structure and secured with fasteners.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 49 OF 98

4.5.4 -

Figure 18: ISIS 3U deployer

BitSat will be launched inside a CubeSat deployer, an example of which is shown in Figure 18. These
are typically provided by the launch broker, as part of the launch service. Depending on the launch
broker’s approach, vibration testing may be performed inside the deployer or a separate “test pod”
may be needed for testing. Thanks to the CubeSat standard, deployers are fairly standard,
interchangeable systems.

4.5.5
Thermal analysis was performed for steady state conditions under best-, worst-, and average-case
scenarios. The spacecraft was modelled as discrete nodes (not FEA) with heat transfer by radiation,
conduction. Calculations considered earth albedo and electrical power consumption.
In the coldest case, all nodes remained above -1 degrees Celsius. In the hottest case the solar panels
remained below 70 degrees Celsius and the electronics below 40 degrees. With a typical operating
range of -10 to +40 degrees Celsius on most CubeSats, there is an appreciable margin for
temperatures to which the satellite’s components are exposed.
The thermal analysis spreadsheet can be found in Appendix 1.2.

4.6

The ADCS and GNC components have been sized to achieve the mission requirements and ConOps.
The rule-of thumb is that attitude knowledge (i.e. sensor accuracy) must be ten times the required
control accuracy. Actuators must have sufficient torque and momentum capacity to provide the
required agility.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 50 OF 98

As the attitude requirements are not onerous, it was not considered necessary to create a simulation
of the ADCS performance, however this is an open item to be addressed early in the detailed design
phase. This has been added to the Action Item Log in Section 7.1.

4.6.1

Phase Activity ADCS/GNC

1 Payload Manufacture N/A
and Testing
2 FlatSat testing ADCS sensor and actuator response tests. Verify data and command exchange with OBC.

3 Integration into bus Reaction wheels and magnetometer integrated after circuit board stacks.

4 Environmental Testing Confirm RXN wheel functionality and directionality. Run test maneuvers to simulate station
keeping and phase determination. Simulate 1 AU sun source and test sun-sensors (coarse
and fine). Hot fire of cold gas thruster if test facility allows propellant in the vacuum
chamber.
5 Storage Cover ADCS sensors for storage.
6 Launch site testing Remove tags and constraints before launch.
7 Launch N/A
8 Check-out and Detumble when contact established using b-dot algorithm. Pulse all valves and check flutter
commissioning speed- record on accelerometers.
9 Operations Testing Test all sensors and actuators. Test ADCS and GNC algorithms.
9a Station Keeping, Phase Orient, maintain orientation, check thrust vector against expected vector.
maintenance
10 Transition to eclipse Maintain attitude. Avoid propulsion during eclipse as attitude errors will be significantly
larger.
11 Transition to day Maintain attitude.
12 Telemetry collection Maintain attitude.
13 User uplink blockchain Maintain attitude.
14 Blockchain broadcast Maintain attitude.

15 Blockchain Metadata Maintain attitude.

broadcast
16 System Optimization Maintain attitude.

17 End of Mission Wheel failure is a possible cause of mission termination as it will decrease pointing ability.
Redundant methods for pointing should allow mission to extend through several system
failures, albeit at reduced performance.
17a Optional: Active De- Maintain attitude for propulsive maneuver
orbit
18 Passive De-orbit N/A
19 Data Analysis N/A

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 51 OF 98

4.6.2 -
Reaction wheels are mechanical components that spin up and down as needed to transfer angular
momentum to the spacecraft at large. This angular momentum transforms into the spacecraft’s
pitch, yaw, and roll. Reaction wheels thus provide unrestricted 3-axis motion.

Figure 19: Blue Canyon reaction wheels for CubeSats

The Blue Canyon Tech Micro-Wheel shown in Figure 19 is a small reaction wheel that can hold an
adequate amount of momentum and provide sufficient torque to the BitSat satellite.

4.6.2.1
BitSat does not require agile pointing as it remains in a sun-pointing attitude during the operational
phases of the mission. The reaction wheels are sized for the maximum angular acceleration and slew
rate, which are driven by the need to rotate the satellite in a timely manner to orient the thrusters
for a propulsive maneuver. For orbital station-keeping, with a burn time of around 2 minutes on the
thrusters to achieve a single maneuver, placing a one-minute limit for turning and stabilization of the
spacecraft from worst conditions (180 degrees from the required direction) is considered a
reasonable design goal.
During Orbital Maintenance mode the payload may be turned off, so minimizing the time spent in
this mode is highly desirable. Blue Canyon Tech’s Micro-Wheel is the lightest available wheel that can
achieve the one-minute rotation/stabilization goal.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 52 OF 98

Figure 20: Analysis of the micro-wheel's rotating abilities at different spin rates.

It is typical to run reaction wheels at a bias speed to avoid frequent zero-crossings that perturb the
attitude. Running at half the maximum speed allows the wheel speed to be changed by the
maximum amount in either direction without a zero-crossings.

Running at a bias speed of 3000 RPM (50% of the maximum speed), the micro-wheel is able to turn
the satellite by 180-degree turn in less than 1-minute. It was observed, however, that power
consumption is high when running continuously at this bias speed. The micro-wheel is capable even
at extremely low input power values at low bias speeds, as can be seen in Figure 21. A lower bias
speed of 1000 RPM was chosen. During normal sun-pointing operations this will avoid zero-crossings.
When slewing the zero-crossings are considered less of a concern.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 53 OF 98

Micro-Wheel RPM vs. Power

1.8
1.6
1.4
1.2
Power (W)

1
0.8
0.6
0.4
0.2
0
-8000 -6000 -4000 -2000 0 2000 4000 6000 8000
RPM

Figure 21: BCT Micro-wheel power consumption at different speeds

4.6.2.2
The Reaction Wheel Analog Drive Electronics Board (RDE) converts analog telemetry from the Micro-
wheels to a digital output for communication on the I2C bus, and transform I2C commands into power
output levels to drive the wheels.

4.6.3
Reaction wheels are sufficient to point the spacecraft in the short-term, however over time they will
build up momentum as the constantly counteract the small disturbance torques from the magnetic
field, solar radiation pressure, atmospheric drag and gravity gradient. In order to “dump” this
momentum, BitSat will use magnetorquers. By a superposition of three orthogonal electromagnets, a
virtual magnet can be created along any vector, which interacts with the Earth’s magnetic field to
produce a torque on the spacecraft.
The magnetorquers are also used to detumble the spacecraft after it is deployed from the launch
vehicle. This allows the sun-pointing mode to be initiated at a very low spin rate, which is easier for
the control algorithms to handle.
The ISIS 3-axis magnetorquer shown in Figure 22 consists of two iron-core electromagnets
(magnetorquers), and one air-core (underneath the PCB). It can generate 0.20 Am2 magnetic dipole
in any direction.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 54 OF 98

Figure 22: ISIS iMTQ 3-axis magnetorquer

It is desirable to detumble the spacecraft within a reasonable time (maximum 1 week) from the
highest expected tip-off rate (a very conservative 100 deg/s). The b-dot control algorithm is used,
which is very simple and also very common for small spacecraft. This was validated by reference to
analysis of similar missions, which achieved the following:
<72hr 0rbit detumble from 29 deg/s in GTO using MTQ 0.13Am² **
<2hr detumble from 17.8 deg/s using MTQ 0.06Am² ***

** Mason Peck (2013) “Attitude

Dynamics and Control of a 3U
CubeSat with Electrolysis
Propulsion”
*** Daniel Torczynski (2010)
“Magnetorquer Based Attitude
Control for a Nanosatellite Test
Platform”

Figure 23: Detumble from a tumble around all three principal axes (Daniel
Torczynski, 2010)

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 55 OF 98

Magnetometers can be accurate to less than 1 degree, however on small spacecraft the magnetic
interference can create errors of degrees or even tens of degrees. The iMTQ board includes a
magnetometer, which can be located at a distance attached by a cable. On BitSat we will place the
magnetometer near the end of the extended solar panels, away from magnetic interference of the
spacecraft’s many components.

Figure 24: Analysis of the detumbling of a 3U CubeSat from various initial tipoff rates (Mason Peck, 2013)

4.6.4
The Clyde Space solar panels’ integrated photo diodes will provide fine sun-sensing through a linear
voltage response. Clyde Space’s integrate sensors are based on the Hamamatsu architecture. These
sensors have flight heritage from the Ukube-1 mission. The accuracy, with temperature
compensation, is around 1 degree.

Figure 25: Clyde Space integrate fine sun sensor - voltage response

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 56 OF 98

4.7
The Telemetry, Tracking and Command system is a relatively low data rate radio. It is adequate for
receiving telemetry and uploading commands and new software.

4.7.1

Phase Activity Comm

1 Manufacture and Testing N/A
2 FlatSat testing Comm testing with wired TT&C initially. Verified comm progresses to RF
transmission after passing functional wired test.
3 Integration into bus Comm assembly shall be installed immediately following OBC installation.
4 Environmental Testing RF equipment tested with RF engineer in supervising role. Attempt wireless
software upload without deployed antennae (use antenna hat). Test Tx and Rx
at high and low temperature in TVAC.
5 Storage Inspect for changes since integration before storage. Record and confirm flight
readiness
6 Launch site testing N/A
7 Launch Off during launch.

8 Check-out and Transmit operational status during flight checkout. Send telemetry. Monitor
commissioning signal strength. Anticipate full software upload and reboot.

9 Operations Testing Maintain periodic send/receive to ground stations for flight status. Health
checks processed. Transmit health checks on encrypted and public bands for
operators and community.
9a Station Keeping, Phase Transmit and receive telemetry.
maintenance
10 Transition to eclipse Continue nominal TT&C
11 Transition to day Continue nominal TT&C
12 Telemetry collection Transmit telem data on request from ground station. Otherwise transmit per
orbit quick checkups.
13 User uplink blockchain Transmit telem data on request from ground station. Otherwise transmit per
orbit quick checkups on encrypted and public bands.

14 Blockchain broadcast Continue nominal TT&C

15 Blockchain Metadata Continue nominal TT&C
broadcast
16 System Optimization Continue nominal TT&C
17 End of Mission Turn off Transmitter
17a Optional: Active De-orbit Minimal telem needed during deorbit burn.
18 Passive De-orbit N/A
19 Data Analysis N/A

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 57 OF 98

4.7.2
The ISIS TRXUV is a common CubeSat transceiver used for TT&C communications in the VHF and UHF
bands. The TRXUV, shown in Figure 26, is a two-module system that handles uplink and downlink
separately, including separate power inputs. It will be connected to both the main and backup I²C
buses.

Figure 26: ISIS TRXUV

Figure 27: TRXUV Circuit Diagram

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 58 OF 98

4.8

4.8.1

Figure 28: ISIS ANTS CubeSat deployed antenna system, intended for UHF and VHF bands

The ISIS deployable UHF/VHF whips use a flight-tested whip deployment design. Its mechanism has
been proven to be reliable on orbit, with many dozens of successful flights. However the Dipole
Antenna which is currently available does not fulfill the needs of the BitSat mission as it is also
intended to operate the payload S-band radios through these antennae.
Out of a number of options, including outfitting the satellite with two dipole antenna arrays, it was
determined that the best method for transmitting on all necessary bands (UHF, VHF and S-band) was
adapting the ANTS antenna system to provide two S-band monopoles, one UHF monopole and one
VHF monopole. The VHF and UHF losses, when switched to using monopole antennas, are expected
to be negligible. Therefore the design modifications will emphasize optimizing for the S-band.
The antenna needs to be designed, simulated, built and tested. This is an open item, and will be done
early in the detailed design phase. This has been added to the Action Item Log in Section 7.1.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 59 OF 98

Figure 29: S-band Monopoles (short, pointing left and right) and VHF and UHF monopoles shown on the BitSat spacecraft

4.9
For BitSat B1 to demonstrate the capabilities of the B2 Constellation mission, the B1 spacecraft have
been designed to have propulsion capabilities. The focus of the propulsion has been on what is
available for use and what can reliably demonstrate relative orbit phase maintenance. The
propulsion subsystem handles orbital station-keeping by propelling prograde (increasing orbital
period) and retrograde (decreasing it) so as to let the other members of the scaled constellation
move to the correct phase.
Propulsion in this satellite will also allow for rapid deorbit (if sufficient propellant exists at EOL),
movement away from the launch vehicle upper stage, or small plane changes if required. It also
allows for some leeway on the kinds of launches necessary to get the satellites into orbit, as they will
be able, to an extent, to modify their orbits within a modest delta-v budget. While all of these
activities are possible, it is only expected that orbit phase maintenance will be performed.

4.9.1

Phase Activity Propulsion

1 Payload Manufacture N/A
and Testing
2 FlatSat testing Propulsion control board tested, with valve activation. Check “depletion protection”
3 Integration into bus N/A
4 Environmental Hot fire of cold gas thruster in vacuum, if test facility allows propellant in the chamber. Find
Testing resonant frequency and check if valve flutter can induce resonance.
5 Storage Propulsion for long term storage requires litmus chemical sensor to check for leak. Propellant
is non-toxic (FE-36 [fire extinguisher]), but a passive detector will show if propellant needs
refilling before flight. Shelf life of cold gas thruster will be characterized prior to BitSat flight.
6 Launch site testing Remove tags and constraints before launch. Dummy valve actuation after shipment. Inspect
propellant leakage and refuel if necessary (deliver extra propellant to launch site).
7 Launch N/A

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 60 OF 98

8 Check-out and Check cold gas temperature and pressure. Pulse all valves and check flutter speed. Determine
commissioning battery energy during eclipse if prop/ADCS is engaged and create safe flight parameters based
on results.
9 Operations Testing Maintain high power stability. Check propulsion temperature, pressure in secondary plenum
ensures no leak. Maintain orbit alignment with passive MTQ primarily.
9a Station Keeping, Orient, maintain orientation, check thrust vector against expected vector, perform burn with
Phase maintenance valve flutter for control. Use thruster for RCS pitch-yaw attitude control during firing.
10 Transition to eclipse Avoid propulsion maneuvers during eclipse. Phase maintenance should occur while in
sunlight, but plan for eclipse ops and determine if environmental phase keeping simulation
was accurate.
11 Transition to day N/A
12 Telemetry collection N/A
13 User uplink N/A
blockchain
14 Blockchain broadcast N/A
15 Blockchain Metadata N/A
broadcast
16 System Optimization If time allows, trial attitude-based variable drag for orbit phase maintenance
17 End of Mission Propellant may become exhausted-- reduce station-keeping capability.
17a Optional: Active De- Point in steady retrograde orbit from apoapsis and fire everything. Heat up of propellant from
orbit external systems is acceptable if mission is over. Keep some propellant onboard for small
adjustments.
18 Passive De-orbit Safe mode or dead
19 Data Analysis N/A

4.9.2

Figure 30: UT Austin cold gas thruster as built for INSPIRE (left) and preliminary design for BitSat (right)

The University of Texas at Austin cold gas thruster, shown in Figure 31, is a 3-D printable propulsion
system capable of approximately 15 m/s delta-v on just 100 grams of propellant. Analysis of the
delta-V requirements for orbit phase maintenance are shown in Figure 31. A total delta-V capacity of
15 m/s is sufficient for one year of for the B1 satellites at an orbit altitude of around 450km, and
longer if the altitude is higher. BitSat is targeting an altitude between 500 and 750km.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 61 OF 98

The thruster uses non-toxic FE-36 (fire extinguisher material) from DuPont Technologies, and has
flight heritage on the Bevo-2 CubeSat, deployed from the space shuttle. The NASA Inspire mission
uses a variant of the Bevo-2 unit designed for RCS, slated to fly (tentatively) in late 2014. The BitSat
B1 thruster proposed for station keeping and phase maintenance has a modified nozzle geometry
but keeps the same control hardware, in order to save design costs. It is further designed for
compatibility and ease of integration with the ISIS 3U chassis. The thruster stores its non-toxic
propellant at pressures of only 100 PSI, and is thus classified as a “container” instead of a pressure
vessel. This feature is extremely desirable for a thruster on a secondary payload.
The UT Austin thrusters only provide enough delta-V for station-keeping of short-term missions, and
are adequate for B1. Electric propulsion options can fulfill constellation setup requires for the larger
B2 fleet, and possibly resistojet booster options as well.

Figure 31: Delta-V requirements for orbital maintenance maneuvers over mission lifetime

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 62 OF 98

5.0
The ground station consists of an antenna, means of tracking the satellite, signal amplification, demodulator,
and tracking control software.

5.1
1. Can receive BitSat signal with a 5 decibel average margin
2. Cost <$10k
3. Easy to ship and install

To keep the spacecraft transmitter power under 1.5 watts, the ground station G/T must be over 8 dB/K, so the
gain of the antenna must be about 30 dBi. This is possible with a 2 meter parabolic dish or a phased array of
the same approximate aperture size.

5.2
The parabolic dish reflects incoming photons and focuses them onto the feed. The dish is mounted on a set of
rotors which are mounted on a mast which allows it to see over nearby obstructions. The feed contains a low
noise amplifier which amplifies the incoming signal. Then a cable drops down from the feed and goes to the
radio.

The gain of a parabolic dish is proportional to its size. We need a 2 meter dish. The cost will be no greater than
$200.

The feed might have to be custom designed for highest performance - we’d package the low noise amplifier
into the feed assembly. Once designed, they can be manufactured for no more than $40 each in 10k+
quantities.

5.3
The rotors allow the dish to track the satellite. Various off the shelf rotors with controllers exist, including the
Array Solutions PST61D, the HY-GAIN RAS-2 and the YAESU G-5500.

The ground station needs a simple computer to plan the next pass and receive data off of the radio. There are
many single-board computers that are capable of this task. In the long term it may be more cost-effective
(saving up to $50 per unit) to use a Cortex Arm A-series processor running linux, laid out on an integrated
board with the demodulator.

5.4

The demodulator receives the radio waves and turns them into digital data. It corrects any errors it might find
and presents the user with data plus a quality indication. The demodulator (including software development)
can be designed for $80k and produced for $50 in 10k+ quantities. This design will include a simple Arm a-
series processor running linux to provide a user interface to the data and plan the next satellite pass.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 63 OF 98

5.5
The ground station will take our team 4 months to design and test. It will be ready for mass production within
5-6 months of initial contract. The development cost will be $178,000 NRE.

5.6
quantity per
Item Cost installation Line cost
Antenna 300 1 300
feed 50 1 50
Cable 5 4 20
Rotor 2000 1 2000
radio/computer 50 1 50
Mast 460 1 460
lightning protection 50 1 50
Hardware 300 1 300
Mounting 200 1 200
development cost over 10k units 17.8 1 13.8
Total 3443.8

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 64 OF 98

6.0
Satellite development projects are typically broken into several phases:
Phase A is the preliminary design, which is the subject of this report. It serves to confirm the
feasibility of the proposed design solution.
Phase B is the detailed design, which concludes with that Critical Design Review when the
detailed engineering drawings are completed and manufacturing can commence.
Phase C is manufacturing or procurement of the spacecraft subsystems and components.
Phase D is assembly, integration and environmental testing, preparing the spacecraft for
flight.
Phase E is Launch and Operations.
In pragmatic nanosatellite programs there is a lot of overlap between the phases in order to reduce
risk early, shorten the schedule, and complete the development more cost-effectively. Subsystems
with high technical risk, such as the communications payload for BitSat, may be prototyped during
Phase A. Long lead-time items may be procured during Phase B. Assembly, and even testing, may
begin during Phase C.
The risk of this approach is that systems mature at different rates and any problems or design
decisions that are resolved later in the design process may be more expensive to resolve after much
of the design has been locked down and hardware has been procured. This risk, as well as traditional
technical risks, are managed by prudent planning of the engineering process and the use of standard
interfaces wherever possible.

6.1

6.1.1
The schedule of technical milestones shown below highlights the engineering reviews that act as
gates between the traditional project phases. This schedule assumes that the team continues
working on the project, and any delay in contracting will cause a corresponding delay to the
schedule. It should also be noted that the launch dates shown are reasonable targets, however
actual launch dates will depend on launcher availability and will be affected by any launch delays,
which is not uncommon.
Three launches are shown, which is only one scenario. It is more desirable to launch at least two
spacecraft on one of the launches to demonstrate orbit phase maintenance, in which case only the
earlier two launches will be needed. If all three are launched together, only the first launch will be
utilized.
While the development phases are somewhat blurred, the engineering reviews are even more
necessary to ensure that the whole team comes together to check all parts of the design are

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 65 OF 98

compatible. Critical peer review is the best method for ensuring design mistakes and false
assumptions are found, fixed and avoided.

Figure 32: BITSAT technical milestones, assuming uninterrupted development and 3 launches.

6.1.2
The bulk of the work during the detailed design and manufacturing phases is at sub-system level and
proceeds in parallel. During the subsequent Assembly, Integration and Testing (AIT) phase, all
subsystems must be proven to work together. Planning of this phase is critical to ensure that no
mistakes have been made at any previous stage, and the spacecraft will survive launch and operate
correctly. Frequent functional testing is performed to check the nominal operations of the system
after each major test. As much as possible, testing is automated.
The figures below show the testing that will be performed, and the planning and test schedule.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 66 OF 98

System Design Team (2-3 engineers)

Software Development Team (2-3 Figure 33: AIT workflow
engineers)
Week 10
Week 11
Week 12

Week 13
Week 14
Week 15
Week 16
Week 1
Week 2
Week 3
Week 4
Week 5
Week 6
Week 7
Week 8
Week 9

Test Preparation Plan

CDR Presentation and Report

Begin FlatSat Integration

FlatSat test documentaion write-ups
Contract Start

Experienced S/C software contractor

oversight supports high-level
documentaion of software dev plan
Assembly, Integration procedures
Facility safety paperwork (NASA leased
office space)
FlatSat software development, simulation
model, payload software development
CDR report and presentation write-ups
CDR correction period
Major component arrival dates

Figure 34: AIT test preparation plan, for scheduling purposes

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 67 OF 98

Figure 35: AIT engineering flow plan, for scheduling purposes

6.1.3
There are three options considered for the model philosophy: QM/FM, PFM and PFM/FM.
A Qualification Model / Flight Model (QM/FM) approach is the traditional spacecraft approach. The
QM is used to qualify the design and is tested at high test levels (vibration, shock, thermal) for a long
duration. Following this, the FM is tested at lower levels and for a shorter duration to ensure that
workmanship is adequate. This protects the flight model from being tested to “within an inch of its
life”.
More common in the CubeSat community is the Proto-Flight Model (PFM) approach, where the
prototype is also the flight model, effectively “flying the prototype”. The PFM is tested to QM level,
for FM durations. The primary advantage of this approach is that it does not require procurement
and assembly of a separate QM, however there are two risk to this; it is not possible to make changes
and apply lessons learned from the QM in building the FM as there is only one PFM flight unit, and
the flight unit has experienced greater stress levels than an FM.
Launch brokers have confirmed that, after the first flight of a PFM, subsequent spacecraft can be
considered FM. This yields a PFM/FM model philosophy that is applicable to satellite constellations.
It may be possible to reduce the launch test requirements even further for the batch-produced
spacecraft, however this needs further investigation. This has been added to the Action Item log in
Section 7.1.

6.1.4
Four options were considered for proceeding from this preliminary design to flight.
1. 3x PFM Spacecraft for the B1 BitSat Demonstrator
2. 3x FM B1 + QM (which doubles as the Engineering Model) for the B1 BitSat Demonstrator
BITSAT PRELIMINARY DESIGN REPORT
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 68 OF 98

3. 24x FM Spacecraft for the B2 Constellations, with the first few unit treated as PFM
4. 24x FM B2 + QM (which doubles as the Engineering Model), also moving directly to the B2
Constellations
Options 1 was assumed for planning purposes in preparing this report, however information was
gathered on the other options to aid in decision making.

6.1.5
In order to proceed most rapidly to fight, all the subsystems for BitSat B1 are commercial-off-the-
shelf (COTS) components procured from external suppliers, except the thruster and payload which
are minor variants of COTS systems.
Checkout, assembly, integration and testing of the subsystems into a satellite requires the following
resources:
Facilities:
An electronics work bench with suitable anti-static controls
A cleanroom or laminar flow hood. As there are no critical optical systems, there is no need
for a full clean room
Environmental test facilities for thermal-vacuum and vibration. These can be rented at an
external site for the short duration they are needed. Several suitable facilities exist in the
vicinity of Mountain View, California, including at NASA Ames.
Antenna pattern test chamber (anechoic chamber), also available in the vicinity of Mountain
View, California, including at NASA Ames
Equipment:
In addition to standard electronics workshop tools (mechanical and electrical), the following
equipment will be needed for this project:
Several jigs, stands and protective covers to aid with integration of the “Flat-Sat” (the circuit
boards laid out on the bench and electrically connected) and the full spacecraft.
A CubeSat Dispenser “Test Pod” for mechanical fit check
A turn-table and magnetometers to aid in verifying the attitude control sensors and
actuators
Personnel:
Skilled engineers with experience with CubeSat integration will help to avoid the many
pitfalls and quirks of the COTS subsystems which can significantly impact the schedule.

6.1.6
To ensure quality workmanship, industrial standards are used. These are not NASA or MIL standards,
which are seen as too onerous for a CubeSat program.
BITSAT PRELIMINARY DESIGN REPORT
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 69 OF 98

Soldering: J-STD-001-ES
Final assembly (if needed): ISO 14644-1 class ISO-8
Parts assembly (laminar flow hood): ISO-8
Electrostatic discharge control: ANSI/ESD S20.20
It is important to note that success of the B1 mission is assured by managing risk at several levels,
allowing relaxing of the most expensive parts of the quality control process of a traditional
spacecraft. Some of the features of the design include:
Flying three spacecraft. While all three are expected to succeed, only two fully functioning
spacecraft are required to meet the mission requirements
Staggered launches. Two launches are recommended: one spacecraft on the first and two on
the second. This allows any problems identified on-orbit on the first spacecraft to be fixed on
the second.
Emphasis on design rigor & critical review. Rather than emphasizing the paperwork and
process, a tightly integrated development team can pay more attention to the system
architecture and the design. Technically critical peer review is crucial, both formal reviews by
external experts as was conducted for the BitSat B1 Preliminary Design Review and informal
on a day-to-day basis within the team. Every engineer must be confident not only that “the
spacecraft will not fail due to my subsystem” but also that “the spacecraft will not fail where
my subsystem interfaces to others”. Much attention is paid to creating and maintaining this
culture within Deep Space Industries.
Multiple spacecraft recovery methods. Despite best efforts to avoid and “flush” errors, they
may still accumulate (radiation-induced errors in working or program memory, memory
leaks, software bugs, etc.). Regularly resetting the spacecraft, preferably by disconnecting
power to the entire spacecraft for a short period of time, can clear many lock-outs. This
involves loading all software from flash memory and re-calculating all internal states.
o Every subsystem should gracefully recover from a reset, and gracefully handle a full
spacecraft reset.
o Regular resets. The spacecraft should be designed to reset once a week, at minimum.
o The use of state parameters are to be minimized and as far as possible the spacecraft
should be stateless. No interacting state parameters should be held cross subsystem
boundaries such that the reset of any one subsystem does not create an incorrect
state.
o Ground-commanded reset that bypasses all computers. A ground command should
be detected by the radios and cause the EPS to power-cycle the spacecraft. If there
are microcontrollers in the receivers that cannot be bypassed, the receivers should
then be dual-redundant.
o Watch-dog timers (WDTs). The main WDT on the EPS requires stroking from the OBC,
lest it reset the spacecraft within 10 minutes. Other subsystems in turn stroke WDTs
that held by the OBC. The microcontrollers in the two redundant receivers on the
BITSAT PRELIMINARY DESIGN REPORT
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 70 OF 98

payload are cross-strapped to stroke WDTs on the other receiver, lest the payload
cause itself to reset.
The ability to reprogram the spacecraft. It is not possible to fully and correctly simulate the
space environment on the ground (and it is very expensive to try!). Every microcontroller
should be able to be reprogrammed from the ground once the real behavior of all the
components is observed on orbit. The low level “boot loader” capability is the only part of
the software that must be immutable.

6.1.7
Space systems require documentation to be accurate and consistent with the delivered (launched)
hardware, so that on-orbit operations and debugging can be done efficiently. For small spacecraft
built in batches, it is not cost-effective to apply the same configuration management approach that is
used for large spacecraft. Change requests and change proposals are handled informally by the small
team executing the project, resolving matters by in-person discussion. It is important, however, that
engineering documentation describes the as-built hardware.
Software version control: SubVersion or GitHub should be used, with appropriate use of
release flags, branches, etc. The spacecraft should report, on request, the build details of
every piece of software that it is running, including the bootloader.
Configuration Identification: Photographs are used to record every step of integration
including incoming inspection flight assembly and any modifications or repairs.
Non-conformance reports are created for any modifications or repairs that deviate from the
assembly plan, require swapping out of a subsystem or component, or re-work of a COTS
subsystem.
For subsystems and ancillary items manufactured by Deep Space Industries, component lot
numbers are recorded in the build and inspection history.
Verification of configuration management record keeping should be undertaken at TRR and
checked at FRR.

6.1.8
The U.S. Government restricts both information and hardware dealing with defense-related topics
under the International Traffic in Arms Regulations (ITAR). The U.S. State Dept. has ruled that this
report is not subject to ITAR, and because it is being published without restriction, it is not subject to
the U.S. Commerce Dept. restrictions on technical information.

6.2
The risk log is a detailed, weighted matrix to quantify risks associated with the mission. The
consequence definitions for each risk category are specific to the BitSat B1 mission, as is the analysis
matrix. This risk log is intended to provide direction in risk management during all phases of

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 71 OF 98

development. Risk logs are constantly updated during the build, test, and flight phases of a satellite,
passing through various stages of acceptance until an action finally accepts and completes a risk.

Table 16: Compiled Risk Definitions

Level Risk Category - Financial
Severe Would cause the project to exceed its financial margin
Major Would cause the project to consume 75% to 100% of its financial margin
Moderate Would cause the project to consume 50% to 75% of its financial margin
Minor Would cause the project to consume up to 50% of its financial margin
Insignificant Would cause the project financial margin to be eroded (or underfunded) by less than 10%

Level Risk Category - Schedule

Severe Would result in a requirement for >12 month launch delay
Major Would result in a requirement for >6 month launch delay
Moderate Would result in a requirement for >3 months launch delay
Minor Would result in a requirement for >1 months launch delay
Insignificant Would result in a requirement for <1 months launch delay

Level Risk Category - Project Outcomes (i.e. to display the potential of BitSat technology in achieving
broadcast and authenticate of bitcoin transactions at all times)
Severe Failure to broadcast and authenticate the latest bitcoin blockchain blocks or block headers
Major Failure to broadcast and authenticate blockchain blocks or header over some parts of the earth
Moderate Failure to demonstrate the spacecraft capabilities required for the BitSat Constellation
Minor Failure to broadcast and authenticate blockchain blocks or block headers in a timely fashion
Insignificant No material impact on block chain or block header communications, or spacecraft capability tests.

Level Risk Category - Legal / Contractual

Severe Unable to place BitSats into orbit, individuals sued by any entity for regulation violations, or
injunctions that halt the project.
Major Company(s) fined by any entity for regulations violations.
Moderate Formal correspondence with regulators, reprimanding the company publicly. No fines.
Minor Formal correspondence with regulators, reprimanding the company privately. No fines.
Insignificant Informal correspondence with regulators, advising alternate actions in the future.

Level Risk Category - Reputation

Severe The reputation of DSS or DSI is irrevocably destroyed or damaged.
Major The reputation of DSS or DSI is severely damaged requiring considerable effort and expense to
recover
Moderate The reputation of DSS or DSI is damaged and some effort and expense is required to recover
(forgotten in 6-24 months)
Minor The reputation of DSS or DSI is minimally affected and little effort or expense is required to recover
(forgotten in 1-6 months).
Insignificant The reputation of DSS or DSI is not affected and no effort or expense required to recover.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 72 OF 98

Rating Likelihood Criteria

Almost Is expected to occur at some time or multiple times during the project
Certain
Likely Would not be surprised if this occurred during the project
Possible May arise at some time during the project
Unlikely Would be a surprise if it occurred during the project
Rare Would be amazed if it happened during the project

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 73 OF 98

Risk Analysis Matrix

Consequence
Insignificant Minor Moderate Major Severe
Likelihood # 2 3 7 15 24
Almost 7 14 21 49 105 168
Certain
Likely 5 10 15 35 75 120
Possible 3 6 9 21 45 72
Unlikely 2 4 6 14 30 48
Rare 1 2 3 7 15 24
Risk Actions
Chair of the Project Board to be immediately notified; do not proceed with remediation until
Extreme >100
mitigation measures have been agreed
High <100 Chair of the Project Board to assess & direct remediation as necessary.
Medium < 36 Project Management Team to assess & remediate as necessary
Low <9 Manage via routine procedures; no specific action

BITSAT PRELIMINARY DESIGN REPORT

 DEEP SPACE INDUSTRIES BITSAT PRELIMINARY DESIGN REVIEW | PAGE 74 OF 98

Table 17: Risk Log for the BitSat Mission

Consequence
Description

Risk Rating
Likelihood

Measures
Category

Counter
(Identifies highest
Risk #

Risk Title Consequence in terms of Causes Actions

Safety, Cost, Performance or
Schedule)

1 Single Event Radiation may cause system failure High energy solar particles and Design in system resilience to
Outcomes

Moderate
Radiation before the BitSat concept is galactic cosmic rays can damage failure: reset commands, watch-

Reduce
Rare

Low
Upset demonstrated. electronics. dog timers, EDAC memory, etc.

2 Total Radiation dose slowly degrades New subsystems (including the Perform limited TID testing.
Outcomes

Moderate
radiation component performance payload) have not been flight-tested

Medium
Unlikely

Reduce
dose and their radiation tolerance is
exposure unknown.

3 Depleting Depleting the propellant would Control system design cannot be Limit the amount of propellant
Propellant prohibit orbit phase maintenance. If ground-tested, and cannot be 100% used per day, such that if the
Outcomes

Moderate

Medium
Unlikely

Reduce
the propellant is depleted before the sure of stability or performance, controller requests more that this
orbit phasing is demonstrated, then consuming excessive propellant. limit then the system shuts the
the BitSat system is not thoroughly Control software bugs. controller out until there is
verified. intervention from the ground.
4 Launch Slip Outside the control of the B1 Launch vehicle or primary payload is Maintain compatibility with the
contractor, the launch may be delayed CubeSat standard, and

Moderate
Schedule

Medium
delayed. environmental test to enveloping

Possible

Accept
worst-case LV conditions allows for
switching between LVs if long
delays occur and other launches
are available.
5 License FCC does not grant frequency of US Government wishes to impede Build a relationship with the
Contractual

refusal launch licenses secure bitcoin use regulators early in the project.

Unlikely

Reduce
Legal /

Severe
Bring advisers into the project who

High
have worked in government and
understand how to approach
sensitive issues.

– CONFIDENTIAL –
DEEP SPACE INDUSTRIES BITSAT PRELIMINARY DESIGN REVIEW PAGE 74 OF 98
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 75 OF 98

Consequence
Description

Risk Rating
Likelihood

Measures
Category

Counter
(Identifies highest
Risk #

Risk Title Consequence in terms of Causes Actions

Safety, Cost, Performance or
Schedule)

6 Licenses are FCC does not respond to license Not leaving sufficient time between File early.
Contractual

late request before launch filing and launch

Medium
Unlikely

Reduce
Legal /

Major
7 Deployable Deployable mechanisms do not Any new deployment mechanisms Use mature deployment systems.
mechanisms deploy correctly. The last-out carry risk. Depleted batteries at Seek means to deploy TT&C
Outcomes

Unlikely

Reduce
Severe
do not mechanism is the TT&C antenna, so launch could mean there isn't antennas first. Strive for design

High
deploy communications would not be enough charge to release the burn- simplicity.
correctly established with the spacecraft. wires.

8 Fuel leak Tank or valve leak would deplete the New fuel tank and valve designs may Thruster is based on design
propellant, prohibiting orbit phase leak in vacuum. delivered for flight to JPL. Thorough
Outcomes

Moderate

Medium
maintenance. If the propellant is testing is performed.

Unlikely

Reduce
depleted before the orbit phasing is
demonstrated, then the BitSat system
is not thoroughly verified.

9 Integration Integration issues take longer to solve All new spacecraft design can have Hire spacecraft integration team
issues than expected, or the spacecraft fails EMI issues. Any new subsystems with experience in propulsion,
environmental tests (e.g. the payload) could have issues. ADCS and CubeSat systems. Track
Multiple

Possible

Reduce
Major
May cause 6 month delay. progress closely. Maintain financial

High
margin to bring in external experts
if necessary. Plan carefully.
Emphasize internal design reviews.
Strive for design simplicity.

BITSAT PRELIMINARY DESIGN REPORT PAGE 75 OF 98

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 76 OF 98

Consequence
Description

Risk Rating
Likelihood

Measures
Category

Counter
(Identifies highest
Risk #

Risk Title Consequence in terms of Causes Actions

Safety, Cost, Performance or
Schedule)

10 Suppliers do Suppliers do not deliver on schedule Grad students quit from UT Austin. DSI is ordering as many
not deliver Principle investigator moves to components up front, and entering

Contingency
Moderate
Schedule

Medium
on schedule Georgia Tech before the thruster is into agreements with suppliers for

Possible
delivered and development stalls. its own missions. In a pinch these
Increasing demand for CubeSat components could be transferred
components causes suppliers to be to the BitSat project (at the cost of
too busy. delaying DSI's other projects).
11 Payload Cannot transmit at required data At the time of writing, the payload is The payload is very similar to a
Outcomes

does not rates in all conditions. a new system and the performance radio system being flown by

Medium
Unlikely

Reduce
Major
perform as cannot be guaranteed. another user in late 2014. Bugs
specified should be worked out before BitSat
CDR.
12 Spacecraft Anyone obtaining the uplink Agents with malicious intent or Several levels of security will be
hacked frequencies and codes can reprogram "having fun" could try to hack our implemented allowing controllers
the spacecraft, disabling it. Recovery system. DSI/DSS reputation to jail-break a hacked system at
is possible, but a "denial of service" damaged and outcomes not met. several levels, and

Medium
Multiple

type attack could be implemented. introduce/change lower level

Unlikely

Reduce
Major
controls. Private keys to be guarded
extremely carefully, and satellite
private keys to be generated on the
spacecraft and never exported.
Garzik and community to consulted
on best security methods.
13 Reaction Reaction wheels fail on orbit before Immature technology on CubeSats. Use the most mature wheels we
Outcomes

Moderate
wheel spacecraft capabilities are Hard to test on ground for the space can get hold of.

Medium
Unlikely

Reduce
lifetime demonstrated. environment.

BITSAT PRELIMINARY DESIGN REPORT PAGE 76 OF 98

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 77 OF 98

Consequence
Description

Risk Rating
Likelihood

Measures
Category

Counter
(Identifies highest
Risk #

Risk Title Consequence in terms of Causes Actions

Safety, Cost, Performance or
Schedule)

14 Subsystem CubeSat subsystems are often not There are many causes for Do not skimp on on-ground testing.
Outcomes

Moderate
immaturity mature, and can fail in complex and subsystem failure. Testing on the Develop test plans early. Strive for

Medium
Possible

Reduce
unexpected ways ground is the best way to catch the design simplicity.
bugs and fix them.

15 High tip-off High tip-off rate from launch vehicle Spinning launch vehicle. Deployer Use wide controller bandwidth
Outcomes

rate can block communications and make gives the satellite a kick. (100Hz) and near-omnidirectional

Medium

Reduce
Major
Rare
it impossible to detumble the TT&C antennas
spacecraft

16 Bitcoin Between payment and conversion to Fluctuation in bitcoin value of 10% is Use BitPay. It appears to provide
Financial

conversion dollars the value of bitcoin changes likely. the fasted conversion to cash.

Possible

Reduce
Major

High
rate and there is less money available Consider hedging if there is a delay
in the transfer.

17 Launch Rockets do not have 100% success Rocket failure. Loss of one of the Flying three spacecraft one two or

Moderate
Schedule

failure rate three B1 spacecraft three separate launches reduces

Medium
Unlikely

Reduce
the consequence of this risk. 3
month delay until next launch.

18 Components Redesign required due to supplies no Technology evolution. Increasing Order early. DSI is ordering as many
or longer making the components. Cost demand for CubeSat components. components up front, and entering
subsystems may increase. into agreements with suppliers for

Moderate

Medium
Multiple

Unlikely

Reduce
no longer its own missions. In a pinch these
available components could be transferred
to the BitSat project (at the cost of
delaying DSI's other projects).

BITSAT PRELIMINARY DESIGN REPORT PAGE 77 OF 98

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 78 OF 98

Consequence
Description

Risk Rating
Likelihood

Measures
Category

Counter
(Identifies highest
Risk #

Risk Title Consequence in terms of Causes Actions

Safety, Cost, Performance or
Schedule)

19 ITAR issues US Government stops or delays the Open-sourcing of spacecraft and Ensure that DSS and DSI implement
Contractual

project due to ITAR concerns. ground segment designs information controls.

Medium

Prevent
Legal /

Severe
Rare
20 Damning Open-sourcing the design allows The preliminary design serves to Acknowledge the "preliminary"
design internet community to quibble about prove that the system is feasible and state of the design. Develop
criticism the design before it is mature. can be made to work, it does not carefully considered information
Reputation

Extreme

Reduce
Severe
Likely
Potential competitors or anyone who completely specify a working release plan.
wishes to stop or impede the project system. Poor information handling
may take advantage of this to kill the and expectations management will
project or take it over. lead to criticism of any "gaps".

21 Divergence B1 and B2 will have differences that Inherent differences in complexity Expectation management and good
between B1 are not testable in B1 (i.e. ground between the two missions, advances design practices should reduce this
and B2 station may have different form from in hardware that are well suited for risk. Need to pay close attention to

Moderate

Medium
Multiple

Reduce
final user interface). B2 but not ready for B1, others ground station capabilities in

Likely
particular.

BITSAT PRELIMINARY DESIGN REPORT PAGE 78 OF 98

 DEEP SPACE INDUSTRIES BITSAT PRELIMINARY DESIGN REVIEW | PAGE 79 OF 98

The following risk analysis shows that the majority of the risks associated with BitSat are technical,
which can be reduced through good design. The reputation of DSS/DSI is also at high risk, more so
than most satellite projects, because of the open source nature of the program. More accurately, the
reputation of the company is at greatest risk because the concept of a “community” satellite design
is fairly novel.
The risk results matrix is intended to provide scope for assigning resources to resolve and/or mitigate
risks in different categories. This mechanism becomes increasingly effective the more diverse the
types of risks that are considered. If the risk log is mostly developed by engineers, as in this case, it is
naturally most likely that difficult technical risks will arise. If lawyers were to design a satellite,
certainly the risks would be challenging legal dilemmas along with technical risks that engineers
might not place emphasis on. Awareness of risk generation biases increases the value of a risk log.

Resource
Risk Results Weighted Average
Extreme High Medium Low Distribution to
Matrix Occurrence
Mitigate
Resource
Multipliers per 8 4 2 1 --- ---
Category
Financial 0 1 0 0 5% 7%
Legal 0 1 2 0 14% 14%
Outcomes 0 2 7 1 48% 39%
Schedule 0 0 3 0 14% 10%
Reputation 1 0 0 0 5% 14%
Multiple 0 1 3 0 19% 17%
Totals Risk Count 1 5 15 1 --- ---

6.3

6.3.1
Deep Space Industries has made best efforts to ensure that this report is comprehensive, consistent
and accurate, commensurate with the completion of the preliminary design phase. However it
deserves stressing that it is a preliminary design and not all the engineering issues have been
answered yet. When released to the open source community it is expected that mistakes will be
found and criticism will be leveled. The use of the MicroSat (or CubeSat) approach may also invite
criticism from those who are only familiar with more traditional approaches.
To ensure that this criticism is not damaging to the prospects of the project it is recommended to
stress that this is a preliminary design and that the detailed design phase will resolve a lot of open
questions. It might even be useful to invite criticism in a constructive way to help find any issues that

– CONFIDENTIAL –
BITSAT PRELIMINARY DESIGN REPORT PAGE 79 OF 98
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 80 OF 98

might have been overlooked, by asking that feedback be posted on a specific website or sent to an
email created for that purpose (and moderated by project insiders).

6.3.2
This design report has been cleared by the U.S. State Dept. of ITAR restrictions, and through its being
openly published, it is no longer controlled by the U.S. Commerce Dept. restrictions on technical
information.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 81 OF 98

7.0
The following table is a collected list of review items from Deep Space Industries’ Preliminary Design
Review on 7/27/2014. These items were generated by those present at this review.

Title Discrepancy Suggested Solution Resolution

Classification
Section

M12 Split and Split this into a requirement Verify constellation Done.
Detail for open source maintenance through the Requirement
satellite/CubeSat design proof of propulsion and split
and constellation tracking during the demo

Relevant
maintenance. You might mission. This will show that it
want to verify through correctable back to the plane
Requirements

simulation that your design of orbit. In the requirement,

will be capable of this for specify the limit of what is
the most likely orbits good enough (a number with
a way to measure it) for
"corrected" (and why).
Demo vs. Full Worth creating and tracking Be clear about these Done. New risk
Mission a tech and reputation risk differences (probably evolves added. Old item
about ways the demo will through development (how clarified
diverge from full mission these will be tested (later
Relevant

and therefore not test it e.g. than what is used for B1,
the ground station may higher risk) e.g. show a goal
have a different form than for cost, reliability, setup and
the goal for final user maintenance service.
interface Communicate about how this
Risk

affects marketing.
Frequency The frequency bands to be Make sure you have a written Will resolve
Band Trades used are not set and need (drawn?) plan for the path to early in Detailed
Planning more info to complete deciding frequency bands-- Design
trades and make a decision. what analysis, what testing,
Relevant

This may change design what FCC meetings, when,

requirements or schedule. and who. There should be a
method to ensure any
Telecom

limitations get put back into

requirements and down
through a design iteration

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 82 OF 98

Title Discrepancy Suggested Solution Resolution

Classification
Section

Scrub ConOps It sounded like some parts Go through your definitive Updated
of ConOps had been ConOps carefully and merge ConOps

Relevant
recently changed, especially your recent changes
ConOps

in the early part, and PDR

documentation is not
consistent.
M7 and M8 M7 and M8 need more Document this as developed. Clarified
Requirements

definition specific to what

Relevant
DSI can do, and they need
clear verification plans
(maybe to be specified in
software specs).
Compliance Suggest that propulsion unit NASA calls this
supplier is compliant with propellant
AFSPCMAN 91-710 Vol. 3 storage method

Relevant
Section 12.2 for compliance a "container"
with cycle and burst testing
Propulsion

for propellant tank. Analysis

can be performed in lieu of
testing, but testing is always
preferred.
NOAA License If cameras are added, even If a NOAA license is needed, Not currently a
Relevant

if they aren’t looking at the required info should be mission

Cameras

Not

Earth, may need NOAA easy to obtain, but obtaining requirement

license a license is [normally] a 120
day process
Thermal Worst-case hot and cold I would suggest having a FEA done during
Consideration thermal analysis backup plan, especially for detailed design
s assumption and results B2, if the spacecraft is
appear to be reasonable at running hotter than analyzed
Thermal

first glance, difficult to to be able to achieve mission,

assess without copy of the with a lower power output.
charts.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 83 OF 98

Title Discrepancy Suggested Solution Resolution

Classification
Section

Vibration Presented worst-case If flying multiple identical Vibration

Testing methods for vibration spacecraft on the same testing spec'd
testing (Qual model and launch, you can protoflight out when
Flight models or all one spacecraft and launch vehicle is
Environments Testing

Protoflight/Protoqual acceptance test the other determined

models). Conservative spacecraft. Also, typically only
assumptions are good, but one vibration test needed,
for different vehicles and either prior to integration
missions, there are typically into dispenser or after.
less conservative
approaches available.
Requirements At a PDR level you should Create the map Not common
Project Management

Map have a function map that CubeSat

Not Relevant
allocates verifiable practice
requirements to all
hardware/software
interfaces. This is a cost,
schedule, and technical risk
issue
Black Box Need to define the Ex. $2000 Phased Array vs. Not in scope.
Computation computation resource as a $3000 Parabolic Dish Receiver station
Not Relevant

Resource hardware/software detailed design

interface specification with is not in scope
Comms

certain functional of B1
requirements, not a black
box.
Demo vs. Full How much does the demo You need to keep your eye on Make clear
Mission relate to the production the end user requirements. recommendatio
system? There are cost, Be as clear as possible with ns in technical
schedule, and technical risks this to the customer. The report
Relevant

associated with divergence. current material invites the

customer into the discussion,
which is not inappropriate for
this level of design, but could
Comms

be construed as vacillation on
the trades as opposed to a
focused path through them

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 84 OF 98

Title Discrepancy Suggested Solution Resolution

Classification
Section

Driving Distribute the block has an These are real likely driving Latency clearly
Requirements intrinsic "time limit" of sixty requirements that were stated in Reqs.
Requirements

Relevant
minutes and QoS drawn out in discussion, they Uplink stations
improvements is to should be explicitly stated as clarified in
customer advantage up to system level requirements. ConOps
10 minutes Thirty seconds for block,
header a few seconds.
Bitcoin Time There will be a system The discussion drew out that Clarify in
master time for QoS there would be one true time, Verification
calculations and orbital "bitcoin" time. There was no Description in
control. It is critical that material on how that time Req Matrix that
there will be one root time would be related back to the ground
source, which you can operation of the spacecraft terminals

Relevant
relate to others but you do and the time/data necessary involved in
not want to divorce to establish attitude/position. testing QoS
operations from payload must maintain
Requirements

data accurate
network time.
Not all users are
aware of exact
QoS.
Hardening Hardening "definition is All use of the term hardening Clarification on
fishy" was the group should be replaced with an term added in
Requirements

Relevant

consensus at the PDR. This explicit articulation of what is Mission

needs to be clarified there being done in each instance. Requirements
are multiple requirements
for hardening that are not
verifiable as written
Plug-in/Pull- CubeSat requirement to The design commitment to CubeSat
out achieve plug-in/plug-out achieve this technology practices
technology… wherever possible is a value explained in
add to the design which report
should be explicitly shown
Relevant

both diagrammatically and by

alignment to key
requirements. This is one of
Requirements

the significant cost, schedule,

and technical risk
management features
intrinsic to the proposed
spacecraft.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 85 OF 98

Title Discrepancy Suggested Solution Resolution

Classification
Section

Constellation Constellation requirement is The "constellation" Requirement

Req separate requirement is an active trade split
that is conflated multiple

Relevant
Requirements

times with other

requirements (e.g., “stable
constellation", etc.).
Requirements should be
restated as clearly separate.
Uplink/User Phase 13 Hardened uplink Definition of Phase 13 in Terminology
Node node, not user node presentation identified as a improved in
Requirements

Relevant
user uplink in multiple ConOps
locations. Normal user nodes
are downlink only. Hardened
uplink nodes should not be
conflated with user nodes
Data Open ended data streaming Inclusion of explicit Blockchain is
Streaming authorization and self-verifying

Not Relevant
authentication provisions to
allow the authenticity of the
open ended data stream to
be established for the
applications system and the
Risk

flight system
Financial This is both a risk of success The two should not be Risk is well-
Market in the marketplace which is conflated, they are both real mitigated
Disruption an applications system and should be identified as
Not Relevant

problem and a marketing such

problem and a risk of
disturbance/cracking which
disrupts financial
transactions in a deleterious
Risk

manner.
Opensourcing Open sourcing of the Systems must be designed to BitSat will be
of the preliminary design is not a have sufficient protections operated with
Preliminary priori a risk. The notion of and overrides to ensure security by
Design security by obscurity as a intended operations through obscurity
Relevant

viable method for system all possible state transitions. because there is
protection is increasingly If the knowledge of how the no other viable
proving problematic system works compromises solution
the ability of the system to
function then the system is
Risk

not designed right.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 86 OF 98

Title Discrepancy Suggested Solution Resolution

Classification
Section

Radiation Gary will track down paper Follow-up with Gary Not a Review
Testing references from the Item
University of Maryland
Space Systems Lab
regarding results that
appear to show that

Not Relevant
relationship between
radiation effects and
component feature size is a
function of localizable
points of disoptimization
rather than an intrinsic
barrier to the use of
components with smaller
feature sizes in higher
Risk

radiation environments.
Meta data The meta data is the highest Some recursion to update the Acknowledged.
Highest priority followed by block documents is in order here. Documents to
Priority transfer. Application system be updated
priorities should be defined Relevant during Detailed
in the top level Design
requirements not just be a
fallout of detailed
Risk

discussions.
Hacking Spacecraft hacking is less of This story should be drawn Once on orbit
a danger in an opensource out as part of the value add the bootloader
Not Relevant

environment due to regular of the design process being firmware

inoculation/immune system offered by DSI cannot be fixed.
development DDOS cannot be
prevented by
Risk

"inoculation".
Deployment Do you mitigate This should be explicitly No control over
deployment risk by traded and the optimized deployment
enhanced control loop system may require both. mechanism. No
frequency or simplify the trade possible
Not Relevant

deployment mechanism? It
was suggested that you can
mitigate deployment risk by
enhanced control loop
frequency or by simplifying
the deployment
Risk

mechanism.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 87 OF 98

Title Discrepancy Suggested Solution Resolution

Classification
Section

ITAR ITAR mitigation by plug- It may be possible to address Issue is not

in/plug-out technology built ITAR mitigation by leveraging acquisition of
to defined plug-in/pull-out technology satellite
hardware/software built to defined technologies, it
interfaces? hardware/software is penalties

Not Relevant
interfaces. Opportunities to involved in
leverage the design to violating ITAR
achieve this may allow a
significant reduction in cost,
schedule, and/or technical
risk. Further investigation will
likely result in the affirmation
that ITAR controls designs not
Risk

Interface Specifications.
MIPS You can mitigate MIPS risk This should be explicitly laid This is planned

Relevant
largely by upfront testing out as part of your risk
which incrementally mitigation and test plans.
Risk

converges to space system

Global Uplink Uplink stations spread over Conflating the two may be of Not relevant for
Stations the globe. There is a limited utility. Find a B1 because a
difference between the consistent way to address single uplink
Not Relevant

ongoing opportunity which both aspects to draw out the system is

enhances the operation distinction. sufficient to
system versus what is demonstrate
required to establish and BitSat concept
maintain the operational
Risk

system.
3D CAD Model Regarding the BitSat 3D Make explicit that the Not relevant
Not Relevant
Engineering 2

CAD Model accuracy and precision of the until Detailed

model will be verified on an Design
Systems

ongoing basis by 3D printing

of test articles with increasing
fidelity.
Spacecraft Regarding the BitSat The BitSat Spacecraft CubeSat
Not Relevant
Engineering 2

Architecture Spacecraft Architecture Architecture diagram should practices

be defined as the initial explained in
Systems

instance of an opportunity to report

evolve a state model of all the
flows across interfaces

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 88 OF 98

Title Discrepancy Suggested Solution Resolution

Classification
Section

RAID RAID 1 absolute duplication The BitSat Spacecraft Does not need
is a simplification that architecture shall implement to be resolved
Engineering 2

Relevant
maximizes availability and a RAID 1 absolute duplication at this time
provides easier error of data as a simplification
Systems

correction schemes that maximizes availability

and provides easier error
correction schemes.
Software Are software reset The BitSat spacecraft CubeSat
Reset occurring at a function or architecture shall implement philosophy
Systems Engineering 2

process level or are you a defined software reset favors only two
rebooting the operating triage scheme which allows reset levels:

Relevant
system? for seamless use of error system reboot
correction schemes, process power cycling
level resets, function level and EDAC.
resets, mode reset and only
when necessary system
reboot.
Memory Memory margin needs to be The memory margins should Design report is
Margin explicit and should be a be explicitly shown and the explicit
Systems Engineering 2

margin sink to be inclusion of memory should

maximized be a designated margin sink
Relevant

to be maximized as the
design moves to
completion/launch. If you put
more memory it should be
put in to provide additional
margin.
USB 2.0 USB 2.0 or later should be a All operational system flight All data transfer
requirement and ground equipment shall budgets shall be
Systems Engineering 2

implement at least the USB prepared on all

v2.0 specification. Any use of data busses
Relevant

earlier specifications in the

demonstration system should
require an explicit waiver and
explanation on how the issue
will be mitigated for the
operational system.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 89 OF 98

Title Discrepancy Suggested Solution Resolution

Classification
Section

Bootloader Regarding the BitSat System should boot to Synchronicity

Bootloader preload environment and test not required

Not Relevant
Engineering 2

for all devices to deal with

asyncronicity, boot to the
Systems

host operating system and

then bring up the application
functions.
Housekeeping Do not forget to turn on log The system will be designed Added to
Engineerin

Relevant
on at the beginning of your to turn screen and all other software flow
Systems

preboot logging on at the earliest diagram

possible point in the preboot.
g2

7.1
Action Items Log
# Topic Document Section Description
1 FCC Licensing 7.0 Develop process for modifying payload operations
based on frequency options
2 CAD Model 7.0 Include dimensional errors in CAD. Assess for
accuracy
3 Payload 7.0 Prioritize header/metadata in transmission process
4 MIPS Budget 4.4.2 MIPS budget needs testing of software on the actual
hardware
5 TT&C Handling 4.4.3 TT&C handling functionality and flow needs to be
functional flow defined
6 ADCS algorithm 4.6 Create a simulation of the ADCS performance
simulation
7 S-band 4.8.1 The S-band antennas needs to be designed,
monopole simulated, built and tested
8 Batch 6.1.3 Investigate EM/PFM batch manufacturing cost
Production reduction techniques for environmental testing
Testing requirements with launch providers
9 “Hardened” 3.1 Define security of the uplink nodes
Definition
10 Ground Station -- Develop separate ground station design report based
Definition on results of BitBeam presentation during PDR.

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 90 OF 98

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 91 OF 98

Appendix 1: Calculations
1.1 Link Budget
BitSat BitSat
BitSat
Item Units Downink - Downink -
Uplink
S-band Ku Band
W4P W4P W4P
Signal Properties
Modulation N/A QPSK QPSK QPSK
Bits/Symbol 2.00 2.00 2.00
Data Rate MBPS 0.05 0.05 0.15
FEC rate unitless 0.75 0.75 0.75
Symbol rate MHz 0.03 0.03 0.10
Occupied Bandwidth MHz 0.05 0.05 0.14

Transmit
Transmitter On S/C On S/C Earth
Station
Frequency GHz 2.45 10.70 2.45
max 10
watts
Transmitter Power Watts 1.20 1.50 2.50 DC
power
see if 5
watts dc
Transmitter Power dBW 0.79 1.76 3.98 power
Ok?
orbital
Transmitter Line Loss dBW -0.50 -0.50 -0.50 average
ideally 5
10
possible
Transmit Total Gain dB 1.0 3.0 34.7
but
painful
also add
Eq. Isotropic
dBW 1.3 4.3 38.2 in the
Radiated Power peak

Orbital Information
Orbit Altitude (km) km 750.00 750.00 750.00
Elevation Angle deg 10.0 10.0 10.0
Propagation Path
km 2,262.36 2,262.36 2,262.36
Length

Channel Losses

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 92 OF 98

BitSat BitSat
BitSat
Item Units Downink - Downink -
Uplink
S-band Ku Band
Free Space Loss dB -167.32 -180.13 -167.32
Polarization Loss dB -0.50 -0.75 -0.50
Rain Attenuation dB -8.00 -8.00 -8.00
Cloud Attenuation dB -1.00 -1.00 -1.00
Other Atmospheric
dB -1.00 -1.00 -1.00
attenuation
Total Propagation
dB -176.82 -189.88 -176.82
Losses

Receive Antenna User User

On S/C
Properties basestation basestation
Antenna Aperture
dBi 32.0 42.0 0.0
Gain
Receive Antenna
dB -0.30 -0.30 -0.30
Line Loss
RX Antenna Pointing
dB -0.30 -0.30 -0.30
Error Loss
Receive Antenna
Gain with pointing dB 31.40 41.40 -0.60
error

Radom Losses no redone no redone no redone

Reflective Losses dB 0.00 0.00 0.00
Dissipative Losses dB 0.00 0.00 0.00
Transmission
1.00 1.00 1.00
Fraction (sigma)
Loss Fraction (1-
0.00 0.00 0.00
sigma)

Rx Antenna
Performance
Net Antenna gain dBi 31.40 41.40 -0.60
System Noise
K 140.00 250.00 200.00
Temperature
System Noise
dB 21.46
Temperature
G/T dB/K 9.94 17.42 -23.61

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 93 OF 98

BitSat BitSat
BitSat
Item Units Downink - Downink -
Uplink
S-band Ku Band
Wifi Interference
Calculation
proximity of nearest
m 1,500.00
wifi router
wifi router maximum
EIRP (per FCC part dBm 36.00
15)
wifi channel
MHz 16.00
bandwidth
propagation loss from
dB -103.76
router to base station
rx isotrop power dBm dBm -67.76
antenna gain in wifi
dBi -20.00
direction
rx power at input to
dBm -87.76
LNB/LNA

Received Signal on ground on ground on S/C

Rx isotropic power
dBm -145.53 -155.62 -108.65
dBm
Rx power at input to
dBm -114.13 -114.22 -109.25
LNB/LNA
kt dBm/Hz -177.14 -174.62 -175.59
N dBm -130.61 -128.09 -124.29
C/No dB Hz 63.01 60.40 66.34
CNR =
C/N C/N = 16.47 13.87 15.04
C/(N0B)
Eb/No 16.02 13.41 14.58
Req Eb/No dB 5 5 5
Implementation Loss dB 3 3 3
Margin in quiet area dB 8.02 5.41 6.58

-
C/No near wifi dB
26.37758113
-
Eb/No near wifi dB
73.36728117
Margin near wifi dB -81.37

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 94 OF 98

1.2 Thermal
Heat Transfer
N1 N2 N3 N4 N5 Space Earth Sun
N1 X X X X Cn+In E A+IRe Is
N2 X X X X Cn+In E A+IRe Is
N3 X X X X Cn+In E A+IRe Is
N4 X X X X Cn+In E A+IRe Is
N5 Cn+In Cn+In Cn+In Cn+In X E A+IRe Is

CubeSat Constants
CubeSat Width m 0.1
CubeSat Length m 0.34
Solar Panel 3U
length m 0.3254
Solar Panel 3U
width m 0.087
3U solar panel 32.54 cm x 8.7 cm between CubeSat
Area m2 0.0283098 rails
Rail Length m 0.34
Rail Width m 0.0065 Each rail. There are 2 per side.
3U Rail Area m2 0.00442 Anodized Al
Top/Bottom solar
panel Area m2 0.009831
Top/Bottom Rail
Area m2 0.000169 Anodized Al
Largest 3U cross
sectional Area m2 0.046245 only considered X & Y contribution
Solar Panel
coverage % % 60%
Kapton % % 40%
Stefan-Boltzman
Constant W/m2/K4 5.607E-08

Power Gen in Full Sun

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 95 OF 98

Power at BOL W 29.9

Max Power
Consumption W 21.5 w/ only active pointing
Safe Mode Power
Consumed W 1

Solar Cells
Emissivity % 87%
Absorptivity % 90%

Kapton
Emissivity % 57%
Absorptivity % 31%

Nitinol Spring Hinges

Thermal
conductivity k W/m/K 18 (compare to copper = 386)
Hinge cross-
sectional area m2 0.00002 20mm * 1mm
Hinge length
(body to solar
panel) deltaX m 0.015

Worst Case Hot - Constants

Solar Constant W.m2 1414
Albedo % 23%
Earth IR W.m2 224 SMAD 500km
% of orbit Sunlit % 100% Always direct sunlight

Worst Case Hot Beginning of Life (Hot Node 5)

Nodes 1-4 Qenv Node 5
Radiative input -
Solar W 26.57995798 9.230286576
Radiative input -
Earth Albedo W 4.662315831 9.206913156
Radiative input -
Earth IR W 5.904533956 4.7560464
Radiative Power Earth, Space & Sun
In Qenv W 37.147 23.193 only
Total Power In W 33.547 26.793

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 96 OF 98

Back Area- effective

Emissivity product m2 0.0161
Front Area- effective
Emissivity product m2 0.0212
Total Solar Area- effective
Emissivity product m2 0.0374 0.0996759
Electric power
transfer Qin W -4.95 21.5
Node Temp K 341.81 304.89
Node Temp
Celsius C 68.66 31.74
Node Emitted
Power W 28.60 48.29

Inter-Nodal Analysis
Conducted heat W 0.886125941 Copper Hinges
To solve circular
Target Conducted reference, make equal
Heat W 0.9 to row 65

Assume solar panel covers entire side,

Radiative for simplicity.
Solar Panel W W 0.3254
Solar Panel H H 0.3254
from RADIATIVE VIEW
FACTORS, Isidoro
Martinez © 1995-
Solar Panel L L 0.1 2014

radiative param h h 3.254

radiative param w w 3.254
radiative param a a 6.055530924
radiative param b b 0.956853837
radiative param c c 0.956853837
View Factor % 11.47%

Anodized
Area-Emissivity effective
product N1-4 m2 0.016136586

BITSAT PRELIMINARY DESIGN REPORT

 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 97 OF 98

Area-Emissivity effective
product Area N5 m2 0.02123235
Transfer W 0.011036612

Worst Cast Cold End of Life (Hot Node 1-4)

Nodes 1-4 Qenv Node 5
Radiative input -
Solar W 26.57995798 9.230286576
Radiative input -
Earth Albedo W 2.854143078 15.03972849
Radiative input -
Earth IR W 5.904533956 7.769123626
Radiative Power Earth, Space & Sun
In Qenv W 35.339 32.039 only
Back Area- effective
Emissivity product m2 0.0092
Front Area- effective
Emissivity product m2 0.0185
Total Solar Area- effective
Emissivity product m2 0.0374 0.086672847
Electric power
transfer Qin W -0.23 1
Node Temp K 359.79 287.15
Node Emitted
Power W 35.11 33.04

Inter-Nodal Analysis
Conducted heat W 1.743320447 Copper Hinges
Target Conducted
Heat W 5.9022

Assume solar panel covers entire side,

Radiative for simplicity.
Solar Panel W W 0.3254
Solar Panel H H 0.3254
Change this
if you only
want the
Solar Panel L L 0.1 panel width
radiative param h h 3.254
radiative param w w 3.254
BITSAT PRELIMINARY DESIGN REPORT
 BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 98 OF 98

radiative param a a 6.055530924

radiative param b b 0.956853837
radiative param c c 0.956853837
View Factor % 11.47%

Anodized
Area-Emissivity effective
product N1-4 m2 0.016136586
Area-Emissivity effective
product Area N5 m2 0.02123235
Transfer W 0.021938807

BITSAT PRELIMINARY DESIGN REPORT