all star payload interface control document outline all ......satellite with 10 w of power during...

Colorado Space Grant Consortium SYS.402.3 Interface Control Document Outline

1

ALL STAR

Payload Interface Control Document Outline

ALL STAR-SYS.402.3

Revision Date Authored By Description

0 7/9/10 Jessica Brown Initial Release

1 1/4/11 Jessica Brown

Riley Pack

Tyler Murphy

Additional

Details Added

2 6/17/11 Tyler Murphy

Riley Pack

Additional

Details Added

3 5/15/12 Tyler Murphy Forming fixes,

Revision on

Appendix I to

include receive

antenna cutouts

Approvals

Originator: Tyler Murphy Date

Systems Engineer: Colin Towery Date

Project Manager: Jesse Ellison Date

Mentor: Chris Koehler Date


2

Table of Contents 0. Author’s Contact Information ................................................................................................. 3 1.0 Introduction ............................................................................................................................. 3

1.1 Purpose and Scope ........................................................................................................... 3 1.2 Acronyms ......................................................................................................................... 4 1.3 Project Description ........................................................................................................... 4

2.0 Performance ............................................................................................................................ 5 2.1 Command and Data Handling .......................................................................................... 5 2.2 Flight Software ................................................................................................................. 5 2.3 Communications............................................................................................................... 6 2.4 Electrical Power System................................................................................................... 6

2.5 Attitude Determination and Control ................................................................................. 7

2.6 Position Knowledge ......................................................................................................... 7 2.7 Structure ........................................................................................................................... 7

2.8 Propulsion......................................................................................................................... 8

3.0 Interfaces ................................................................................................................................. 8 3.1 Physical interfaces ............................................................................................................ 8

3.1.1 Structural Interface.................................................................................................... 8

3.1.2 Launch Environmental Testing ................................................................................. 9 3.1.3 Electrical Connections ............................................................................................ 10

3.2 Electrical Interfaces ........................................................................................................ 10 3.2.1 Physical Layer ......................................................................................................... 10 3.2.2 Data Link Layer ...................................................................................................... 16

3.2.3 Network Layer ........................................................................................................ 19

4.0 Command Dictionary ............................................................................................................ 24 4.1 Bus Interface to Payload ................................................................................................ 24 4.2 Payload Interface to Bus ................................................................................................ 24

5.0 Restrictions ........................................................................................................................... 24 6.0 Appendix I: Payload Envelope Drawings Using Provided Structure ................................... 25

7.0 Appendix II: Payload Envelope Drawings with Custom Payload Structure ........................ 28 8.0 Appendix III: Data Sheets ..................................................................................................... 33


3

0.0 Author’s Contact Information

Jesse Ellison

ALL-STAR Project Manager

[email protected]

Colin Towery

ALL-STAR Systems Engineer

[email protected]

1.0 Introduction

1.1 Purpose and Scope

The ALL-STAR program is designed to accelerate the rate at which small research and

technology based payloads are able to be launched by providing the satellite bus. Customers can

purchase the ALL-STAR bus which includes the satellite structure, power, communications,

attitude determination and control, command and data handling, and position knowledge. This

Interface Control Document (ICD) outlines the planned interfaces between the ALL-STAR bus

and any potential ALL-STAR payload as well as the planned capabilities of the ALL-STAR bus.

The Payload must also meet all of the requirements pertaining to their design that are stated in

the Cal Poly CubeSat Design Specifications document and may not be explicitly called out

within this ICD.

This is the fourth release of the payload to bus ICD, and is subject to change between the

release date and the first ALL-STAR delivery.

Figure 1: ALL-STAR layout and exploded view


4

1.2 Acronyms

Acronym Definition

ICD Interface Control Document

ALL-STAR Agile Low-cost Laboratory for Space Technology Acceleration and

Research

SYS Systems

COM Communications

CDH Command and Data Handling

EPS Electrical Power System

GPS Global Positioning System

STR Structures

PROP Propulsion

FSW Flight Software

ACS Attitude Determination and Control System

GUI Graphical User Interface

SPI Serial Peripheral Interface

1.3 Project Description

ALL-STAR is a 3U CubeSat bus currently being designed and developed by students at

the Colorado Space Grant Consortium (COSGC) as a partnership with Lockheed Martin Space

Systems Corporation.

The ALL-STAR program is designed to accelerate the rate at which small research and

technology-based payloads are able to be launched by utilizing a standard 3U CubeSat bus.

Customers can purchase the ALL-STAR bus which includes the satellite structure, power,

communications, attitude determination and control, command and data handling, and position

knowledge.

ALL-STAR is a low-cost 3U CubeSat bus capable of supporting the 1-year on-orbit

operation of a variety of space-based research payloads that can be configured and ready for

flight in 6 months through a simplified payload hardware and software interface. The goal is to

make ALL-STAR as flexible as possible by making the subsystems and the payload interface

modular and by including enough capabilities that it can be used for a wide variety of small

payloads. The structure will conform to the 3U CubeSat Specifications set out by CalPoly while

leaving half the internal usable volume for the payload. After launch, the structure deploys

additional solar panels and a drawer containing all of the electronics to increase the available

surface area, this can be seen in Figure 2. This allows the power system to provide the entire

satellite with 10 W of power during nominal power draw and 30 W of power during a peak

power draw. The payload will receive around 5 W of power nominally and can use the peak

power draw when the satellite does not have a communications pass. The downlink rate of the

COM system will be at least 250 kbps with a goal of 1 Mbps. Before being sent to the ground,

data is stored in the command and data handling system. The CDH system also handles all

subsystem interactions and has the capability of reading analog and digital sensors from the

payload. The software is being written in a modular way that can be easily changed from

mission to mission through a GUI. An onboard GPS receiver sends the satellite’s position,

accurate to within 100 meters, and current time to the bus and payload. In addition, ALL-STAR


5

has an active pointing system, which will be able to point the satellite to within 1° of its desired

location with a knowledge accuracy of 0.2°.

Figure 2: ALL-STAR in flight configuration

2.0 Performance

2.1 Command and Data Handling

The Command and Data Handling system will communicate with and manage all

subsystems as well as monitor and send commands to and from the payload. The CDH system

will also store data for the payload. The CDH system will provide identical subsystem interfaces

for nearly wire-free integration as well as a similar connector for the payload. The ALL-STAR

user will be provided with the part number for the payload half of the connector.

Item Capabilities provided to payload

Maximum Bus Speeds 20 Mbps

Configuration Memory 62.5 kB

Data Memory 3276.8 MB

2.2 Flight Software

The payload’s configuration will be completed through a GUI, simplifying the integration

of the payload’s software. This GUI will allow for drag and drop configuration interactions.

The user will be able to identify commands that need to be passed to the bus as wells as what

data needs to be sent to memory or to the ground. They will be able specify analog sensors or

digital messages. The necessary code needed in the bus configuration is automatically

generated. The figure below shows a screen shot of the initial revision of the GUI. This item is

currently in progress and is not currently ready for distribution to ALL-STAR users.


6

Figure 3: Screen shot of the GUI in its current form

2.3 Communications

The communications system is responsible for transmitting data from the CDH system to

the ground. Using a software-defined radio and a cavity-backed spiral antenna, the

communications system will be capable of transmitting in the S-band ISM segment and receiving

in the UHF amateur segment near 430 MHz. The band will be defined by the ALL-STAR user

depending on the payload’s purpose or use. COM will also forward all commands from the

ground to CDH. The Colorado Space Grant Consortium uses a grounds station with a 3 meter

dish to close the link. ALL-STAR users are encouraged to use their own ground station with

similar or better capabilities.


Information downlink rate 250 kbps

Information uplink rate 9.6 kbps

2.4 Electrical Power System

Through the connector provided by the CDH, the payload will be provided with 3

different voltage lines, 3.3, unregulated battery, and 12 volts. The EPS team will be capable of

supplying the payload with at least 4 watts of power continuously, even after 1 year of operation.

EPS will also support a peak power draw of 30 W for 10 minutes once every orbit. The high

speed COM system requires this peak power draw to complete their link, however, during orbits

that do not require a pass, the payload may use this excess power.

Item Total capabilities Capabilities provided to payload


7

Nominal power draw 10 W 4-5 W

10 minute peak power draw

30 W 25 W

2.5 Attitude Determination and Control

The ACS system will use 3 reaction wheels for attitude control, a micro star tracker for

attitude knowledge, and magnetorquers and magnetometers for momentum dumping. ALL-

STAR shall be capable of complete 3-axis control and capable of compensating for external

attitude disturbances. ACS shall also be able to determine its attitude utilizing a “lost in space”

algorithm.


Attitude pointing accuracy 1°

Attitude knowledge accuracy 0.2°

Slew rate 180° in 95 seconds

Max amplitude of jitter 0.03°

2.6 Position Knowledge

Using a NovaTel GPS receiver, ALL-STAR may be capable of determining its position

to within 100 m. The GPS receiver will also relay accurate satellite time to the CDH system

which can then be distributed amongst the subsystems and payload.

2.7 Structure

The Structures team will provide the ALL-STAR user with a payload structure which

already includes the interface to the bus. The premade structure ensures that integration with the

bus will run smoothly. The payload section is allotted 2 kg. This includes the structure, which

weighs 81.19 g. The internal volume of the premade structure is equivalent to 1.07 U or 1214.5

cm3. There are certain situations in which the ALL-STAR user may want to create their own

custom structure. There will be strict requirements for a custom structure since it must be

capable of deploying from the external shell. The interface to the bus will be the same in either

case. The CG of the payload must also be within 2cm of the geometric center of the payload

section.


Length 6.50 in [16.50 cm]

Volume 77.93 in3 [1277 cm

3]

Mass 2000 g +0,-150 (Including the payload

structure)


8

2.8 Propulsion

The propulsion module is an optional add-on to the ALL-STAR bus. This optional

module cuts into payload volume and weight. The Propulsion module weighs 462 g and has a

length of 2.24 in [5.7 cm]. Using butane propellant, the ALL-STAR PROP module will be

capable of changing the satellite’s velocity by 10 m/s. The PROP module is not intended to

replace the attitude control system. It is the responsibility of the ALL-STAR user to get approval

from the launch provider to launch a propulsion unit.


ΔV 10 m/s

Length 4.25 in [10.8 cm]

Volume 48.53 in3 [795.3 cm

3]

Mass 1538 g (Including the payload structure)

3.0 Interfaces

3.1 Physical Interfaces

3.1.1 Structural Interface

The ALL-STAR provided payload structure consists of four side panels that will be

delivered to the payload customer. These panels consist of two identical top/bottom panels and

two identical left/right panels. The payload structure is shown below in Figure 4. All panels will

be hard anodized black.

Figure 4: Payload Structure

The payload envelope is shown in Figure 5.The sections that are hatched out are places

where components of the payload structure impinge upon the standard envelope. These

impingements are only at certain locations so they don’t affect the payload envelope for the

entire length of the payload section.


9

Figure 5: Payload Envelope Overview

Detailed drawings of the payload volume can be found in the Appendix I, which outlines

more specifics of the allowed usable volume. If the ALL-STAR user chooses to manufacture

their own payload structure, the interface positions and dimensions shown in Appendix II, must

also be included in their design.

3.1.2 Launch Environmental Testing

The environmental testing levels have been base lined to meet +6dB NASA GEVS levels.

This is to insure that the system is able to survive on any launch vehicle in positions that are

outside of the payload faring. This requirement will be revised as future profiles are developed

that better encompass the P-POD locations.


10

3.1.3 Electrical Connections

Electrical connections will be made through a single connector, shown below in Figure 6.

This connector provides the power as well as data transfer. This connector is from Samtec and

the part number is LS2-125-01-S-D. Either this connector or the equivalent right angle

connector can be used (LS2-125-01-S-D-RA1). The connector’s position is also shown in Figure

5. The top of the connector must be 0.039” inset into the payload section in order to properly

interface with the CDH backplane.

Figure 6: Electrical connector

3.2 Electrical Interfaces

3.2.1 Physical Layer

3.2.2.1 Connector

The LS2 connector family from Samtec has been chosen to interface between CDH and

the payload. The LS2-125-01-S-D-RA2 connector will be used on CDH while the LS2-125-01-

S-D-RA1 will be placed on the payload. The payload-CDH connector layout is shown in Figure

7 from the payload side of the interface. The function of each pin is described in Table 1. The

corresponding PCB layout on the CDH backplane is shown in Figure 8. Unless otherwise stated,

all signals are referenced to ground and have values between 0 V and 3.3 V.


11

Figure 7: Subsystem Connector Pinout

Function Pin Number Signal Type (Referenced by Payload)

Description

GND 1, 3, 5, 7, 9, 11, 13, 15, 41, 42, 43, 45, 47, 49

Ground Ground for the payload. This node is common to all components on the ALL-STAR bus.

VCC3.3_SW 2, 4, 6, 8 Power Input Regulated 3.3 V line for the payload.

VCCBAT_SW 10, 12, 14, 16 Power Input Unregulated battery line for the payload.

ISO_PWR_3.3 18 Power Input

Un-switched 3.3 V line for use in isolating the payload signals from CDH. See the isolation section below.

PLD_ADC0..7 17, 19, 20, 21, 22, 23, 24, 26

Analog Output

Analog outputs from the payload. These signals are routed to the payload ADC located on the CDH backplane.

D0..3 27, 29, 30, 31 Digital Input / Output

Digital signals to/from the payload. The functions of these pins can be configured on a mission-to-mission


12

basis.

INT 32 Output

Interrupt signal from the payload to CDH. This signal can be set high by the subsystem to indicate to CDH that it needs to send a packet.

SDA 33 Input / Output Serial data for the payload I2C backup bus.

SCL 34 Input Serial clock for the payload I2C backup bus.

SCK 35 Input Serial clock for the payload SPI interface.

MISO 36 Output Master In Slave Out line for the payload SPI interface.

MOSI 37 Input Master Out Slave In line for the payload SPI interface.

SS 38 Input Slave select for the payload SPI interface.

ACK 39 Output

Acknowledgement signal by the payload to the CDH PULSE. This signal must be pulled high by the payload after the PULSE signal is received.

PULSE 40 Input

Heartbeat signal supplied by CDH to the payload. The nominal frequency is 1 Hz. This signal also serves as a watchdog signal on CDH.

RESERVED 25, 28 N/A Reserved for future functionality.

VCC12.0_SW 44, 46, 48, 50 Power Input Regulated 12 V line for the payload.

Table 1: Subsystem Connector Pin Descriptions

Figure 8: Subsystem Connector Layout (Subsystem View, Board Edge Towards Top of Figure)


13

3.2.2.2 Isolation

The payload is responsible for ensuring that when its power is off, no portion of its

electronics can be partially or fully activated by a signal line from CDH. This means that some

form of signal isolation must be utilized on any pins that are inputs from CDH or common

between the payload and other systems. In particular, the SCK, MOSI, SS, PULSE, and D0-D3

must be isolated using a component with functionality similar to the TXB0108 chip from Texas

Instruments (TI). In addition, it is recommended that the MISO be isolated in a similar manner.

Finally, the SDA and SCK signals should be isolated using a chip with open-drain output

buffers, such as the P82B96 bus buffer from TI.

3.2.2.3 Primary Bus Protocol

The hardware protocol for the primary payload bus utilizes the Serial Peripheral Interface

(SPI) standard. The standard bus topology for 4-wire SPI is shown in Figure 9. On ALL-STAR,

CDH acts as the bus master and the payload is a slave device. Therefore, the payload is exposed

a 4-wire interface: MISO, MOSI, SCK, and SS. At all times, the interface is controlled

exclusively by the master. The interface is always operated in Mode 0, which is shown in Figure

10. During a transaction, the master will first activate SS for the subsystem (pull it low). Then,

on each rising edge of SCK, the master reads in the value of the MISO line while the payload

reads the value of the MOSI line. The data on MISO and MOSI is then changed on the falling

edge of SCK so that it is ready at the beginning of the next cycle. In this way, bidirectional

communication is facilitated between the master and each of the slaves. Once a byte of data has

been transferred, the master releases (pulls high) the SS line, which deactivates the subsystem’s

SPI interface hardware.

Figure 9: Typical SPI Bus Topology

The main bus protocol adds an additional interrupt signal to the standard SPI bus to make

requests by the payload easier to handle by CDH. Whenever the payload needs to send a packet


14

to CDH, it must toggle the INT line from low to high. The payload must then keep the line high

until CDH has responded to the request, at which point the line must be returned to a low value.

3.2.2.4 Backup Bus Protocol

Not supported in this revision.

3.2.2.5 Watchdog

In order to prevent software or hardware latch-ups, it is necessary for CDH to watch the

payload periodically. This functionality is implemented at two levels in the interface: the

physical layer and the network layer. On the physical layer, the watchdog is implemented via the

PULSE and ACK signals. Once every second, CDH will toggle the value of the PULSE signal.

This signal will nominally be driven by the GPS PPS signal, which is a very accurate 1 Hz

signal. Therefore, this signal can also be used to synchronize the clocks throughout the system.

When the payload receives the toggle on the PULSE line, it must toggle its ACK signal. If the

ACK signal is not toggled 10 times by the payload, the CDH will attempt to contact it over the

primary and backup buses. If no contact can be made, then the power to the payload will be

toggled to reset any latch-ups that may have occurred.


15

Figure 10: SPI Transfer Modes (Mode 0 Used for Subsystem SPI Interface)

3.2.2.6 Power

The payload will receive switched and regulated 3.3 V and 12 V power lines from EPS.

The switching of these lines will be controlled exclusively by CDH. EPS will also provide

(through the CDH backplane) access to the unregulated battery voltage. This power rail will also

be switched by CDH.

When CDH switches the power off for the payload, the payload is guaranteed that all

three power rails will be switched off simultaneously, barring differences in switching time

between the MOSFETs used to control the rails. Under nominal operation, there will be no way

that one or more of the rails for a subsystem are inactive while others are still active.

The specifications for each power rail are given in Table 2. Note that the maximum

current ratings are the absolute maximum for the system and that each subsystem must operate

within the current power budget.


16

Voltage Rail 3.3 V Battery 12 V

Minimum Voltage 3 V 6 V 10.8 V

Nominal Voltage 3.3 V 8.4 V 12.0 V

Maximum Voltage 3.6 V 10 V 13.2 V

Maximum Current 5 A 5 A or 30 W/ , whichever is smaller

2.5 A

Table 2: Subsystem Power Rail Specifications

3.2.2 Data Link Layer

3.2.2.1 Description

The Data Link Layer of the protocol is responsible for splitting up the larger Network

Layer packets into sizes that are manageable by the subsystems. Because different subsystems

have different resources available for this interface, some specific parameters of the data link

layer may vary from subsystem to subsystem, as described below.

3.2.2.2 Primary Bus Protocol

Frame Format

The format for each link layer frame is shown in Figure 11. Each frame contains two

bytes of overhead. The first, shown in purple in the figure, is the header. The header contains

two fixed bits (as basic error checking), a continuation bit, and the packet number. The

continuation bit indicates whether this frame is a continuation of a previous frame or if it is the

beginning of a new chain. If the continuation bit is set, then the frame is a continuation and the

packet number field contains the number of the packet, which is zero-indexed. If the

continuation bit is cleared, then the packet number instead indicates the number of packets in the

chain and the packet number is assumed to be zero.

0 1

Cont

Frame Number

Frame Length Frame Data

00 1 2 3 4 5 6 7 8 9

10 1 2 3 4 5 6 7 8 9 . . .

Figure 11: Link Layer Frame Format

Frame Processing

The processing loop for the link layer is slightly different for packets being sent to the

payload versus packets being sent to CDH. The procedure for the CDH to payload direction is

shown in Figure 12. At the start of the frame, CDH sends the header for the frame to the

payload. CDH then requests the response to the header from the payload, which can be one of

the values in Table 3. If the payload is able to process the frame, then it responds with the OK

token. If it is not currently able to process the frame but could in the future, then it response with


17

BUSY. Finally, if the payload would not ever be able to process the header or the header is

invalid, then the INVALID token is returned.

Send Header

Send Response

Response?BUSY

Send Frame Length

OK

Send Frame Data

Frame End?

NO

Start

YES

INVALID

CDH Action

Payload Action

More Frames?

YES Process Packet and Send Response

NO

End

Figure 12: CDH to Payload Frame Processing

Token Value

OK 1

BUSY 2

INVALID 3

Table 3: Header Response Tokens

Once the header has been accepted by the payload, then the length of the frame is sent by

CDH. Because the length is one byte, a maximum of 255 bytes can be sent in the data frame.

Following the length, CDH then sends the data in the frame. If there are more frames in the

chain (the number of frames is greater than 1), then this process is repeated until the entire packet

has been received. At that point, the packet is handled and a response is generated, which is

returned to CDH using the process in Figure 13. The overall process is almost identical as the

previous process, with the exception that the payload is now sending the data. Also, because

CDH drives the physical layer interface, there is no confirmation that the header is acceptable. It

is assumed that if CDH asks for the header that it will be able to handle any packet sent to it by

the payload.


18

Send Header

Send Frame Length

Send Frame Data

Frame End?NO

Start

YES

CDH Action

Payload Action

More Frames?

YES

EndNO

Figure 13: Payload Response to CDH Packet

When data needs to be sent from the payload to CDH, then the process in Figure 14 is

followed. First, the payload asserts its interrupt line to CDH. Then, CDH sends a packet header

with the number of packets equal to 0. This is the only time that this type of header is allowed,

and it signals to the subsystem that it should start sending its frame when it is ready. At this

point, the process is identical to that shown in Figure 13. Finally, when all of the payload frames

have been sent, CDH processes the packet and responds using the process in Figure 12. The

only deviation from this process occurs at the very end. Instead of processing the packet, the

payload instead ends the cycle and returns the response to the higher level application code.


19

Send Header with Number of

Packets = 0

Send Frame Data

Frame End?NO

Start

YES

CDH Action

Payload Action

More Frames?

YES

Process Packet and Send Response

NO

Assert Interrupt Line

Send Response

Response?

OK

INVALIDBUSY

Send Header

Send Frame Length

End

Figure 14: Payload to CDH Frame Processing

3.2.2.3 Backup Bus Protocol

Not implemented in this revision of the ALL-STAR bus.

3.2.3 Network Layer

3.2.2.1 Packet

Description

The Network Layer of the protocol contains the highest level of abstraction to the

application. It allows four types of messages to be sent from one location in the system to

another. Due to the flexible nature of the protocol, it will serve as the sole method of

communication between systems in the satellite.


20

Packet Format

The format of network layer packets is shown in Figure 15. The numbers along the top

of the packet are the bits in the packet. Descriptions of each packet field are given in Table 4.

As can be seen from the figure, there are 128 fixed bits (16 bytes) in each packet. The message

component is the actual data payload and takes one of two formats, shown in Figure 16. The

first format, which contains only a single parameter, is used by Data and Error message types.

The second format contains multiple parameters and is utilized by the Command and

Configuration message types. Each type of message is described in further detail in Table 5.

Finally, the format for the VariableTypeData fields in the messages is shown in Figure 17. For

any given type, the data is always stored in a big-endian manner, and for strings and arrays, the

data is stored in logical order (i.e. the first byte is sent first, etc). Furthermore, because the

length of the string is sent, it should not be null-terminated, and a null character will be treated

like any other within the string.

Source Destination Number

Resp

Succ

Type Opcode

Length Message CRC

00 1 2 3 4 5 6 7 8 9

10 1 2 3 4 5 6 7 8 9

20 1 2 3 4 5 6 7 8 9

30 1 2 3 4 5 6 7 8 9

40 1 2 3 4 5 6 7

990 1 2 3 4 56 7 8 9

60 1 2 3 4 5 6 7 8 9

70 1 2 3 4 5 6 7 8 9

80 1 2 3 4 5 6 7 8

. . .x0 1 2 3 4 5 6 7

Timestamp

8 950 1 2 3 4 5

6 7 8 9

100 1 2 3 4 5 6 7 8 9

110 1 2 3 4 5 6 7 8 9 9

x0 1 2 3 4 58

Figure 15: Format of Network Layer Packets

Field Name Size (Bits) Description

Source 16 Source location of the packet.

Destination 16 Destination location of the packet. Part of the extended opcode of the packet.

Number 16 Number of the packet. Note that if the packet is a response to another packet, the number field must match the number field of the original packet.

Timestamp 32 GPS time of the last PULSE signal sent out by CDH at the time that the packet was formulated.

Response 1 Indicates whether the packet is a response to a previous packet. A value of 1 indicates a response, while 0 indicates that the packet is not a response to another packet.

Success 1 Set to indicate that a packet’s desired operation was successful. Only considered when the Response bit is also


21

set.

Type 6 Field indicating which type of message is being sent. Part of the extended opcode of the packet.

Opcode 8 Identifier indicating which operation the packet is requesting. Part of the extended opcode of the packet.

Length 16 Length of the message portion of the packet.

Message 0 - 65535 Data payload of the packet. The type of message is indicated by the Type field.

CRC 16 16-bit checksum of the packet. The algorithm for the CRC is the CRC-CCITT algorithm.

Table 4: Packet Field Descriptions

Message Type

Type Field Value

Number of Parameter

s Parameter Type Description

Command 0 Multiple VariableTypeData

A command message represents a request for an action from one system to another. It may contain any number of parameters, which makes it a flexible option for many operations in a system.

Data 1 Multiple VariableTypeData

A data message represents an interaction in which one system sends data to another. In many cases, it will be used as a response to a command message. It may contain any number of parameters, which makes it a flexible option for many operations in a system.

Error 2 Multiple VariableTypeData

An error message represents an erroneous state in the satellite. It can result from either an invalid packet or from an invalid state from within a system. It may contain


22

any number of parameters, which makes it a flexible option for many operations in a system.

Configuration

3 Multiple VariableTypeData

A configuration message represents a change in configuration prompted by one system to another. The parameters in the message each describe the setting to be changed and the new value for said setting. As with other messages, multiple parameters are allowed.

Table 5: Description of Message Types

Parameter #1

Number of Parameters

Parameter #1 . . .Parameter #2 Parameter #N

Single Parameter Message

Multiple Parameter Message

Figure 16: Network Layer Message Types

The extended opcode for a given operation is determined by three fields in the packet: the

destination, the type, and the opcode. Each system must specify the commands that it will

handle from its corresponding control module on CDH as well as the commands that should be

handled directly by CDH without forwarding them on to the subsystem. A list of all of these

commands is contained in the Command Dictionary subsection. In addition, the payload must

implement the mandatory commands listed in that section.

3.2.2.2 Timing Synchronization

In order to ensure that the payload time is synchronized with that of the rest of the bus, a

timing synchronization protocol has been devised for the ALL-STAR system. The most

important portion of this protocol is the timing reference point, which is a precise moment in

time that the payload and CDH can agree on for sending time information. The most convenient

point is the time at which the payload sets its interrupt line high to send a message to CDH.


23

When CDH receives that signal, it captures the current time in seconds and sets the time stamp of

its response to that time. The payload then counts the number of rising edges that it receives on

the PULSE line and adds that number to the time that it receives from the time stamp in the CDH

response packet and resets its time to that value on the next PULSE rising edge. By doing so,

the payload can synchronize its time to that of CDH within a few microseconds or less.

Figure 17: VariableTypeData Packet Formatting

3.2.2.3 Protocol Implementation

The protocol described has been implemented to allow payloads at least an initial

implementation, if not a full solution for their interface code. The code can be broken into

three distinct sections. The first, the core interface, contains the high-level interface code to

be used by the payload application. After calling PacketInit(), the payload can use the

Dispatch() function to send data to CDH. In addition, payloads must define message

handlers in PACKET_HANDLER_ISR(). Example implementation have been included, as

well as a full set of documentation for all functions in the included PDF. In order to port the


24

interface to a new processor, the functions in ProtocolPort.h and ProtocolPort.c must be

updated from the current implementation using an Atmel ATXMEGA256A3 processor.

4.0 Command Dictionary

4.1 Bus Interface to Payload

4.2 Payload Interface to Bus

5.0 Restrictions


25

6.0 Appendix I: Payload Envelope Drawings Using Provided Structure


26


27


28

7.0 Appendix II: Payload Envelope Drawings with Custom Payload Structure


29


30


31


32


33

8.0 Appendix III: Data Sheets

all star payload interface control document outline all ......satellite with 10 w of power during...

Documents