Initial Design:

Initially we had hoped to implement a scripting language that could run on the Mega128. The idea was to make the board programmable so that it could be configured to run basic commands to measure any voltage/current on any board that the CubeSat project uses. The scripting language would have to be very small in order to fit on the Mega128 without any external memory. Ideally, this language could even run while the satellite was in operation. It could provide real-time diagnostic information of the satellite’s status while it is in orbit. It could report this data to the command and data handling board on the satellite so it could potentially respond to errors or report the data back to the ground, or both.

Obviously, we would not write the entire interface with the satellite because it would not be feasible. But, the scripting language should be very adaptable so that future users could augment it to give it the above functionality.

Software Tradeoffs:

Once we realized how much effort that would require and taking into account the amount of time we needed to spend getting the PCB to work, we adopted a more pared down strategy. The diagnostic board is intended to make debug of future CubeSat and CUSat boards much simpler and quicker. In the past, teams have gone through several boards, shorting them out or otherwise rendering them inoperable while trying to diagnose a problem. The diagnostics board is supposed to provide a safer and easier alternative. Version 1 of the board is mostly a hardware design with the software added to make sure that hardware is operating correctly and can respond to the variety of inputs that could occur while the satellite is in operation.

We ended up implementing a testing suite tailored to a particular board, the CubeSat power board, with a user interface through the serial port. This test setup is capable of measuring all of the relevant voltages and currents on the power board by simulating the loads that the power board would be driving were it hooked up in the satellite. The user menu is a straightforward prompt/response system where the system waits for the user to specify what he wants to measure and then carries out the measurement. There is also a timeout feature, where if the board is turned on for 30 seconds, waiting for user input, it will start executing a default program which basically cycles through the various operations that it can perform. The board has an LCD on it, so the results of the measurements are displayed there. This setting allows the board to be used without a computer in the event that one is not available. We also included status led’s to indicate to the user the state of board, what it is measuring (current or voltage) and whether the value is outside of the expected range.

Most of the code deals with setting up the hardware (multiplexer select lines, sourcing voltage to the power board, etc.) and then using one of the 8 ADCs on the Mega128. Using some current sensors each ADC is either measuring current or voltage. The values coming out of the circuit are then scaled to their actual values based upon the transfer functions of the circuits that they are connected to.

Testing Algorithms:

The code is broken down into a few main components: the menu, test_ckt, run_mux8, run_mux2, and run_coils.

The main menu loads on startup and prompts the user to select the type of measurement they want to make. It then steps through all the options associated with the measurement and sets up variables to perform that particular test. Once the user has finished entering data, the menu exits and test_ckt is loaded.

The menu and all user i/o is designed to be very readable and easy to understand. We included descriptions of the tests as they are running so that even users unfamiliar with the system could quickly learn how to use it to suit their purposes.

Test_ckt is a carrier for all the other tests the board performs. Based upon the user input it sets up and calls subroutines to return the expected data.

Run_mux8 performs all the measurements associated with the dual 8:1mux circuit included on the board. The operation of this circuit is detailed in the hardware section, but basically it chooses voltages from the power board, measures them, and then selects a load to simulate actual operation of the power board and measures the current that the voltage sources. This is accomplished by setting select lines on both multiplexers corresponding to the desired output. The ADC is then selected and read. The data is reported back to the user for inspection.

Run_mux2 performs a test on the flight-pin/kill switch setup on the power board. Basically, this is a set of select lines that determines what mode of operation the power board should be in. Run_mux2 cycles through all the possibilities of select combinations and checks the state of the power board. Run_mux2 uses run_mux8 to check voltage levels on the board to determine the “state of the power board.”

Run_coils simulates the torque coils included in the actual satellite. There are 3 of them so the code lets the user specify which one to test and which direction to test it in. Each coil can have its voltage measured or the current measured. The coils have to be carefully operated. If they are run in both directions simultaneously then they will fail so it is important to make sure that the power board turns on in one direction and only one direction at a time.

There is also a default program which runs if prompted by the user or if there is a time out while waiting at the main menu. The default program allows the diagnostic board to relay data to the user without the use of a computer terminal. The default program executes the most important tests the diagnostic board can perform in a predetermined sequence. It waits briefly between each test so that the user can read the data off the LCD and then proceeds.

Testing Considerations:

In order to make the code manageable, and easily editable, enums are extensively used. All of the diagnostic board combinations are enumerated so that switch/case statements can be used with actual descriptors of the function being executed. In order to add more functions to the board, one merely has to add enumerations and update the switch statements with the proper setup.

The code is also extensively commented so that future users can understand the design methodology behind the code.

Additional Code:

This project also implements drivers for dual serial port operation and LCD operation. Two serial ports are necessary because the diagnostic board communicates with the user through serial communication and it can also send and receive data from the power board MCU. Currently, the send/receive functionality is limited, but it is proof that the concept works. In the future, it should be possible for robust interaction between the diagnostic board and the power board.

The serial connection to the PC is non-blocking so we don’t have to worry about it interfering with more important operations. The connection to the power board is blocking because we want to wait for a response from the power board MCU.

We are using a 4 digit, 7-segment LCD display, with a hardware driver. The driver for it was written by us, specifically for our project.  We were going to use some 7-segment LED’s to display data on the board because we had them available already in lab (free), but they required too many port pins and were somewhat difficult to read. In the end, everything worked out.