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.
- 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.
- We were able to carry out
voltage and current measurements on various voltage/load
combinations.
- We were able to measure
currents and voltages while running simulated torque
coils in both directions.
- We were able to simulate the
startup of the power board using its flight pin/kill
switch interface.
- 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.
- 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.
- 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.
- 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.
- 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.
|