Design expectations & actual results

Our final board design actually met many of out initial expectations. We were very happy to have actually pulled off the design, layout, population, programming and testing of a microcontroller-based PCB. We put so many hours into the design and debug of this board and it actually paid off, though not completely.
 

1. We were able to design a PCB that supported an Atmel Mega128, serial port communication, an LCD, and which also had programming capabilities through CodeVision.
2. We were able to carry out voltage and current measurements on various voltage/load combinations.
3. We were able to measure currents and voltages while running simulated torque coils in both directions.
4. We were able to simulate the startup of the power board using its flight pin/kill switch interface.
5. We were able to send and receive primitive serial commands/responses between our board and the power board.

However, we did not meet all of our initial design goals. Given more time/another revision of the diagnostic board, we feel that we could correct these problems relatively easily.
 

1. We did not successfully integrate the power board and the diagnostic board as we intended. This is a result of not being able to safely supply the twelve volts that the power board requires through our multiplexers.
2. We are not able to measure the full current/voltage ranges that the power board is capable of producing. This is again a result of our multiplexers only being able to apply 5 V to bias the gates of the MOS transistors functioning as switches.
3. We did not achieve error-free operation. When the power switch is turned on, our board sometimes goes into a strange state where it scrolls the main menu over and over again. Upon a soft-reset, the problem goes away. We have been unable to diagnose/fix this problem.
4. Also, we had hoped to have time to implement a more robust scripting language as a testing interface for our diagnostic board. This feature would have made the board easily applicable to a variety of situations. However, due to the sheer volume of work this would have entailed in addition to the PCB debug, we had to cut this feature out of our final design.

Overall, this was a good version 1 of the diagnostics board. It serves its purpose as a proof of concept and in debugging it we actually found solutions to some of the problems with it so that future revisions will be more functional.

Next time, we would start work on the designing the circuits used on the board well before the final project began. Basically, if you plan on making a PCB, it is generally not a good idea to do it in 4 weeks and expect to have a social life.

Standards, Ethics & Intellectual Property

This project takes advantage of no known standards besides RS232 serial communications. The diagnostic board and the power board it diagnoses were both custom designed by Cornell students and as such there are no real intellectual property issues. However, we would like to thank Embedded C Programming and the Atmel AVR by Barnett, Cox & O’Cull for some inspiration with the serial driver.

We don’t know of any patent opportunities for our project. Most of the circuits and code we designed were relatively straightforward implementations. Also, because our board has such a specific application at the moment it probably wouldn’t be of great interest outside of the CUSat team.

The IEEE code of ethics mandates that electrical engineers should “accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public.” We believe that our use of a circuit breaker on the board in the event of shorts and the fact that our board allows hands-free testing all improve the safety of power board diagnostics.

The code also states that an engineer should “be honest and realistic in stating claims or estimates. We believe that we have fully disclosed the faults of our board and have made no unrealistic claims about its operation.

This process has also improved “our technical competence” as engineers. The PCB design knowledge, soldering skills, and general debugging knowledge that we gained as a result of this project have been invaluable.

We also believe that we have accepted “honest criticism of technical work” and made an effort to correct those errors. We have probably been our harshest critics, but the other members of the CubeSat team also gave us good feedback.

Lastly, we have “assist[ed] colleagues and co-workers in their professional development” by designing a board that our fellow CubeSat/CUSat team members can use and benefit from in the future.