ALL STAR Payload Interface Control Document Outline ALL STAR-SYS.402.3

Transcription

1 1 ALL STAR Payload Interface Control Document Outline ALL STAR-SYS Revision Date Authored By Description 0 7/9/10 Jessica Brown Initial Release 1 1/4/11 Jessica Brown Riley Pack Additional Details Added Tyler Murphy 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 2 Table of Contents 0. Author s Contact Information Introduction Purpose and Scope Acronyms Project Description Performance Command and Data Handling Flight Software Communications Electrical Power System Attitude Determination and Control Position Knowledge Structure Propulsion Interfaces Physical interfaces Structural Interface Launch Environmental Testing Electrical Connections Electrical Interfaces Physical Layer Data Link Layer Network Layer Command Dictionary Bus Interface to Payload Payload Interface to Bus Restrictions Appendix I: Payload Envelope Drawings Using Provided Structure Appendix II: Payload Envelope Drawings with Custom Payload Structure Appendix III: Data Sheets... 33

3 3 0.0 Author s Contact Information Jesse Ellison ALL-STAR Project Manager jesse.kane.ellison@gmail.com Colin Towery ALL-STAR Systems Engineer colin.towery@colorado.edu 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 4 Acronym ICD ALL-STAR SYS COM CDH EPS GPS STR PROP FSW ACS GUI SPI 1.2 Acronyms Definition Interface Control Document Agile Low-cost Laboratory for Space Technology Acceleration and Research Systems Communications Command and Data Handling Electrical Power System Global Positioning System Structures Propulsion Flight Software Attitude Determination and Control System Graphical User Interface 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 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 Maximum Bus Speeds Configuration Memory Data Memory Capabilities provided to payload 20 Mbps 62.5 kb 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 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. Item Information downlink rate Information uplink rate Capabilities provided to payload 250 kbps 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 7 Nominal power draw 10 W 4-5 W 10 minute peak power 30 W 25 W draw 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. Item Capabilities provided to payload Attitude pointing accuracy 1 Attitude knowledge accuracy 0.2 Slew rate 180 in 95 seconds Max amplitude of jitter 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 g. The internal volume of the premade structure is equivalent to 1.07 U or cm 3. 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. Item Capabilities provided to payload Length 6.50 in [16.50 cm] Volume in 3 [1277 cm 3 ] Mass 2000 g +0,-150 (Including the payload structure)

8 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. Item Capabilities provided to payload ΔV 10 m/s Length 4.25 in [10.8 cm] Volume in 3 [795.3 cm 3 ] Mass 1538 g (Including the payload structure) 3.0 Interfaces 3.1 Physical Interfaces 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 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 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 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 LS S-D. Either this connector or the equivalent right angle connector can be used (LS S-D-RA1). The connector s position is also shown in Figure 5. The top of the connector must be inset into the payload section in order to properly interface with the CDH backplane. Figure 6: Electrical connector 3.2 Electrical Interfaces Physical Layer Connector The LS2 connector family from Samtec has been chosen to interface between CDH and the payload. The LS S-D-RA2 connector will be used on CDH while the LS 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 11 Figure 7: Subsystem Connector Pinout Function Pin Number Signal Type (Referenced Description by Payload) 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. Un-switched 3.3 V line for use in ISO_PWR_ Power Input isolating the payload signals from CDH. See the isolation section below. PLD_ADC , 19, 20, 21, 22, 23, 24, 26 D , 29, 30, 31 Analog Output Digital Input / Output Analog outputs from the payload. These signals are routed to the payload ADC located on the CDH backplane. Digital signals to/from the payload. The functions of these pins can be configured on a mission-to-mission

12 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 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 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 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 Backup Bus Protocol Not supported in this revision 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 15 Figure 10: SPI Transfer Modes (Mode 0 Used for Subsystem SPI Interface) 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 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/, 2.5 A whichever is smaller Table 2: Subsystem Power Rail Specifications Data Link Layer 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 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 C o Frame 0 1 n Number t Frame Length Frame Data 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 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. Start CDH Action Payload Action Send Header Send Response End BUSY Response? INVALID YES More Frames? NO Process Packet and Send Response OK YES Send Frame Length Send Frame Data Frame End? NO 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 18 Start CDH Action Payload Action Send Header Send Frame Length Send Frame Data NO Frame End? YES More Frames? NO End YES 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 19 Start CDH Action Payload Action Assert Interrupt Line Send Header with Number of Packets = 0 Send Response BUSY Response? INVALID End OK Send Header YES Send Frame Length Send Frame Data More Frames? NO Process Packet and Send Response NO Frame End? YES Figure 14: Payload to CDH Frame Processing Backup Bus Protocol Not implemented in this revision of the ALL-STAR bus Network Layer 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 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 Timestamp R S e u Type s c p c x Opcode x Length Message CRC 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 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 Data payload of the packet. The type of message is indicated by the Type field. CRC 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 Command 0 Multiple VariableTypeData Data 1 Multiple VariableTypeData Error 2 Multiple VariableTypeData Description 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. 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. 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 22 Configuratio n 3 Multiple VariableTypeData Table 5: Description of Message Types any number of parameters, which makes it a flexible option for many operations in a system. 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. Parameter #1 Single Parameter Message Number of Parameters Parameter #1... Parameter #2 Parameter #N 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 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 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 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 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 Appendix I: Payload Envelope Drawings Using Provided Structure

26 26

27 27

28 Appendix II: Payload Envelope Drawings with Custom Payload Structure

29 29

30 30

31 31

32 32

33 Appendix III: Data Sheets