bitsat design review - dssdss.co/assets/bitsat-design-pdr.pdf · 3.7 spacecraft data link budget...

The Next Generation of Cloud Computing

Conducted by Deep Space Industries Inc.

- - - -

Prepared Sergio Gallucci

Reviewed Craig Foulds

Signed off Daniel Faber

TM

BitSat BitSat

BITSAT B1 PRELIMINARY DESIGN REPORT| PAGE 2 OF 98

BITSAT PRELIMINARY DESIGN REPORT PAGE 2 OF 98

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.



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



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



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.



Table 1: Acronyms used in this document



-



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.



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



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



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?”

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

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

3.1

Table 4: Mission Requirements Matrix

Re

q #

Title Requirement Comment Verification Overview Verification

Method

M1 Distribute latest block

BitSat B1 system SHALL test distribution of the latest block to receiver stations

Latency across the network is the constraint on distribution time

Analysis of latency. May also demonstrate "distribution" in lab using setup representative of orbital geometries. If testing, ground terminals involved in latency testing must maintain accurate network time.

Analysis

M2 Distribute recent blocks

BitSat B1 system SHALL perform network tests of transmission of recent blocks or transactions

This is a useful but secondary goal. The scheduling algorithm will be developed with community input after the space communications capacity is known.

Demonstrate in lab using setup representative of orbital geometries

Demonstration

M3 Block transmission non-interruption

BitSat B1 satellite transmission SHALL not be interrupted during block transmission, to start transmitting another block.

It may be in the economic interest of users that interruption does occur. Address this at the same time that we look at the scheduling algorithm.

Prioritize transmit/receive order, ground test of flight software

Test

M4 Continuous block transmission

BitSat B1 system SHALL test continuous transmission from satellites

When the tail of the buffer is reached, transmission immediately begins anew at the buffer head

Long duration test on ground, to make sure it doesn't stop.

Test

M5 Satellite storage The BitSat B1 satellites SHOULD store the entire blockchain

This makes the satellite a full trusted node, which achieves the "hardening" requirements.

Ground test of flight software Test

M6 Satellite Block Retention

The BitSat B1 satellites SHALL add new blocks to the tail of its buffer, dropping one or more blocks from the head of the buffer.

Most likely, we can store the whole blockchain on the satellite. Scheduling algorithm should determine which is sent when. The "buffer" becomes a "schedule buffer".

Ground test of "schedule buffer" components of flight software

Test

M7 Hardened* Uplink Nodes

BitSat B1 system SHALL have hardened uplink nodes that transmit bitcoin blocks to the satellite(s), as they appear on the network.

This requirement became unnecessary when the spacecraft design achieved a true bitcoin node, performing block verifications. It continues to be useful to implement CDMA (or other anti-jamming techniques) + Com link Authentication

Ground station authentication Inspection



M8 Uplink nodes separate from P2P network

BitSat B1 uplink nodes SHALL have protections and gaps in place separating them from the primary P2P network

These are not trusted bitcoin nodes; these are hardened bitcoin nodes,

Design review of Ground station concept of operations

Inspection

M9 Uplink Authentication

BitSat B1 uplink notes SHALL send bitcoin blocks in a reliable, digitally authenticated data envelope to satellite

Note that having the entire block chain provides this authentication.

Uplink security verification Test

M10 Compatible with Inexpensive Downlink Station

BitSat B1 downlink stations SHALL be compatible with personal use ground terminals using sub-$10,000 hardware

Review of Downlink Station point-design Inspection

M11 Downlink station communication to client

When one or more new bitcoin blocks appear in the data, the BitSat B1 downlink stations SHALL submit this block to the local client for data processing.

Downlink station does not do processing. It is not a bitcoin node.

Demonstrate in lab Demonstration

M12 Satellite Constellation

BitSat B1 system SHALL consist of a constellation of satellites within one plane

Design Review Inspection

M13 Open-Source Design

BitSat B1 satellites SHALL be built with commercial off the shelf (COTS) hardware and an available design report (CubeSat parts when possible)

B1 shall be operated by DSI/DSS, but B2 long-term philosophy is that the community is able to design, improve, and manufacture new BitSats.

Design Philosophy Inspection

* “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.



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.



Table 5: Mission Level Concept of Operations Activities

Mission Level Activities

Phase Activity Description 1 Payload Manufacture and

Testing Engineering model and flight models, built and tested by BitBeam in California

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

maintenance Periodic phase and altitude maintenance maneuvers over the operational lifetime of the spacecraft

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 broadcast

Transmit blockchain metadata for a block (65 kb per block) in 2 seconds, with sufficient link 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 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



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.



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

Off Spacecraft is off (all power lines disconnected) during launch and when the EPS 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.

Detumble When the spacecraft is tumbling non-negligibly, ADCS actuators will slow the rate of tumble over several orbits.

Unpointed Payload on. Actuators at rest. Attitude sensors may be turned on. The spacecraft is free to tumble.

Pointing Payload on. The spacecraft points towards a specific direction, e.g. greatest profile for solar power collection.

Orbital Maintenance

The spacecraft performs station-keeping to keep in phase with the constellation. 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



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

EPS OBC TT&C Payload

ADCS GNC

Modes MTM MTQ Gyro

Sun-Sensor

RWs Cold Gas

Off

Boot

Load Code

Deploy

Safe

Detumble

Unpointed

Pointing

Orbit Maintenance



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

SCHD Scheduled Task

Scheduled tasks are run by functions running within the on-board computer and EPS that run in an interval.

SRST Soft Reset

Soft resets to bring the spacecraft into Safe Mode. This disengages it from potentially harmful situations or behaviors, and allows for the system to “get its bearings”. Examples include OBC-measured low battery voltage and ground command.

HRST Hard Reset If the OBC freezes, the EPS WDT will power cycle the spacecraft, returning it to Boot Mode. Ground Control can also hard-reset a spacecraft, bypassing the OBC.

SENS Sensor Attitude Determination and Guidance, Navigation, & Control sensors determine that an action should be taken by the spacecraft, e.g. the spacecraft is tumbling uncontrollably.

CMD Command Ground Control or flight software specifically tells the spacecraft to run a 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.



Table 9: A tabular layout of how modes transition.

To

From

Off

Bo

ot

Lo

ad

Co

de

De

plo

y

Sa

fe

De

tum

ble

Un

po

inte

d

Po

intin

g

Orb

ital

Ma

inte

na

nce

Off -

DEP, SENS

- - - - - - -

Boot HRST SRST

CMD, SCHD

FLAG CMD, SCHD

- - - -

Load Code HRST SRST - - SCHD - - - - Deploy HRST SRST - - SCHD - - - - Safe

HRST SCHD, SRST

- CMD - CMD CMD CMD CMD

Detumble HRST SRST - -

CMD, SCHD

- - - -

Unpointed HRST SRST - - CMD - - CMD - Pointing HRST SRST - - CMD - CMD - CMD Orbital Maintenance

HRST SRST - - CMD, SCHD

- - CMD -

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



Table 10: Spacecraft mass budget

Without

contingency (kg)

Contingency Including contingency

(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

(W) Duty 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



Total Power 18.5 1.0 6.0

Table 12: Power Consumption in modes where ADCS/GNC and Propulsion are on

Subsystem Peak Power Pointing Mode Orbital Maintenance

Mode

(W) Duty 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 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

Battery Depth of Discharge Units Safe Mode Payload-only Mode

Pointing Mode

Orbital Maintenance 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

Recharge Units Safe Mode Payload-only

Mode Pointing

Mode Orbital

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



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 Margin

8%

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.



Table 19: Payload Downlink and Uplink Budgets

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.

Time in MissionSize

Downlink

timeData Rate Contingency

Including

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

Time in MissionSize Uplink time Data Rate Contingency

Including

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



Table 20: OBC RAM Budget

Table 21: Payload Flash Budget

Estimated

Memory UsageContingency

Including

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

Time in Mission

Start (July

2015)1 year 5 year

(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



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



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.



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.



4.2.1

Phase Activity Payload Software Payload Hardware

1 Payload Manufacture and Testing

Test software developed. Documented Test reports generated and hardware delivered to DSI for integration.

2 FlatSat testing Run and update flight software during FlatSat stage.

Performance parameters tested. Data throughput clocked between OBC and payload. End-to-end blockchain communications tests.

3 Integration into bus

N/A N/A

4 Environmental Testing

Update performance parameters to reflect safe operations in simulated space environments

Run block uplink, downlink, during T-VAC.

5 Storage N/A N/A

6 Launch site testing

Upload new software at launch site if necessary

N/A

7 Launch N/A

8 Check-out and commissioning

Run health check Check telemetry

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 maintenance

Power off during station keeping

10 Transition to eclipse

Continue normal ops

11 Transition to day

Continue normal ops

12 Telemetry collection

N/A

13 User 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.


Transmit blockchain metadata for a block (65 kb per block) in 2 seconds, with sufficient link 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 Optimization

Change algorithm for prioritization of most recent block, make software or parameter changes to increase robustness

17 End of Mission N/A Turn off payload

17a Optional: Active De-orbit

N/A

18 Passive De-orbit

N/A



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).



4.3.1

Phase Activity Power


N/A

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)


Power system requires safe handling and a clean facility. Assembly performed with sufficient anti-static surfaces.


Power supplies for testing shall be high quality benchtop with low ripple current. Facility 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


Batteries shall be charged at the launch site.

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


Test nominal, minimal, and peak current power cycles. Peak test over short duration 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


Check battery current/voltage during testing. Solar panel output changes over time. Log panel performance. Log electrical connector possible changes (ohm differences).


Check that initial peak current is still the same as former peak current. Ground contact required for data comparison.


Check battery voltage during thermal cycling and ensure safe operational limits are 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


Continue providing operational power to subsystems. Check power parameters on the 10 second cycle and transmit out of schedule if normal thresholds are breached.








Continue providing operational power to subsystems. Check power parameters on the 10 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.




Power may be fed through propulsion and ADCS exclusively during this operational phase. 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


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.

Customization of the panel to provide slots in the body-mounted 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.

Figure 7: Deployed Clyde Space solar panels.



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.



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


N/A N/A

2 FlatSat testing Test software uploaded and verified with hardware-in –the-loop simulation, then integrated to flight hardware for functional ground disassembled testing.

Upload FlatSat test software to OBC. Anticipate frequent software rewrites during this phase.


Flight computer shall be disassembled from FlatSat config to integrated config. Data and power lines removed, then rerouted and installed during assembly of the other systems.

Upload environmental testing software


Flight computer will test on-board sensors. Compare to external test sensors. Calibrate hardware and update flight and test software. Run wired upload and wireless upload of test software.

Update test parameters with calibrated values.

5 Storage Duplicate on-board software during storage and check for parity after unpacking.

Save test/flight software. Store data on external HDD kept with B1. Track updates post testing and determine software upload schedule for launch site testing


Upload new flight software at launch site if necessary

7 Launch


Calculate tumble rate. Detumble if GO. Perform all operational modes and test all sensors. Reboot additional software from onboard memory and check against transmitted software for differences. Characterize all systems with functional test under operational modes (power cycles,

Ground control manages software distribution and uploads based on check-out results. Anticipate 90 minute cycles for main upload contact. Rewrite software if bugs identified.



eclipse, controlled tumble, simulated uncontrolled tumble). Determine best solution for detumble (MTQ, RXN wheel, propulsion, and anticipated time)


Process sensor data, upload blockchain over several orbits. Broadcast metadata, chain length, test during eclipse, sunlight, partials. Test with mobile uplink station for low-baud data first. Upload software for high-baud data (block).

Anticipate decreasing re-upload frequency. Flight software will become more permanent after passing checkout and early stage ops. Update environmental sensor calibration to measured/calculated values and reassess operational thresholds through edge-case testing.


OBC checks all systems during burn. Confirm that the minimal shock and increased thermal output does not put systems over safe levels. Close valves.

Software lock-out if commanded thrusting exceeds propellant expenditure limits.


Update software if behavior in eclipse differs drastically from expectations.



Process S/C health data and send to TT&C. Store on 10 second cycles and transmit package on request, plus per orbit single packet.

Anticipate occasional updates but nominal ops should be steady


Process payload blockchain uplink and store on flash memory with redundancy. Broadcast includes requests for the next block, and blocks are verified in OBC.



Broadcast block over the course of 30 seconds if data budget stays steady from test parameters. Broadcast includes requests for the next block, and blocks are verified in OBC.



Transmit blockchain metadata for a block (65 kb per block) in 2 seconds, with sufficient link 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.



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 Computer will degrade in performance over time. Power cycling, reboots, redundant processor checking, will extend life. Power consumption likely to increase slightly. Lattice damage may degrade OBC but B1 will fly below hazard rad belt.

Software errors are most likely failure mode. Many ways for this to happen. Reference Software Failure Mode report for more detail.


Engage valves on low flutter cycle (high thrust) Upload deorbit software if possible. Do not keep onboard during primary mission.



18 Passive De-orbit

Safe mode or dead Safe mode or dead

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.



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.



Figure 8: Bootloader functional flow diagram



Figure 9: Housekeeping task functional flow diagram



Figure 10: ADCS task functional flow diagram



Figure 11: GNC task functional flow diagram

Figure 12: Payload handling functional flow diagram



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


N/A N/A

2 FlatSat testing N/A Verify chassis meets spec and store hardware during FlatSat testing.


Passive coatings are robust to ground handling

Provide supporting jigs to simplify assembly. Connector and fastener routing pre-defined in CAD.


Thermocouples will verify thermal output during peak, nominal, and safe operating modes in TVAC testing.

Placement of accelerometers and spot (pulse) weld thermocouples to flight chassis.

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


N/A Remove tags and constraints before launch.

7 Launch N/A Launch inside the CubeSat deployer


On-board temperature logged for 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.

Solar panel deployment.


Periodic temperature checks. Transmit if anomalous, otherwise only transmit infrequent health checkups.

N/A

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



Phase maintenance

station keeping. Anticipate peak temperature for longer duration than initial functional test.


Monitor cold operational temperature and check against electrical current.

N/A


Monitor temperature changes. Check electrical current

N/A


Monitor and modify alarm thresholds if S/C health checks change over flight

N/A


Monitor and modify alarm thresholds if S/C health checks change over flight

N/A


Monitor and modify alarm thresholds if S/C health checks change over flight. Check thermal output when payload is on peak current against functional flight test results.

N/A


Maintain operation and modify if S/C health checks change over flight

N/A


Monitor and modify alarm thresholds if S/C health checks change over flight.

N/A

17 End of Mission Heat death is potential failure mode. Health checkups should tell ground operators when S/C thermal is a problem.

Structure performance unlikely to change. Mechanisms may degrade, but mechanisms are not mission-critical after initial checkout.


N/A N/A

18 Passive De-orbit N/A N/A

19 Data Analysis N/A N/A



- 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



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



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.



- 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.



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


N/A

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


Detumble when contact established using b-dot algorithm. Pulse all valves and check flutter speed- record on accelerometers.

9 Operations Testing Test all sensors and actuators. Test ADCS and GNC algorithms.


Orient, maintain orientation, check thrust vector against expected vector.

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.


Maintain attitude.

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.


Maintain attitude for propulsive maneuver

18 Passive De-orbit N/A




- 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.



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.



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.

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

-8000 -6000 -4000 -2000 0 2000 4000 6000 8000

Po

wer

(W

)

RPM

Micro-Wheel RPM vs. Power



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)



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.

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

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



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.


Transmit operational status during flight checkout. Send telemetry. Monitor 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.


Transmit and receive telemetry.

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


Continue nominal TT&C

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




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



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.



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


N/A

2 FlatSat testing Propulsion control board tested, with valve activation. Check “depletion protection”

3 Integration into bus N/A


Hot fire of cold gas thruster in vacuum, if test facility allows propellant in the chamber. Find 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




Check cold gas temperature and pressure. Pulse all valves and check flutter speed. Determine 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.


Orient, maintain orientation, check thrust vector against expected vector, perform burn with 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


N/A

14 Blockchain broadcast N/A


N/A

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.


Point in steady retrograde orbit from apoapsis and fire everything. Heat up of propellant from external systems is acceptable if mission is over. Keep some propellant onboard for small adjustments.

18 Passive De-orbit Safe mode or dead


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.



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



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.



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

Item Cost quantity per 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



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



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.



Figure 33: AIT workflow

Figure 34: AIT test preparation plan, for scheduling purposes

System Design Team (2-3 engineers)

Software Development Team (2-3

engineers)

Test Preparation Plan

We

ek

1

We

ek

2

We

ek

3

We

ek

4

We

ek

5

We

ek

6

We

ek

7

We

ek

8

We

ek

9

We

ek

10

We

ek

11

We

ek

12

We

ek

13

We

ek

14

We

ek

15

We

ek

16

FlatSat test documentaion write-ups

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

Co

ntr

ac

t S

tart

CD

R P

rese

nta

tio

n a

nd

Re

po

rt

Be

gin

Fla

tSa

t In

teg

rati

on



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



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.



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



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



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.



Rating Likelihood Criteria

Almost Certain

Is expected to occur at some time or multiple times during the project

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



Risk Actions

Extreme >100 Chair of the Project Board to be immediately notified; do not proceed with remediation until 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

Risk Analysis Matrix

Consequence

Insignificant Minor Moderate Major Severe

Likelihood # 2 3 7 15 24

Almost Certain

7 14 21 49 105 168

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



Table 17: Risk Log for the BitSat Mission R

isk

#

Risk Title

Ca

teg

ory

Description (Identifies highest

Consequence in terms of Safety, Cost, Performance or

Schedule)

Causes

Lik

eli

ho

od

Co

nse

qu

en

ce

Ris

k R

ati

ng

Co

un

ter

Me

asu

res

Actions

1 Single Event Radiation Upset

Ou

tco

mes

Radiation may cause system failure before the BitSat concept is demonstrated.

High energy solar particles and galactic cosmic rays can damage electronics.

Ra

re

Mo

der

ate

Low

Red

uce

Design in system resilience to failure: reset commands, watch-dog timers, EDAC memory, etc.

2 Total radiation dose exposure

Ou

tco

mes

Radiation dose slowly degrades component performance

New subsystems (including the payload) have not been flight-tested and their radiation tolerance is unknown. U

nlik

ely

Mo

der

ate

Med

ium

Red

uce

Perform limited TID testing.

3 Depleting Propellant

Ou

tco

mes

Depleting the propellant would prohibit orbit phase maintenance. If the propellant is depleted before the orbit phasing is demonstrated, then the BitSat system is not thoroughly verified.

Control system design cannot be ground-tested, and cannot be 100% sure of stability or performance, consuming excessive propellant. Control software bugs.

Un

likel

y

Mo

der

ate

Med

ium

Red

uce

Limit the amount of propellant used per day, such that if the controller requests more that this limit then the system shuts the controller out until there is intervention from the ground.

4 Launch Slip

Sch

edu

le

Outside the control of the B1 contractor, the launch may be delayed.

Launch vehicle or primary payload is delayed

Po

ssib

le

Mo

der

ate

Med

ium

Acc

ept

Maintain compatibility with the CubeSat standard, and environmental test to enveloping worst-case LV conditions allows for switching between LVs if long delays occur and other launches are available.

5 License refusal

Lega

l /

Co

ntr

actu

al FCC does not grant frequency of

launch licenses US Government wishes to impede secure bitcoin use

Un

likel

y

Seve

re

Hig

h

Red

uce

Build a relationship with the regulators early in the project. Bring advisers into the project who have worked in government and understand how to approach sensitive issues.



Ris

k #

Risk Title C

ate

go

ry Description

(Identifies highest Consequence in terms of

Safety, Cost, Performance or Schedule)

Causes

Lik

eli

ho

od

Co

nse

qu

en

ce

Ris

k R

ati

ng

Co

un

ter

Me

asu

res

Actions

6 Licenses are late

Lega

l /

Co

ntr

actu

al FCC does not respond to license

request before launch Not leaving sufficient time between filing and launch

Un

likel

y

Ma

jor

Med

ium

Red

uce

File early.

7 Deployable mechanisms do not deploy correctly O

utc

om

es

Deployable mechanisms do not deploy correctly. The last-out mechanism is the TT&C antenna, so communications would not be established with the spacecraft.

Any new deployment mechanisms carry risk. Depleted batteries at launch could mean there isn't

enough charge to release the burn-wires.

Un

likel

y

Seve

re

Hig

h

Red

uce

Use mature deployment systems. Seek means to deploy TT&C antennas first. Strive for design simplicity.

8 Fuel leak

Ou

tco

mes

Tank or valve leak would deplete the propellant, prohibiting orbit phase maintenance. If the propellant is depleted before the orbit phasing is demonstrated, then the BitSat system is not thoroughly verified.

New fuel tank and valve designs may leak in vacuum.

Un

likel

y

Mo

der

ate

Med

ium

Red

uce

Thruster is based on design delivered for flight to JPL. Thorough testing is performed.

9 Integration issues

Mu

ltip

le

Integration issues take longer to solve than expected, or the spacecraft fails environmental tests

All new spacecraft design can have EMI issues. Any new subsystems

(e.g. the payload) could have issues. May cause 6 month delay.

Po

ssib

le

Ma

jor

Hig

h

Red

uce

Hire spacecraft integration team with experience in propulsion, ADCS and CubeSat systems. Track progress closely. Maintain financial margin to bring in external experts if necessary. Plan carefully. Emphasize internal design reviews. Strive for design simplicity.



Ris

k #

Risk Title C

ate

go

ry Description



Causes

Lik

eli

ho

od

Co

nse

qu

en

ce

Ris

k R

ati

ng

Co

un

ter

Me

asu

res

Actions

10 Suppliers do not deliver on schedule

Sch

edu

le

Suppliers do not deliver on schedule Grad students quit from UT Austin. Principle investigator moves to

Georgia Tech before the thruster is delivered and development stalls.

Increasing demand for CubeSat components causes suppliers to be

too busy.

Po

ssib

le

Mo

der

ate

Med

ium

Co

nti

nge

ncy

DSI is ordering as many components up front, and entering into agreements with suppliers for its own missions. In a pinch these components could be transferred to the BitSat project (at the cost of delaying DSI's other projects).

11 Payload does not perform as specified

Ou

tco

mes

Cannot transmit at required data rates in all conditions.

At the time of writing, the payload is a new system and the performance

cannot be guaranteed.

Un

likel

y

Ma

jor

Med

ium

Red

uce

The payload is very similar to a radio system being flown by another user in late 2014. Bugs should be worked out before BitSat CDR.

12 Spacecraft hacked

Mu

ltip

le

Anyone obtaining the uplink frequencies and codes can reprogram the spacecraft, disabling it. Recovery is possible, but a "denial of service" type attack could be implemented.

Agents with malicious intent or "having fun" could try to hack our

system. DSI/DSS reputation damaged and outcomes not met.

Un

likel

y

Ma

jor

Med

ium

Red

uce

Several levels of security will be implemented allowing controllers to jail-break a hacked system at several levels, and introduce/change lower level 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 wheel lifetime

Ou

tco

mes

Reaction wheels fail on orbit before spacecraft capabilities are

demonstrated.

Immature technology on CubeSats. Hard to test on ground for the space

environment.

Un

likel

y

Mo

der

ate

Med

ium

Red

uce

Use the most mature wheels we can get hold of.



Ris

k #

Risk Title C

ate

go

ry Description



Causes

Lik

eli

ho

od

Co

nse

qu

en

ce

Ris

k R

ati

ng

Co

un

ter

Me

asu

res

Actions

14 Subsystem immaturity

Ou

tco

mes

CubeSat subsystems are often not mature, and can fail in complex and

unexpected ways

There are many causes for subsystem failure. Testing on the

ground is the best way to catch the bugs and fix them. P

oss

ible

Mo

der

ate

Med

ium

Red

uce

Do not skimp on on-ground testing. Develop test plans early. Strive for design simplicity.

15 High tip-off rate

O

utc

om

es High tip-off rate from launch vehicle

can block communications and make it impossible to detumble the spacecraft

Spinning launch vehicle. Deployer gives the satellite a kick.

Ra

re

Ma

jor

Med

ium

Red

uce

Use wide controller bandwidth (100Hz) and near-omnidirectional TT&C antennas

16 Bitcoin conversion rate

Fin

anci

al Between payment and conversion to

dollars the value of bitcoin changes and there is less money available

Fluctuation in bitcoin value of 10% is likely.

Po

ssib

le

Ma

jor

Hig

h

Red

uce

Use BitPay. It appears to provide the fasted conversion to cash. Consider hedging if there is a delay in the transfer.

17 Launch failure

Sch

edu

le Rockets do not have 100% success

rate Rocket failure. Loss of one of the

three B1 spacecraft

Un

likel

y

Mo

der

ate

Med

ium

Red

uce

Flying three spacecraft one two or three separate launches reduces the consequence of this risk. 3 month delay until next launch.

18 Components or subsystems no longer available

Mu

ltip

le

Redesign required due to supplies no longer making the components. Cost

may increase.

Technology evolution. Increasing demand for CubeSat components.

Un

likel

y

Mo

der

ate

Med

ium

Red

uce

Order early. DSI is ordering as many components up front, and entering into agreements with suppliers for its own missions. In a pinch these components could be transferred to the BitSat project (at the cost of delaying DSI's other projects).



Ris

k #

Risk Title C

ate

go

ry Description



Causes

Lik

eli

ho

od

Co

nse

qu

en

ce

Ris

k R

ati

ng

Co

un

ter

Me

asu

res

Actions

19 ITAR issues

Lega

l /

Co

ntr

actu

al US Government stops or delays the

project due to ITAR concerns. Open-sourcing of spacecraft and

ground segment designs

Ra

re

Seve

re

Med

ium

Pre

ven

t

Ensure that DSS and DSI implement information controls.

20 Damning design criticism

Rep

uta

tio

n

Open-sourcing the design allows internet community to quibble about

the design before it is mature. Potential competitors or anyone who wishes to stop or impede the project may take advantage of this to kill the

project or take it over.

The preliminary design serves to prove that the system is feasible and

can be made to work, it does not completely specify a working

system. Poor information handling and expectations management will

lead to criticism of any "gaps".

Like

ly

Seve

re

Extr

eme

Red

uce

Acknowledge the "preliminary" state of the design. Develop carefully considered information release plan.

21 Divergence between B1 and B2

Mu

ltip

le

B1 and B2 will have differences that are not testable in B1 (i.e. ground

station may have different form from final user interface).

Inherent differences in complexity between the two missions, advances in hardware that are well suited for

B2 but not ready for B1, others

Like

ly

Mo

der

ate

Med

ium

Red

uce

Expectation management and good design practices should reduce this risk. Need to pay close attention to ground station capabilities in particular.


– CONFIDENTIAL – BITSAT PRELIMINARY DESIGN REPORT 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.

Risk Results Matrix

Extreme High Medium Low Weighted Average

Occurrence

Resource Distribution to

Mitigate

Resource Multipliers per

Category 8 4 2 1 --- ---

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



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.



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.

Sect

ion

Title Discrepancy Suggested Solution

Cla

ssif

icat

ion

Resolution

Req

uir

eme

nts

M12 Split and Detail

Split this into a requirement for open source satellite/CubeSat design and constellation maintenance. You might want to verify through simulation that your design will be capable of this for the most likely orbits

Verify constellation maintenance through the proof of propulsion and tracking during the demo mission. This will show that it correctable back to the plane of orbit. In the requirement, specify the limit of what is good enough (a number with a way to measure it) for "corrected" (and why).

Rel

evan

t

Done. Requirement split

Ris

k

Demo vs. Full Mission

Worth creating and tracking a tech and reputation risk about ways the demo will diverge from full mission and therefore not test it e.g. the ground station may have a different form than the goal for final user interface

Be clear about these differences (probably evolves through development (how these will be tested (later than what is used for B1, higher risk) e.g. show a goal for cost, reliability, setup and maintenance service. Communicate about how this affects marketing.

Rel

evan

t

Done. New risk added. Old item clarified

Tele

com

Frequency Band Trades Planning

The frequency bands to be used are not set and need more info to complete trades and make a decision. This may change design requirements or schedule.

Make sure you have a written (drawn?) plan for the path to deciding frequency bands--what analysis, what testing, what FCC meetings, when, and who. There should be a method to ensure any limitations get put back into requirements and down through a design iteration

Rel

evan

t

Will resolve early in Detailed Design



Sect

ion


Cla

ssif

icat

ion

Resolution

Co

nO

ps

Scrub ConOps It sounded like some parts of ConOps had been recently changed, especially in the early part, and PDR documentation is not consistent.

Go through your definitive ConOps carefully and merge your recent changes

Rel

evan

t

Updated ConOps

Req

uir

eme

nts

M7 and M8 M7 and M8 need more definition specific to what DSI can do, and they need clear verification plans (maybe to be specified in software specs).

Document this as developed.

Rel

evan

t

Clarified

Pro

pu

lsio

n

Compliance Suggest that propulsion unit supplier is compliant with AFSPCMAN 91-710 Vol. 3 Section 12.2 for compliance with cycle and burst testing for propellant tank. Analysis can be performed in lieu of testing, but testing is always preferred.

Rel

evan

t

NASA calls this propellant storage method a "container"

Cam

era

s

NOAA License If cameras are added, even if they aren’t looking at Earth, may need NOAA license

If a NOAA license is needed, the required info should be easy to obtain, but obtaining a license is [normally] a 120 day process

No

t

Rel

evan

t Not currently a mission requirement

Ther

mal

Thermal Considerations

Worst-case hot and cold thermal analysis assumption and results appear to be reasonable at first glance, difficult to assess without copy of the charts.

I would suggest having a backup plan, especially for B2, if the spacecraft is running hotter than analyzed to be able to achieve mission, with a lower power output.

FEA done during detailed design



Sect

ion


Cla

ssif

icat

ion

Resolution

Envi

ron

men

ts T

esti

ng

Vibration Testing

Presented worst-case methods for vibration testing (Qual model and Flight models or all Protoflight/Protoqual models). Conservative assumptions are good, but for different vehicles and missions, there are typically less conservative approaches available.

If flying multiple identical spacecraft on the same launch, you can protoflight one spacecraft and acceptance test the other spacecraft. Also, typically only one vibration test needed, either prior to integration into dispenser or after.

Vibration testing spec'd out when launch vehicle is determined

Pro

ject

Man

agem

en

t Requirements Map

At a PDR level you should have a function map that allocates verifiable requirements to all hardware/software interfaces. This is a cost, schedule, and technical risk issue

Create the map

No

t R

elev

ant

Not common CubeSat practice

Co

mm

s

Black Box Computation Resource

Need to define the computation resource as a hardware/software interface specification with certain functional requirements, not a black box.

Ex. $2000 Phased Array vs. $3000 Parabolic Dish

No

t R

elev

ant

Not in scope. Receiver station detailed design is not in scope of B1

Co

mm

s

Demo vs. Full Mission

How much does the demo relate to the production system? There are cost, schedule, and technical risks associated with divergence.

You need to keep your eye on the end user requirements. Be as clear as possible with this to the customer. The current material invites the customer into the discussion, which is not inappropriate for this level of design, but could be construed as vacillation on the trades as opposed to a focused path through them

Rel

evan

t

Make clear recommendations in technical report



Sect

ion


Cla

ssif

icat

ion

Resolution

Req

uir

eme

nts

Driving Requirements

Distribute the block has an intrinsic "time limit" of sixty minutes and QoS improvements is to customer advantage up to 10 minutes

These are real likely driving requirements that were drawn out in discussion, they should be explicitly stated as system level requirements. Thirty seconds for block, header a few seconds.

Rel

evan

t

Latency clearly stated in Reqs. Uplink stations clarified in ConOps

Req

uir

eme

nts

Bitcoin Time There will be a system master time for QoS calculations and orbital control. It is critical that there will be one root time source, which you can relate to others but you do not want to divorce operations from payload data

The discussion drew out that there would be one true time, "bitcoin" time. There was no material on how that time would be related back to the operation of the spacecraft and the time/data necessary to establish attitude/position.

Rel

evan

t

Clarify in Verification Description in Req Matrix that ground terminals involved in testing QoS must maintain accurate network time. Not all users are aware of exact QoS.

Req

uir

eme

nts

Hardening Hardening "definition is fishy" was the group consensus at the PDR. This needs to be clarified there are multiple requirements for hardening that are not verifiable as written

All use of the term hardening should be replaced with an explicit articulation of what is being done in each instance.

Rel

evan

t

Clarification on term added in Mission Requirements

Req

uir

eme

nts

Plug-in/Pull-out

CubeSat requirement to achieve plug-in/plug-out technology…

The design commitment to achieve this technology wherever possible is a value add to the design which should be explicitly shown both diagrammatically and by alignment to key requirements. This is one of the significant cost, schedule, and technical risk management features intrinsic to the proposed spacecraft.

Rel

evan

t

CubeSat practices explained in report



Sect

ion


Cla

ssif

icat

ion

Resolution

Req

uir

eme

nts

Constellation Req

Constellation requirement is separate

The "constellation" requirement is an active trade that is conflated multiple times with other requirements (e.g., “stable constellation", etc.). Requirements should be restated as clearly separate.

Rel

evan

t

Requirement split

Req

uir

eme

nts

Uplink/User Node

Phase 13 Hardened uplink node, not user node

Definition of Phase 13 in presentation identified as a user uplink in multiple locations. Normal user nodes are downlink only. Hardened uplink nodes should not be conflated with user nodes

Rel

evan

t

Terminology improved in ConOps

Ris

k

Data Streaming

Open ended data streaming Inclusion of explicit authorization and authentication provisions to allow the authenticity of the open ended data stream to be established for the applications system and the flight system

No

t R

elev

ant

Blockchain is self-verifying

Ris

k

Financial Market Disruption

This is both a risk of success in the marketplace which is an applications system problem and a marketing problem and a risk of disturbance/cracking which disrupts financial transactions in a deleterious manner.

The two should not be conflated, they are both real and should be identified as such

No

t R

elev

ant

Risk is well-mitigated

Ris

k

Opensourcing of the Preliminary Design

Open sourcing of the preliminary design is not a priori a risk. The notion of security by obscurity as a viable method for system protection is increasingly proving problematic

Systems must be designed to have sufficient protections and overrides to ensure intended operations through all possible state transitions. If the knowledge of how the system works compromises the ability of the system to function then the system is not designed right.

Rel

evan

t

BitSat will be operated with security by obscurity because there is no other viable solution



Sect

ion


Cla

ssif

icat

ion

Resolution

Ris

k

Radiation Testing

Gary will track down paper references from the University of Maryland Space Systems Lab regarding results that appear to show that 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 radiation environments.

Follow-up with Gary

No

t R

elev

ant

Not a Review Item

Ris

k

Meta data Highest Priority

The meta data is the highest priority followed by block transfer. Application system priorities should be defined in the top level requirements not just be a fallout of detailed discussions.

Some recursion to update the documents is in order here.

Rel

evan

t

Acknowledged. Documents to be updated during Detailed Design

Ris

k

Hacking Spacecraft hacking is less of a danger in an opensource environment due to regular inoculation/immune system development

This story should be drawn out as part of the value add of the design process being offered by DSI

No

t R

elev

ant

Once on orbit the bootloader firmware cannot be fixed. DDOS cannot be prevented by "inoculation".

Ris

k

Deployment Do you mitigate deployment risk by enhanced control loop frequency or simplify the deployment mechanism? It was suggested that you can mitigate deployment risk by enhanced control loop frequency or by simplifying the deployment mechanism.

This should be explicitly traded and the optimized system may require both.

No

t R

elev

ant

No control over deployment mechanism. No trade possible



Sect

ion


Cla

ssif

icat

ion

Resolution

Ris

k

ITAR ITAR mitigation by plug-in/plug-out technology built to defined hardware/software interfaces?

It may be possible to address ITAR mitigation by leveraging plug-in/pull-out technology built to defined hardware/software interfaces. Opportunities to leverage the design to 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 Interface Specifications.

No

t R

elev

ant

Issue is not acquisition of satellite technologies, it is penalties involved in violating ITAR

Ris

k

MIPS You can mitigate MIPS risk largely by upfront testing which incrementally converges to space system

This should be explicitly laid out as part of your risk mitigation and test plans.

Rel

evan

t This is planned

Ris

k

Global Uplink Stations

Uplink stations spread over the globe. There is a difference between the ongoing opportunity which enhances the operation system versus what is required to establish and maintain the operational system.

Conflating the two may be of limited utility. Find a consistent way to address both aspects to draw out the distinction.

No

t R

elev

ant

Not relevant for B1 because a single uplink system is sufficient to demonstrate BitSat concept

Syst

ems

Engi

nee

rin

g 2

3D CAD Model Regarding the BitSat 3D CAD Model

Make explicit that the accuracy and precision of the model will be verified on an ongoing basis by 3D printing of test articles with increasing fidelity.

No

t R

elev

ant Not relevant

until Detailed Design

Syst

ems

Engi

nee

rin

g 2

Spacecraft Architecture

Regarding the BitSat Spacecraft Architecture

The BitSat Spacecraft Architecture diagram should be defined as the initial instance of an opportunity to evolve a state model of all the flows across interfaces

No

t R

elev

ant CubeSat

practices explained in report



Sect

ion


Cla

ssif

icat

ion

Resolution

Syst

ems

Engi

nee

rin

g 2

RAID RAID 1 absolute duplication is a simplification that maximizes availability and provides easier error correction schemes

The BitSat Spacecraft architecture shall implement a RAID 1 absolute duplication of data as a simplification that maximizes availability and provides easier error correction schemes.

Rel

evan

t

Does not need to be resolved at this time

Syst

ems

Engi

nee

rin

g 2

Software Reset

Are software reset occurring at a function or process level or are you rebooting the operating system?

The BitSat spacecraft architecture shall implement a defined software reset triage scheme which allows for seamless use of error correction schemes, process level resets, function level resets, mode reset and only when necessary system reboot.

Rel

evan

t

CubeSat philosophy favors only two reset levels: system reboot power cycling and EDAC.

Syst

ems

Engi

nee

rin

g 2

Memory Margin

Memory margin needs to be explicit and should be a margin sink to be maximized

The memory margins should be explicitly shown and the inclusion of memory should be a designated margin sink to be maximized as the design moves to completion/launch. If you put more memory it should be put in to provide additional margin.

Rel

evan

t

Design report is explicit

Syst

ems

Engi

nee

rin

g 2

USB 2.0 USB 2.0 or later should be a requirement

All operational system flight and ground equipment shall implement at least the USB v2.0 specification. Any use of earlier specifications in the demonstration system should require an explicit waiver and explanation on how the issue will be mitigated for the operational system.

Rel

evan

t

All data transfer budgets shall be prepared on all data busses



Sect

ion


Cla

ssif

icat

ion

Resolution

Syst

ems

Engi

nee

rin

g 2

Bootloader Regarding the BitSat Bootloader

System should boot to preload environment and test for all devices to deal with asyncronicity, boot to the host operating system and then bring up the application functions.

No

t R

elev

ant

Synchronicity not required

Syst

ems

Engi

nee

rin

g 2

Housekeeping Do not forget to turn on log on at the beginning of your preboot

The system will be designed to turn screen and all other logging on at the earliest possible point in the preboot. R

elev

ant Added to

software flow diagram

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 functional flow

4.4.3 TT&C handling functionality and flow needs to be defined

6 ADCS algorithm simulation

4.6 Create a simulation of the ADCS performance

7 S-band monopole

4.8.1 The S-band antennas needs to be designed, simulated, built and tested

8 Batch Production Testing

6.1.3 Investigate EM/PFM batch manufacturing cost reduction techniques for environmental testing requirements with launch providers

9 “Hardened” Definition

3.1 Define security of the uplink nodes

10 Ground Station Definition

-- Develop separate ground station design report based on results of BitBeam presentation during PDR.



Appendix 1: Calculations 1.1 Link Budget Item Units

BitSat Downink -

S-band

BitSat Downink - Ku Band

BitSat Uplink

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

Transmitter

On S/C On S/C Transmit

Earth Station

Frequency GHz 2.45 10.70 2.45

Transmitter Power Watts 1.20 1.50 2.50

max 10 watts DC

power

Transmitter Power dBW 0.79 1.76 3.98

see if 5 watts dc power Ok?

Transmitter Line Loss dBW -0.50 -0.50 -0.50 orbital

average ideally 5

Transmit Total Gain dB 1.0 3.0 34.7

10 possible

but painful

Eq. Isotropic Radiated Power

dBW 1.3 4.3 38.2 also add

in the peak

Orbital Information

Orbit Altitude (km) km 750.00 750.00 750.00

Elevation Angle deg 10.0 10.0 10.0

Propagation Path Length

km 2,262.36 2,262.36 2,262.36

Channel Losses



Item Units

BitSat Downink -

S-band


BitSat Uplink

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 attenuation

dB -1.00 -1.00 -1.00

Total Propagation Losses

dB -176.82 -189.88 -176.82

Receive Antenna Properties

User basestation

User basestation

On S/C

Antenna Aperture Gain

dBi 32.0 42.0 0.0

Receive Antenna Line Loss

dB -0.30 -0.30 -0.30

RX Antenna Pointing Error Loss

dB -0.30 -0.30 -0.30

Receive Antenna Gain with pointing error

dB 31.40 41.40 -0.60

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 Fraction (sigma)

1.00 1.00 1.00

Loss Fraction (1-sigma)

0.00 0.00 0.00

Rx Antenna Performance

Net Antenna gain dBi 31.40 41.40 -0.60

System Noise Temperature

K 140.00 250.00 200.00

System Noise Temperature

dB 21.46

G/T dB/K 9.94 17.42 -23.61



Item Units

BitSat Downink -

S-band


BitSat Uplink

Wifi Interference Calculation

proximity of nearest wifi router

m 1,500.00

wifi router maximum EIRP (per FCC part 15)

dBm 36.00

wifi channel bandwidth

MHz 16.00

propagation loss from router to base station

dB -103.76

rx isotrop power dBm dBm -67.76

antenna gain in wifi direction

dBi -20.00

rx power at input to LNB/LNA

dBm -87.76

Received Signal

on ground on ground on S/C

Rx isotropic power dBm

dBm -145.53 -155.62 -108.65

Rx power at input to LNB/LNA

dBm -114.13 -114.22 -109.25

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

C/N CNR = C/N =

C/(N0B) 16.47 13.87 15.04

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



1.2 Thermal Heat Transfer

N1 N2 N3 N4 N5 Space Earth Sun

N1 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 Area m2 0.0283098

32.54 cm x 8.7 cm between CubeSat 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



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 In Qenv W 37.147 23.193

Earth, Space & Sun only

Total Power In W 33.547 26.793



Back Area-Emissivity product

effective m2 0.0161

Front Area-Emissivity product

effective m2 0.0212

Total Solar Area-Emissivity product

effective 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

Target Conducted Heat W 0.9

To solve circular reference, make equal to row 65

Radiative Assume solar panel covers entire side, for simplicity.

Solar Panel W W 0.3254

Solar Panel H H 0.3254

Solar Panel L L 0.1

from RADIATIVE VIEW FACTORS, Isidoro Martinez © 1995-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 product N1-4

effective m2 0.016136586



Area-Emissivity product Area N5


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 In Qenv W 35.339 32.039

Earth, Space & Sun only

Back Area-Emissivity product

effective m2 0.0092

Front Area-Emissivity product

effective m2 0.0185

Total Solar Area-Emissivity product

effective 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

Radiative Assume solar panel covers entire side, for simplicity.

Solar Panel W W 0.3254

Solar Panel H H 0.3254

Solar Panel L L 0.1

Change this if you only want the panel width

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 product N1-4


Area-Emissivity product Area N5


Transfer W 0.021938807