DESIGN OF A CUBESAT PAYLOAD INTERFACE. Jason Axelson Department of Electrical Engineering University of Hawai i at Mānoa Honolulu, HI ABSTRACT

Transcription

1 DESIGN OF A CUBESAT PAYLOAD INTERFACE Jason Axelson Department of Electrical Engineering University of Hawai i at Mānoa Honolulu, HI ABSTRACT Typically, a complete satellite will be designed around each payload. This has several drawbacks, such as larger budgets and a longer development cycle. However, it does not need to be this way. A standardized payload interface can help alleviate these issues and allow for a lighter budget and a tighter development schedule. To avoid these problems a modular payload interface was designed to support multiple CubeSat payloads. A large part of this work involved designing the Application Programming Interface for the payload to interact with the satellite s main microprocessor. The motivation for a modular interface is to reduce the budget and development schedule. INTRODUCTION The main advantages of CubeSats over larger, more traditional commercial satellites are the shorter development time and lower cost. In addition, CubeSats are also a fantastic tool for introducing students to the various interrelated aspects of satellite design. The purpose of my project is to ease the challenge of developing a CubeSat for any arbitrary future missions by developing a standard CubeSat payload interface. Upon the successful completion of my project, new CubeSat teams will find it easier and more efficient to integrate a new payload into their design. My proposal focuses on creating an application programming interface (API) for communicating with the payload. OVERVIEW An API would allow CubeSat teams to write code once and then use it on multiple processors. However, there is more to the payload interface than just the API. There are also voltage and data connections to consider. The voltages provided will vary from satellite to satellite but generally there will be at least 3.3V and 5V provided. It is important to note that the choice of voltages provided by the hardware is completely orthogonal to the design of the API. The only thing that matters for the API are the peripheral connections to the payload such as SPI, I 2 C, and UART. Figure 1 shows the basic form of the API. It shows how the satellite team will write code that will target the API that will then run on different processors.

2 Figure 1 API Overview PURPOSE OF THE APPLICATION PROGRAMMING INTERFACE The purpose of the application programming interface is to provide one interface to the processor of the satellite. Ideally this would mean that any code written that complies with the API will work on any processor supported by the API. However, this level of support would be counterproductive. It would entail a much larger initial expenditure in creating the API because many more cases would need to be considered, rather than just the common cases. Instead the API focuses on easing the important task of working with the various communication protocols, and automating common tasks. HARDWARE The PIC microprocessor platform, which was developed by Microchip, was chosen for this project because I have experience working with this family of microprocessors. In particular the dspic33f family of PIC microprocessors was used to prototype the various aspects of the payload interface. The dspic33f family was chosen largely because it provides Direct Memory Access (DMA). DMA is a technology that allows a peripheral controller to directly access system memory. This means that the peripheral can happily be transferring data without the processor being involved at all (besides some setup and teardown). Have you ever noticed your computer slow to a crawl as you transfer you photography collection to your USB stick? DMA helps avoid these types of situations. So instead of the processor controlling the flow of information, it can happen in the background. However, since the PIC is not the only microprocessor commonly used on satellites, I also researched the AVR family of microprocessors. It has been used by many other spacecraft programs such as the University of Colorado s DANDE (Drag and Atmospheric Neutral Density Explorer), which uses a 32-bit Atmel AVR as the main processor as well as several other AVR chipsˡ. My experience with the Arduino and AVR will be detailed in the section titled: Working with the AVR.

3 API DETAILS There are two main parts to the API, the interface itself, and the drivers. The interface is an abstract concept that is implemented by the drivers. This means that the API is basically a contract that needs to be described while the drivers actually need to be implemented. At first the plan was to implement a driver for both PIC microcontrollers and AVR microcontrollers. However, after further investigation it was decided that an API that worked on both platforms would not be feasible due to the large differences between the two platforms. Some of the differences include entirely different registers with a different set of semantics. This means that translating between the two would hide too much of the implementation details which would eventually become a net negative for the satellite team. PROTOCOLS One of the major tasks for the microprocessor of any satellite is to interface with the many peripherals aboard the satellite. Therefore working with the many protocols used by peripherals is one of the primary requirements for the API. The function names in the API are prefixed with ss, which stands for small satellite. This is to make it clear that this code is specific to the Small satellite lab, to help improve readability of the code. As an example I will go over I 2 C in detail. I 2 C Inter-Integrated Circuit (I 2 C) is a two wire serial communication protocol often used for satellite peripherals. Table 1 shows a listing of the low-level I 2 C commands in the API, while Table 2 shows the higher-level commands that are built on top of the low-level commands. It is important to note that it is not the intention that the satellite programmers only use the high-level commands, they are only included as a convenience to make the code easier to write, read, and maintain. Table 1 I 2 C Low-level Commands Function Name Description ss_acki2c Generate I 2 C acknowledge condition ss_closei2c Disable the I 2 C module ss_configinti2c Configure interrupts for I 2 C ss_datardyi2c Checks if the receive buffer is full ss_idlei2c Generate I 2 C wait condition and wait until I 2 C bus is idle ss_mastergetsi2c Get a set length string from I 2 C bus ss_masterputsi2c Write a string to the I 2 C bus ss_masterreadi2c Read a byte from the I 2 C bus ss_masterwritei2c Write a byte to the I 2 C bus ss_nacki2c Generate I 2 C negative acknowledge condition ss_openi2c Configures and enables the I 2 C module ss_restarti2c Generate I 2 C restart condition ss_starti2c Generate I 2 C start condition ss_stopi2c Generate I 2 C stop condition

4 Table 2 I 2 C High-level Commands Function Name Description ss_startwrite Start a write command to listed recipient ss_startread Start a read command to listed recipient ss_sendstringi2c Sends a string to the listed recipient ss_readdatai2c Reads data from the listed recipient The low-level I 2 C functions are based on the functions provided by the PIC peripheral library. They are intended to present a more uniform interface to the peripherals than is provided by the peripheral library itself. Also, I avoid the need to have multiple versions of the same function, for example the PIC peripheral library has multiple versions of most of the above functions corresponding to the multiple I 2 C peripheral modules. So for example there would be OpenI2C1 and OpenI2C2, if you want to enable the first I 2 C module you need to use OpenI2C1, and if you want to use the second you need to use OpenI2C2. Another benefit to creating a wrapper over the PIC peripheral library is that since the peripheral library is not perfect, there are bound to be bugs or suboptimal behavior within the library. By creating a wrapper for the library, it is possible to fix those bugs by simply implementing our own version of the function in the wrapper rather than calling the PIC peripheral library. Other Protocols Of course I 2 C is not the only protocol that is worth implementing. While, the other protocols will not be described in detail, they have still been implemented and tested, although not to the extent that I 2 C has. The other communication protocols implemented include UART, GPIO, ADC, and most of SPI along with some general helper functions such as delay and debug facilities. UART (Universal Asynchronous Receiver/Transmitter), is also known as serial or RS UART is the serial transmission of bytes over a single wire (in each direction). It is commonly used by devices such as radios and modems. GPIO (General Purpose Input/Output) is used for digital input and output, such as flashing an LED or reading a digital line. ADC (Analog to Digital Conversion) is reading an analog value from a pin and converting it to a digital value. It is commonly used in temperature sensors and some battery monitors. SPI (Serial Peripheral Interface) is similar to UART, but includes a clock running from the master to the slave as well as inputs to enable or disable each individual slave device. SPI is most commonly used for EEPROMS which are a common means of data storage on satellites. SPI is sometimes preferred over I 2 C because it has a significantly higher data transfer rate. Delay functions are useful for timing purposes as well as to aid in debugging. Without using delay functions, many operation will happen much faster than the human eye is able to detect. For example, an LED will blink so quickly that it will appear to always be on to the casual observer, and some type of debugging device will be necessary to discern the rapidly changing voltage, such as Logic or an oscilloscope.

5 WORKING WITH THE AVR As part of the project I attempted to generalize the API to the AVR microcontroller platform. To this end I purchased two Arduino Duemilanove s. Arduino is a platform that is based on the AVR family of microcontrollers; in this case the Duemilanove is based on an ATmega328. Arduino provides a set of libraries that make working with the microcontroller much simpler, but at the same time restrict advanced techniques. For this reason, Arduino makes a poor choice for a satellite project. Both the Arduino and AVR were researched and tested. It was concluded that there is not enough benefit to extending the API to cover the AVR microcontroller to offset the high costs. Also not many people at UH have experience working with the AVR compared to those that have experience working with PICs. TESTING THE API The API has been tested with several common peripherals. Of course the simplest peripheral is a simple blinking LED. For this only the STDIO (Standard Input/Output) pins were needed. This was mostly a test about getting the PIC working to an acceptable level. After getting basic input and output working the next step was to try one of the various communication protocols. I 2 C was selected because it is relatively simple, and is commonly used on satellites. Since I 2 C is a high-speed serial protocol, it is difficult to debug with a simple multimeter. An oscilloscope can help, but it is rather limited and does not help you analyze the protocol and it is easy to miss the short transmissions altogether. To deal with issues a Saleae Logic Analyzer was purchased. The Saleae Logic Analyzer greatly simplifies the task of debugging the common communication protocols. Figure 2 shows an example of debugging the API with Logic using the I 2 C protocol. Note that it is able to capture only when pin 3 s (I 2 C SDA) value changes from 1 to 0, which indicates the I 2 C start condition (labeled by logic with Start ). Figure 2 Example I 2 C Debugging with Logic Furthermore it is easy to see that we are doing an I 2 C write to address 0x9, which is the address of the BlinkM smart LED ˡ. Next we write the hex value of 0x67 which has the ASCII value c, which stands for the command Get current RGB ColorError! Bookmark not

6 defined.. For this command it is necessary to first write a c to the BlinkM and then generate a repeated start (restart) condition (noted by the start label on the right of Figure 2). The repeated start condition is then followed by a read of 3 bytes to read back the RGB color value. ss_openi2c(1); // Defaults are okay (using 1 st I2C Module) ss_starti2c(1); // Generate I2C start condition ss_startwritei2c(1, 0x09); // Start write command to 0x09 (BlinkM) ss_writei2c(1, c ); // Send ASCII c command to BlinkM ss_restarti2c(1, c ); // Generate I2C restart condition ss_startreadi2c(1, 0x09); // Start read to BlinkM (Address 0x09) char str[3]; Figure 3 Example API Code Listing // Create array of 3 chars Figure 3 Shows an example use of the API to accomplish the task of reading the RGB color from a BlinkM. If the API was not used, more code would be needed. Also this code listing includes the use of two of the more useful higher-level I 2 C functions, ss_startwritei2c and ss_startreadi2c. They are useful because they set the read/write bit automatically. This saves the programmer from doing an error-prone calculation before sending the byte out on the I 2 C bus. The byte consists of the concatenation of the 7-bit address and the read/write bit. So to start a read to address 0x09 it is necessary to shift 0x09 to the left one bit and add 1 (indicating a read), which results in the value 0x13. Similarly a write would be sending the value 0x12 onto the bus, since the read/write bit is set to 0. CONCLUSION A CubeSat payload interface was described in this paper. It is not yet complete, but it is ready to be used and improved under an actual CubeSat satellite project. The main intention of the payload interface is to simplify the process of integrating a satellite with a payload. The payload interface and API certainly help with this, thus helping to ensure the successful operation of the payload and satellite. ACKNOWLEDGEMENTS I would like to thank NASA and the Hawaii Space Grant Consortium for supporting my research and providing me with this great opportunity to experience engineering directly. I would also like to thank Dr. Shiroma and the Small Satellite Laboratory for providing the facilities for my work and invaluable guidance. REFERENCES ˡBrandon G., James G., Eric M., Gabe T. (2007) Team DANDE Preliminary Review Presentation. University of Colorodo at Boulder ²ThingM Labs (2009) blinkm datasheet v ThingM <

7