Senior Design 2 Documentation - University of Central Florida
UNIVERSITY OF CENTRAL FLORIDA - COLLEGE OF SCIENCES
COLLIDE-3: AVionics
Module
Group 2
Members
Mohammad Amori
Walter Castellon
Joshqua Steele
Tri Tran
Sponsor:
Dr. Josh Colwell
- 0 -
Contents
1.0 Executive Summary
Dr. Colwell, a planetary researcher at UCF, has been running the COLLIDE
(COLLisions Into Dust Experiment) experiments for over a decade. The most recent iteration of the experiment is COLLIDE-3, which was originally designed to fly aboard a rocket (called New Shepard) provided by Blue Origin, an emerging sub-orbital rocket flight company. At the time, the experiment consisted of two major elements:
1. The CPB, which housed the actual COLLIDE-3 vacuum chamber, camera recording equipment, and electrical components
2. The AVM, which was the “brain” of the experiment, transferring power to the various components within the CPB and storing the video coming out of the camera within the CPB.
Blue Origin supplied everything for the experiment that wasn’t COLLIDE-3 itself; they provided the CPB box itself, the camera, the feed through wires and connectors for the CPB, and of course the entirety of the AVM. All of the aforementioned were loaned to Dr. Colwell’s lab so that his engineers could design COLLIDE3 around working with Blue Origin’s hardware. Unfortunately, on the final test run, New Shepard experienced critical failure and was lost.
While COLLIDE-3, the CPB and the AVM were all not aboard New Shepard during the failure, everything on loan from Blue Origin was only allowed to be used if COLLIDE-3 flew on one of their rockets. Since their only rocket was New
Shepard, and that was now out of commission for quite some time, the only way to ever get actual data out of the COLLIDE-3 module was to re-create the elements of the experiment that belonged to Blue Origin, allowing Dr. Colwell to fly aboard any suborbital rocket that had room for his experiment.
Thus, the inspiration to create an AVM of our own came about. The CPB is almost literally just a housing unit with nothing electrical about it, so there was no reason to consider working on it for our project. The AVM, however, promised to be full of unique challenges that would prove to not only be an interesting senior design project, but would also have the added benefit of being used in the future to generate actual scientific data, something not many senior design projects can boast.
- 1 -
1.1 Background of COLLIDE-3
To understand what we are trying to achieve through the implementation of our
AVM, and to comprehend the vocabulary that will be used regularly throughout this paper, it is important to have a firm grasp of the experiment that our AVM is being designed around to control. However, before we get into that, it is equally important to know the scientific reason behind COLLIDE-3 existing in the first place.
1.2 The Science
Dr. Colwell is a planetary researcher in the Physics Department at UCF. One of his labs focuses on low-velocity particle collisions in microgravity environments.
The formation of a planet occurs in multiple stages. First, dust particles come together to form planetesimals. Once planetesimals grow enough in size, they are considered protoplanets. Finally, a protoplanet can become large enough to be considered a planet. Much is known about planet formation once it reaches the planetesimal stage, since from that stage on the body is large enough to attract particles through its own gravitational force.
However, before this stage, it’s unclear how enough particles come together to develop into something with its own gravitational force. This is where Dr. Cowell’s research comes in. Through observing collisions of tiny dust particles in a spacelike environment (vacuum chamber, microgravity) we can actually see the types of reactions that are likely to lead to planetesimal formation. Dr. Colwell specializes in low velocity impacts, specifically in ranges around 20cm/second.
Not only is a microgravity environment essential for reasons of watching the collision occur without gravity moving the particles, but the presence of gravity makes creating a collision at 20cm/second virtually impossible. What we hope to see in these collisions is particles starting to stick together.
1.3 The Experiment
COLLIDE-3 houses all of the necessary functions for a controlled collision experiment. Shown in Figure 1 are two of the main components of COLLIDE-3; the IBS module, which is where the actual collision occurs, and the vacuum chamber, in which the IBS module resides inside. The vacuum chamber is pumped down through the connection circled in yellow in Figure 1.3.1. A gauge
(orange circle) connects to the same place so that the level of vacuum on the inside can be read. Once a vacuum is achieved, COLLIDE-3 is loaded onto a suborbital rocket. A suborbital rocket is just that; it flies up into the area above
Earth’s atmosphere, outside the pull of Earth’s gravitational forces. Through not having to leave the actual orbit of the Earth, the rocket can be made much
- 2 -
simpler and cheaper than those designed to leave orbit, while being able to achieve the same environment for scientific experiments.
Figure 1.3.1-COLLIDE-3 IBS and Vacuum Chamber
The electrical connections circled on the left feed through the box, coming out on the red circle on the right.
Once the rocket reaches its peak altitude and has achieved a microgravity state,
COLLIDE-3 runs its experiment. First, the lights (blue, Figure 1.3.2) activate, allowing the now-recording camera looking in through the viewport (purple,
Figure 1) to witness the contents of the vacuum box. The microstep driver
(yellow, Figure 1.3.2) activates, running the stepper motor (purple, Figure 1.3.2) and moving the door down the track on the IBS (green, Figure 1.3.1). This door reveals a payload of dust particles to be collided into. Shortly after the door opens, a current is passed through the muscle wire (red, Figure 1.3.2), which activates the launcher located between the LEDs in Figure 1.3.2. The launcher propels a quartz marble into the dust payload basin, all of which is recorded.
After 30 seconds, the door is closed, the lights turn off, and the camera stops recording.
Figure 1.3.2-(Left) Electrical inside of IBS (Right) Microstep driver connected to stepper motor
- 3 -
Not shown is the CPB in which the vacuum box, camera, and circuit board is housed in. This is because the CPB is property of Blue Origin, and we are under a Non-Disclosure Agreeme nt which prevents us from picturing it anywhere. It’s a fairly straightforward box though, simply providing threaded holes to mount our boxes and room for electrical feedthroughs. The DC to DC converters shown in
Figure 1.3.3 are for regulating the voltage sent into the IBS module. Blue Origin’s
AVM, and the one we are replacing it with, only provided 28V DC. The lights and power of the microstep driver require 12V DC, while the PWM of the microstep driver and the muscle wire require 6V DC. The middle chip in Figure 1.3.3 is the
28-12 converter, with the two chips flanking it acting as 28-6 converters.
Figure 1.3.3-DC to DC converters for IBS components
2.0 Accelerometer
2.1 Introduction and functions
One of the most important factors of our COLLission Into Dust Experiment-3
AVionics Module project is the accelerometer. In our project, the accelerometer is the component that essentially starts everything else that needs to start. Without the accelerometer, the Collide 3 AVM would not do anything at all because it would not detect any micro gravity. Hence, it is one of the most important components that we need to have working correctly and efficiently for the rest of the project to go accordingly to our experiment.
In order for us to start the mission, we need our accelerometer to sense that it is in mid air or in micro gravity which will simulates the same condition as out of space. The accelerometer will be used to start up many other components like the LED lights, muscle wires, the microcontroller or the FPGA board (we have not decided to use which one yet because we are still researching to see which one is the better fit for our project), solid state hard drives, and the camera. Thus, the accelerometer is very important to our project and should be researched and implemented correctly.
- 4 -
Our project is designed to simulate how the universe was created by putting the
Collide 3 AVM into space to conduct our experiment with a spherical object and dust particles. We obviously are not able to do this. We can not demonstrate it because we can not do it in spaces. For our senior design project, we will be simulating the micro gravity in space by using a drop tower. This drop tower is provided for us by Dr. Josh Colwell which is our sponsor. We will be using his lab to conduct our experiment which will sense micro gravity instead of the conventional space beyond our earth. The drop tower is basically a structure that is about ten to twelve feet tall and made out of PCP pipes and other metal materials. The drop tower also has soft cushions at the bottom to hold the object so it would not break our project when it hits the bottom. We will be lifting our project up to the top of the tower and then we will drop it. Once our project is being dropped in mid air, the accelerometer will detect the micro gravity in that very instance.
Once our accelerometer sense micro gravity from the free fall with the help of the drop tower, it will basically flag a switch which states that it is in space or free fall.
Most likely we will have to test it out in the drop tower first to make sure the accelerometer actually senses the micro gravity and activates the switch to flag it on. We will probably keep the micro gravity flag on for the rest of our project because we might not be able to present it in the lab. Thus, our presentation will probably start with a switch that turns the accelerometer on. Of course, we will have some kind of documentations that shows that the accelerometer actually working either on paper or video.
When the accelerometer sense micro gravity, it will initially turn on the LED lights which will provide the Collide 3 AVM with visibility in space. After that, it will initiate the muscle wire by letting current go through it. The muscle wires will squeeze the hinge which will open the door to release the bigger spherical object. It will also open the doors to release some dust particles. The dust particles will most likely orbit around the bigger object. Here is when the camera shines. The camera will start to take pictures and it will store these images onto the solid state hard drive or drives, we have not decided how many solid state hard drives will be implemented into our project. Essentially, everything will proceed after the accelerometer detects micro gravity.
The reason we are using an accelerometer for our project is because we need a device that measures active acceleration which is the force due to the gravity of the Earth. We can experience this force during freefall. An accelerometer in a gravitational freefall will measure its force to be zero because its reference to the earth is weightless during this timeframe. Even though the speed is increasing with every second during the fall, there is no normal force to push back which is used to determine the weight. With no weight on the accelerometer, it is essentially weightless. This is the reason why we will be using the accelerometer to simulate micro gravity in out of space.
There are lots of different types of accelerometers out there. The Collide 3 AVM is suppose to go into space as well, thus it might be better to explore our options
- 5 -
of accelerometers by getting a more advance one. Some of them even sense the direction and the magnitude of the accelerations in vector and quantity respectively. The advance accelerometer models with these features can be used to detect vibration and shock during the flight. The Collide 3 AVM does not care of the orientation of itself nor does it care about the angles it is in compared to the Earth. Even though those features are not important, most accelerometer are able to sense them anyways, but we did not use it.
We only need it to sense micro gravity and handle the shock and vibration while it is on its way into space. Most accelerometers are small and is able to handle vibration. This is essential to our project because if it is big and bulky, then the vibration from the flight might shake it and make it not function correctly. The smaller the accelerometer is, the more secure and safe it can be integrated into our Collide 3 AVM. Thus, we tried to find a small size and dimension accelerometer in figure 2.1.1.
Figure 2.1.1. This picture shows what an accelerometer should look like and its real life scale compared to a quarter. This accelerometer provides digital PWM or Analog output. This picture is provided by Zagrosrobotics.com
As mentioned above, our project only demonstrats the process after the accelerometer activates the on switch from the existence of micro gravity. It should also be able to handle vibration and shock. Our sponsor wants this because the Collide 3 AVM will have to endure to flight. Our accelerometer should have some kind of sensor or mechanism that should output a zero flag once it detects micro gravity. Also, it should be low powered consumption because it will be running on battery. We researched what accelerometers are and what the different types are. Then we determined what type we need.
Thereafter, we narrowed our selection down to three to choose from. After we have our three main accelerometers, we compared and saw which one was the best choice.
- 6 -
2.2 Research
Accelerometers are known to be electromechanical devices and are used for many different applications. An accelerometer acts as a mass on a spring.
Whenever it experience acceleration of any kind, that mass will moves so that the spring will accommodate it’s acceleration to the same rate as the housing of the component. This movement is measured as displacement, calculated, and is formed into integer as a quantity for the acceleration of the whole ordeal. You can say it is an inertial sensor used to measure the acceleration. This can be obtained by deducting the gravitational acceleration (g) from the movement acceleration (a) along the direction of the axis its going in. we use the following formula to explain this process: A= a-g. Therefore, a three axis accelerometer will indicate zero for all three of its axis. It senses this simultaneously during the free fall. This will only happen during a free fall. This process can be simply demonstrated by the picture below in figure 2.2.1.
Figure 2.2.1 This is not an accelerometer, it is just a demonstration of how the accelerometer is structured to calculate and determine its value. This picture is provided by Education.com in the
Acceleration Help section.
For this theoretical situation, the indicated output values of the three axes will all show zero simultaneously. With this characteristic, we can say that the accelerometer is in the condition of free fall. In the state of free fall, it means that there is no external force except for gravity. During this free fall, there is only air resistance. Thus, no external force acts upon it to create any kind of stir inside the accelerometer.
In most common devices, there are several different technology types which consist of capacitive, piezo-electric, and piezo-resistive accelerometers. These different types are used to convert mechanical motion into measurable electrical signals. The designs of these accelerometers are also abundant. Some examples of their design are flexural, inverted compression, single ended
- 7 -
compression, isolated compression, and shear type design. Also, there are many grades of accelerometers.
The types of accelerometer are important to know what is needed and what we do not need. Obviously, the more it cost the better it is, but we do not need it to do everything. The high vibration accelerometer design is made to stand high vibration levels which are used in heavy machining tools, vibrations labs, and many other high vibration applications. This is good in our designed project because it will be able to withstand the initial launch and flight into space. There are many other types such as premium grade, triaxial, and industrial grade.
The premium grades are made from top rated crystals and are secure from the environment with stainless steel housing. They produce top quality and low noise using low noise circuits for their accelerometers. The industrial grade accelerometers are most common and are used in regular shops that do not need high attention for their job. These accelerometers are also protected against all sorts of weather and rough environments. The next one is the triaxial accelerometer. These use the x, y, and z coordination plane with three separate crystals to give three signals respectively to each of the three coordinates. After researching these different types of accelerometer to decide which one is needed, we definitely do not need to spend more than we have to for some of these accelerometers because we do have a budget we have to go with. But we did keep a good eye on them and kept them up for consideration. It is always good to have our options open.
Accelerometers have different important specifications that can be compared.
The accelerometer’s sensitivity, its bandwidth, if it’s analog or digital, it’s and buffering ability are things to consider for picking the right accelerometer for your project. The accelerometer’s sensitivity is the measurement of ‘g’ force which produces an output voltage. The accelerometer’s bandwidth is the total number of times a reading is being recorded per second. Obviously we want the most sensitive accelerometer and high rate bandwidth so it can detect micro gravity at the instant it happens and activates quickly. Our drop tower is only about ten to twelve feet tall, thus the drop will be really quick and short. So it needs to detect micro gravity as quickly as possible.
In order to pick between analog accelerometer and/or digital accelerometer depends on which microcontroller or FPGA board we will be using to make a better choice. We ended up using a microcontroller. Digital accelerometer uses square waves of frequency like we have seen before in our digital system class and lab. The acceleration was measured by the number of times the voltage is in its high state. All of these accelerometers we researched was used to interface with our microcontrollers.
For analog accelerometers, the output is dependent on the continuous voltage.
Some accelerometer delivers both output in digital or analog. Everything being researched should be incorporated into which accelerometer we used and its structure as shown in figure 2.2.2. Whether the output be analog or digital, we
- 8 -
have a converter for our microcontroller when it is needed. Thus, we researched on converters to help with the accelerometer.
Figure 2.2.2 This picture is a basic structure of an accelerometer labeled with its important components provided by Dliengineering.com
2.3 Narrow down to 3 Accelerometers
We researched a couple of accelerometer that we could use for our project. At first we did not think that we need to get the higher grade accelerometer because of price, but with this being in space with technically no axis. We basically decide on getting the 3-Axis accelerometer modules as appose to 2-Axis. The 3-Axis accelerometer gives us more sense of direction, thus it will be more sensitive to detect any kind of acceleration for micro gravity or none at all when it is in space.
The most important factor of the accelerometer is to accurately sense micro gravity or in other words ‘zero gravity’. We research lots of accelerometer but we have narrowed it down to three to chose from.
MMA7361 3-Axis Accelerometer Module
MMA7260QT 3-Axis Accelerometer Module
Hitachi H48C Tri(3)-Axis Accelerometer Module
The first accelerometer that has all of the features we need for our Collide 3 AVM project is the MMA7361 3 Axis Accelerometer Module from Freescale
Semiconductor. This one can be bought for the amount of ten dollars and ninety five cent on ‘modern device’ website. We search many accelerometers with the features that we wanted. The most important feature is the ability to detect micro gravity and sends and output so that the rest of our project may continue its process. All in all, the accelerometer has to be small, vibration resistance, and low power consumption.
This accelerometer meets our requirements. Thus, we picked it as one of the accelerometers to do more research and compare. This MMA7361 3 Axis
Accelerometer Module operates in two simple selectable sensitivity modes. It has
- 9 -
a +/- 1.5g mode for more sensitivity activities and it also have a +/- 6g mode for applications that you do not want anything to change with a slight tap. The default will be +/- 1.5g mode which is 800 mV/g @ 1.5g but you could change it to the other mode which is 206 mV/g @ 6g by simply selecting 0 or 1. 0 is defaulted to the +/- 1.5g mode while 1 is changed to the +/- 6g mode. This feature will be very useful if one mode does not work. We would just have to change it to the more sensitive mode.
Another awesome feature of this accelerometer is its sleep mode. The normal current operates at 400 micro amperes. Once it is in its sleep mode, the output turns off and this significantly reduce the operation of current being used. The current is reduced down to 3 micro amperes. This can and is useful due to it being powered by a battery to conserve as much as possible. This will save power till the battery is being needed.
The most important feature of this accelerometer is the 0g detection feature. This feature is important because it is exactly what we need for our Collide 3 AVM senior design project. That is the main functionality that we need for our project.
This feature will provide a logic high signal when all three of the axes are all measured at 0g. This feature signal is connected to an interrupt pin or a poled I/O pins on the microcontroller. This accelerometer module has the technical data sheet which includes the functional block diagram, the pin connections layouts, dimensions of it, and spec information. This is just the first accelerometer we found that is suitable and has all the necessary features for our senior design project. Table 2.3.1 below shows the description for the MMA7361 3-Axis
Accelerometer.
Rating
Maximum Acceleration (all axis)
Supply Voltage
Symbol g
V max
DD
Value
±5000
–0.3 to +3.6
Unit g
V
Drop Test
Storage Temperature Range
D
T drop stg
1.8
–40 to +125 m
°C
Table 2.3.1 above shows the maximum acceleration for all 3 axis, the supply voltage, meters for drop test (important for our drop tower), and temperature of the accelerometer for space simulation.
Secondly, an accelerometer that has all the features we need for our Collide 3
AVM project is the 3-Axis Accelerometer with the MMA7260QT module. This accelerometer is from Freescale Semiconductor and it is manufactured by
Liquidware with Modern Device. This accelerometer can be purchase for
- 10 -
nineteen dollars and ninety five cents from Jameco Electronics website. It is a low cost capacitive micromachined accelerometer.
The main reason why we scaled down our research and picked this accelerometer is because of its Zero-g offset full scale span feature. Our project requires a micro gravity detection option, thus we pick this one to do more research and consideration on. This accelerometer also has more than one sensitivity modes. The first accelerometer has two options of sensitivity mode, while this one operates in four different selectable sensitivity modes. The four selectable modes are +/- 1.5g, +/- 2g, +/- 4g, and +/- 6g. With these four sensitivity modes, we can adjust it to what we need our accelerometer to be. If one mode is not sensitive enough for our freefall drop test, we can try the other three modes. The more options we have, the better we can test our Collide 3
AVM in micro gravity and freefall test.
This accelerometer also has a sleep mode which helps our battery powered senior project. It consumes the same amount of current in sleep mode as the first accelerometer we chose, which is 3 micro amperes. On the other hand, in regular operated power mode, its current consumption is much higher than the first accelerometer we chose. It consumes about 500 micro amperes for regular mode. This accelerometer is still low power consumption, but it consumes more current than the first one.
Additionally, this accelerometer also has a temperature compensation feature which can be useful for the purpose of our project during flight then in space.
Some typical applications for this accelerometer are that it works for laptop pc’s and HDD mp3 player. Its purpose for these applications is for freefall detection and has many uses for many other applications which does not relate to our project. Thus, they were not discussed.
To complete the total package, it has a pdf data sheet which has pin connections, pin descriptions, PCB Layout for interfacing accelerometer to microcontroller, block diagrams, dimensions, and spec table. One thing this one has that the first one does not have are sample codes which can help us have a better understanding how to code it. Of course we have to write our own code which will fit our ports and pins for our microcontroller, but any example is a big help for a better understanding.
There is also a sample helicopter projects which we looked at to help us get a better feel of what we need to do. This accelerometer has lots of information and examples. It also has a maximum rating table which scores the same as the first one as well so we did not include the table. All in all, this accelerometer has more feature than the first accelerometer does but it does have its downside, such as more power consumption.
- 11 -
Characteristic
Operating Range
Supply Voltage
Supply Current
Supply Current at
Sleep Mode
Operating
Temperature Range
Acceleration Range,
X-Axis,Y-Axis,Z-Axis
Symbol Min Typical Max Unit Sensitivity
V
DD
I
I
DD
DD
2.2
-
-
3.3
500
3.0
3.6 V
800 µA
10 µA
-
-
-
T
A
-40 - +105
°C
-
g-Select1 & 2: 0 0 g
FS
g-Select1 & 2: 1 0 g
FS
-
-
+/-1.5
+/-2.0
-
- g 800 mV/g g 600 mV/g
g-Select1 & 2: 0 1
g-Select1 & 2: 1 1 g
FS g
FS
-
-
+/-4.0
+/-6.0
-
- g 300 mV/g g 200 mV/g
Table 2.3.2 shows the specs we needed to know for the 3-Axis Accelerometer MMA7260QT. It shows the voltage range, current range, current at sleep mode range, temperature range, and the four selective sensitivity ranges with its sensitivity magnitude.
Last but not the least, the accelerometer that has all the features we need for our
Collide 3 AVM project is the Hitachi H48C Tri (3)-Axis Accelerometer Module shown in figure 2.3.1. This accelerometer module is produced by Hitachi Metal. It can be purchased at ‘Parallax’ for twenty four dollars and ninety nine cents. We were happy to find this accelerometer because it had a lot of information and contents with it and that should help us with our project greatly.
Unfortunately, they do not sell this single component one at a time anymore. This accelerometer module can only be bought in a package deal which will include other components that could also be helpful to our Collide 3 AVM project. This package deal does cost a little more than it is to buy the accelerometer by itself.
It probably cost more because of all the other components included in the package. But in order to get this accelerometer to work with, we would need to buy the whole package. Good thing we are sponsored by Dr. Colwell, thus we can spend a little more.
- 12 -
Figure 2.3.1 This is the actual picture of the Hitachi H48C Tri-Axis Accelerometer Module next to a quarter. It is 17.8mm x 20.3mm in size.
Even though it was only sold in a package deal and not by itself, we still consider this accelerometer because it has a lot of contents that we can go from to help us learn more about it. Also, it is breadboard friendly for us to test. Another reason why we still consider this highly reliable accelerometer is because of its ceramic package and the air-tight seal. Our project should be able to handle flight and space, so this feature is a plus for us. And of course, we included this accelerometer to our narr ow selection is because of its “free-fall” output which indicates simultaneous 0g on all axis.
This accelerometer also has a very low powered consumption feature. It’s STBY
(standby) mode operates are only 1 micro ampere. This accelerometer
STBY/SLEEP mode beats out the other two by one third. It is high shock durable which is also relevant to our project because of the flight into space. One thing that this accelerometer does not have that the other two have is different sensitivity mode. The Hitachi H48C Tri-Axis Accelerometer Module only have one mode which measures +/- 3g on any axis.
Like the other two accelerometers, this one also has the data sheet which contains most of the component’s information needed to help us make a decision. It includes data such as the connection pins and descriptions, functional block diagrams, dimensions, and general spec sheet. This is the third accelerometer that we chose to research more in dept on because it has great features that fulfill our requirements.
2.4 Comparison and Chosen Accelerometer
We pick these three accelerometers above because they met the functionality that is needed for our Collide 3 AVM project. One first two have sensitivity modes which can be helpful for our project to determine micro gravity. The third one did not have the different sensitivity modes but +/- 3g might be sufficient. Thus, the first two wins in that category. The first one did not have much information and examples we can go with compare to the second and third. The third
- 13 -
accelerometer actually had the most information and example we can look at so the Hitachi H48C won that. As far as power consumption goes, the obvious winner here is also the Hitachi H48C with standby consuming only 1 micro ampere while the other two consumes 3 micro amperes. This gives us more power to use when needed.
All three accelerometers have a 0g detection feature so that is a no contest. They also all have block diagrams, dimensions, pin connections and description. After comparing all three of the accelerometers that we narrow down, we had a discussion to choose the accelerometer we are going to be using. Our discussion was short and the obvious winner that we should choose is the Hitachi H48C.
Even though it did not have different modes for sensitivities, we figured +/- 3g is good enough to determine micro gravity during the free fall experiment we are going to do in the lab. The Hitachi H48C is our choice.
The Hitachi H48C 3-Axis Accelerometer that we choose is an integrated module that can sense gravitational force for all three X, Y, and Z axis. It can sense up to
+/- 3g on those three axes. This module has an onboard regulator which provides
3.3 volt power to the H48C. It also contains an MCP3204 analog to digital converter to read the H48C output voltages and it also has analog signal conditioning. This accelerometer uses MEMS (Micro Electro Mechanical System) technology. These are the pin layouts that was being considerated as shown in figure 2.4.1.
Pin layouts
Figure 2.4.1 Shows the pin layout of the Hitachi H48C
The Zero Gravity detection system built into our chosen Hitachi H48C 3-Axis
Accelerometer is the most important feature. Aside from the other features on this accelerometer, without this feature, we would not have picked it at all.
Hence, it’s the most important feature that we are looking for. The Zero Gravity detector compares the absolute value of the acceleration outputted from the three axes with threshold Gt. During a free fall event is occurring, the absolute
- 14 -
value of the acceleration should become smaller than the threshold Gt for all three of the axis.
Description Table
Pin Label Definition
1 CLK Synchronous clock input
2
3
DIO
Vss
Bi-directional data to and from the host
Power supply ground which is 0v
“Free-fall” detection output; active-high
4
5
Zero-G
CS\ Chip select input; active-low
6 Vdd +5 vdc
Table 2.4.1 Is the essential connections layout, pin, labels, and a little description that we need to know for the H48C module. As you can see, the Zero-G output pin is pin 4. That is the pin we will be using to detect micro gravity or free fall.
After the acceleration becomes smaller than the threshold on all three axes happens, the detector judges the state is Zero Gravity and the ZeroG flag is outputted. That is exactly what we want to happen. The ZeroG flag is on pin 4 of the accelerometer. It is always comparing the two forces. The comparison happens repeatedly around every 0.4milli seconds. Once the comparison does not satisfy the rule (a<G), then the ZeroG flag will disappear and not be outputted anymore. The standard specification of the Gt is about 0.4g. This is what we were talking about earlier in the introduction about the Zero flag shown in figure
2.4.2. Since we have to demonstrate this without a drop tower, we might have to set the Zero flag on. The picture below explains this phenomenal process in a block diagram of the H48C ZeroG detector of the H48C.
Figure 2.4.2 The block diagram for the H48C for the zero gravity detector
- 15 -
2.5 Software side
The hardware and spec/data sheets are fun and all but it does not help us with the coding part. Nothing will work without some kind of software application. With this accelerometer, we had some basic samples of projects and codes that was relevant for us to use as a guide. What we noticed is that it depends on which microcontroller we choose. A simple code to determine the Gf can be as follows.
IF (axCount >= rvCount) THEN This gives positive g-force
gForce = ( axCount – rvCount ) ** GfCnv
ELSE This gives negative g-force
gForce = - ( ( rvCount – axCount ) ** GfCnv )
ENDIF
The code above shows a sample of a code segment that measures the G-force by the accelerometer. The accelerometer gets the integer for axCount and rvCount then calculates the answer for the G-force.
There are many different types of software applications wer can code in for our senior design project. It all depends on which type of microcontroller. The sample on their website uses BASIC Stamp 2 module as a host controller. While with some research, we found other programs like Arduino and we can also use java and C to actually program our accelerometer. Most microcontrollers have their own drivers and applications that they use. In those cases, we use those coding application to also control our accelerometer. As far as errors that happens during our coding process. We are familiar with debugging with the classes we have taken. Taking coding classes like C, Java, CS1, and CS2 gave us experience with errors and problems.
3.0 Power Source
The power source is another important aspect of our Collide 3 AVM project.
Almost every senior design projects’ most important component is the power supply or some kind of battery. We had to find out a way to efficiently use our power supply and deliver it to each of our components accurately and successfully. There are many different components in the circuit that needs to be powered. Each component had a different voltage or current being carried to it.
Thus, it was very important for us to know each of the components inside out to know how much power each needs. This power supply has to last long enough to power the accelerometer, the microcontroller, LED lights, take pictures with the camera, store data and run the solid state hard drives, and give enough current to the muscle wires to open the hinges. We have to find a good battery source and a converter that can distribute the power to each component as needed to
- 16 -
make sure everything will be fully functional. It should be able to last the time length of the simulation as well.
Researching the power source took longer than expected. Thinking that any power supply would do, we were wrong. There are so many different types of power source and what they are good at. This power supply we pick should be able to last for at least a good minute to make sure that we got enough pictures to see the movement of any dust particles. It should also operate correctly no matter what environment and weather it is in because it will be going through a flight into space. There are lots of choice of battery and power source out there such as Alkaline Batteries, Lithium-ion, Nickel-metal hydride, and Nickelcadmium. There are probably other types of batteries out there we can research on but these are the ones that would work most efficiently for our project. After our research, we were able to pick the right type of battery to power our Collide 3
AVM senior design project.
3.1 Lithium-Ion Battery
In the world today, the most common batteries out there for electronic devices are lithium-ion batteries. These batteries are everywhere in every portable device you know and love. You can find these in iPods, iPads, cell phones, laptops and many other devices that need to be supported on the go. Researching this battery for our Collide 3 AVM is a must, because these batteries can give a higher voltage than others can to split and support all of our components needs.
These can range between 3.2 volts to 3.7 volts. Lithium-ion batteries in smaller portable electronic devices uses prismatic lithium-ion cells while bigger electronic device like laptops uses cylindrical 18650 cells. Lithium-ion batteries are energetic and they are also rechargeable. There are three primary functional components in the lithium-ion battery. They are anode, cathode, and electrolyte.
Depending on what material is being used, voltage, life, capacity, and safety can all be changed. Lithium batteries are more expensive than Nickel batteries. Thus, they are so common and widely used. Also they have many important advantages over other competing technologies. This is a very important option for us.
In general, these batteries are picked to be in portable electronic devices are because they are very light weight and are rechargeable. These batteries are great to put into consideration. They are made of light weight lithium and carbon which make them so light. Also, another reason for their popularity is their ability to store a lot of energy. Lithium is the result of this ability. It is a highly reactive element. Thus, lithium-ion batteries have a very high energy density. Most lithium-ion batteries can hold up to one hundred and fifty watts hours of electricity in one kilogram. Compared to other types of batteries, this one has the highest capacity per kilogram.
- 17 -
Another important feature that these batteries have over their competitor is that they do not have any memory leak effects. This means you do not have to discharge them fully before you can recharge them again. You might have remember in the pass that you have to discharge a battery co mpletely so it’s capacity can stay the same. Now with these batteries, there is no need for such a draining process. Lithium-ion batteries also can hold their energy for a long amount of time. They only lose 5 percent of their energy in a span of a month. It can also provide very high current to applications that needs powerful force such as power tools. These are just some of the advantages of using the lithium-ion batteries. Now let us check out what the disadvantages are that might make us abandon this type.
Everything has a downside to it, including this battery. For starters, these lithiumion batteries need some kind of on board computer to keep their level in check. It requires some kind of power managing which could be more work for us and might be even more expensive than it is worth. These types of batteries also start to degrade very fast. They usually last for about three years whether you use them or not. A very important disadvantage is that it is very sensitive to high temperatures. This battery need to be able to withstand the heat from the launch and flight into space. Not so much in space but the heat dissipated from the launch might ruin the battery. These batteries also have a chance of bursting into flames if they fail. The chances are small but it could still happen. Being in space and enduring space, the battery might be put under lots of stress and usage. This is not good for these types of batteries because once they are completely dead, they are ruined. Unlike other batteries that needs to kill completely before you can charge them again, these can not be totally dead or they will be ruined.
Cathode Materials Advantages Disadvantages
Lithium-cobalt-oxide
(most common)
Lithium-phosphate
(newest)
Lithium-manganeseoxide
High Capacity
Very low ESR
Very high charge and discharge rates
High temperature operation
Inherently safer
Lower ESR
Higher charge and discharge rate
Higher temperature
Lower Charge and discharge rates
Higher cost
Lower discharge voltage
Lower float voltage
Lower capacity
Lower capacity
Lower cycle life
Shorter lifetime operation
Inherently safer
Table 3.1.1 Shows the advantage and disadvantages of Lithium-ion batteries with different materials
- 18 -
3.2 Alkaline Batteries
Most regular electronic device around your house that uses batteries are mostly alkaline batteries. When you open up the back cover of your television remote control, you will probably see an alkaline battery. They can also be found in CD players, digital cameras, simple kids’ toys, radios, and other electronic devices.
One reason why we could use these batteries in our Collide 3 AVM is because they are cheap and disposable. They are cheaper than the other batteries are to make, thus they are usually disposable. These batteries make up most batteries out in there today. They are dependent on the reaction with zinc and manganese dioxide. You might have seen AA, AAA, D, and etcetera. These batteries are most common around the house.
The normal voltage of a new alkaline battery cell is 1.5 V. You can get more voltage by putting multiple batteries together in series. The amount of current these batteries can give depends on the size of the batteries. For example, AA batteries can deliver about 700 mA, while D cell batteries can deliver a lot more.
Devices that use more current can be a flash light, which need the juice to handle this extra load it needs. A normal battery in used can vary between 1.1 voltage to
1.3 voltage. If the battery is old and almost dead, its remaining voltage can vary between 0.8 voltage to 1.0 voltage. You can noticed this when they flashlight start to dim as the battery is almost depleted.
A disadvantage of the alkaline batteries is that it leaks. They can leak potassium hydroxide as shown in figure 3.2.1. This usually happen to disposable alkaline batteries that are being recharged. Thus, they are called disposable batteries, because you should not recharge them. This can also happen when you mix battery types and new with old batteries. These batteries were not always disposable. Alkaline batteries produced before 1996 contained mercury which is not environmental friendly. Today they are safer and still there are special areas to dispose of these batteries. So even though these batteries are easy to use and are very cheap to buy, they are not that reliable if we need a high voltage source.
Figure 3.2.1 This picture shows the corrosion and leakage of potassium hydroxide out of the outer steel shell of an Alkaline battery.
- 19 -
3.3 Nickel-metal hydride Battery
These types of batteries are rechargeable and use a hydrogen-absorbing alloy for the negative electrode. The typical specific energy for a nickel-metal hydride double A battery cell is about 100 W-h/kg. Most applications for nickel-metal hydride batteries are expected in all electric plug-in vehicles. Same examples are
Honda EV Plus and Vectrix scooter. These types of batteries are widely used in rechargeable electronic devices. It is dangerous to over charge these batteries.
That is why you should not use any kind of battery charger to charge these. You should use a charger is made for nickel-metal hydride batteries. Thus, you have to be careful to not over charge.
There are advantages of nickel-metal hydride which includes high energy density but still lower then Lithium ion. These batteries discharge linearly but falls rapidly at the end of the cycle as shown in figure 3.3.1. A good thing about these batteries is that they can operate at a wide range of temperature which is good for our project. These batteries can also charge really quickly, as fast as an hour’s time frame. A great environmental friendly factor is that these do not contain cadmium, lead, or mercury. These are a lot safer then Lithium based batteries.
They do have their negatives as a whole. This type of batteries suffers from memory leaks. You have to discharge them completely before recharging them.
One important factor is that you can not overcharge these batteries or they will get destroyed, hence you have to get a charger made for it or have some kind of timer set for charging. Nickel-metal hydride batteries usually lose approximately thirty percent of their life force every month even if you do not use them at all.
Also, these batteries can only give off about 1.2 volts to our components. We would have to put these in series to get the power we need to support our components. Despite their negative contribution as batteries, they still hold strong advantages for us to consider.
Figure 3.3.1 This graph shows the rate of discharge of nickel-metal hydride battery compared to alkaline batteries. Alkaline gives more juice but the discharge curve is steeper than that of the
Nickel-metal hydride.
- 20 -
3.4 Power Source: Nickel-cadmium
Last but certainly not the least, is the nickel-cadmium battery. Also a great important source we could use in our Collide 3 AVM project. Like the nickel-metal hydride, it also only produce 1.2 volts, but nothing a series of these can’t add up in series to handle. It is also a type of rechargeable battery which uses nickel oxide hydroxide and metallic cadmium as electrodes. These batteries are simular to the NiMH batteries but do not have the same energy density but it gives off more current than the alkaline batteries do. Its main reason to be included in the research is of its ability to provide large amounts of current. That is something we should consider for our Collide 3 AVM.
In comparison to the other batteries, these have better long term storage and last longer. These batteries also have a slower curve of discharge rate. Their voltages decline much slower than other batteries. Another advantage for this type of batteries is that they are difficult to damage. Some disadvantages are that they are hazard to the environment, they cost more, and their temperature is relevant to their internal resistance and usually falls when temperature rises.
They use to be a primary use until lithium-ion and nickel-metal hydride became less expensive. Their main advantages are their high source of current. That is why we included them into research.
3.5 Compare and result
All these batteries have their strengths and weaknesses. Now let’s compare and seek out which one is the best for our Collide 3 AVM project. The first one that comes to mind for the best fit is the Lithium ion battery. It has the highest capacity per kg compare to all the other batteries. It produces the most amount of voltage as well. Thus it is very efficient to our project, but it is expensive, its discharge rate is really high and most importantly it is very sensitive to high temperature. Alkaline batteries have less voltage than the lithium ion but it is very cheap and disposable. It does have higher voltages than the other two nickel batteries though. The two nickel batteries are very similar but nickel-cadmium is hazardous to the environment. Nickel-metal hydride has an over charge problem and also degrade fast having age-related degeneration effect. On the other hand, nickel-metal hydride has a two to three times higher capacity than the same size nickel-cadmium can hold. The nickel-metal hydride has a self discharge rate of
30% per month as to the nickelcadmium only 20% per month. Lithium’s self discharge rate is the best at only 5% per month. Due to the higher voltage that a lithium battery can operate at, you would probably need two to three or more nickel batteries in series to operate at the same voltage that one lithium battery.
- 21 -
At first, the lithium-ion batteries seem like the best choice because it fits everything we need for it to be. After doing a little more research, one of its downfalls is the ability to withstand heat so there might be some heat involved during the flight. The alkaline batteries are cheap but they just do not cut it for what we are trying to do. The two nickel batteries are very close but we are going to go with the nickel-metal hydride battery. It is currently more widely used, thus cheaper and for our project, it won’t be up there for months so the self discharging rate is not a big deal. It is more environmental friendly so if anything happens to the project during the flight or in space, we didn’t have to worry about ruining the environment.
Battery Type Alkaline (non rechargable)
Ni-Cd Ni-MH Lithium-ion
Energy density 40-60 40-60 60 120
Cycle life
Power density
(W/kg)
Cost ($/kWh)
1
1800
150
2000
250-1000
2000
1800
3500
200 280 500-1000 Consumer electronics:
300-800
Vehicles:
1000-2000
Small size, light weight
Battery characteristics
High reliability, low cost
Memory effect
Currently, best value and most popular
Applications Small electronic device
Flashlight battery and electronic device
Flashlight battery and electronic device
Consumer electronics , cell phones, mp3 players
Table 3.5.1 Shows the description of all the different types of batteries and their applications.
All of our research and comparisons of battery types were liberated as we decided to use the power from the housing of the rocket. It wasn’t in vain though, because we understood batteries better from our researches. For our experiment and demonstrations, we temporarily used a 5v power supply to power it. While the flight will be hooked up to the rocket for power.
- 22 -
4.0 Research of FPGA
4.1 Introduction
A field programmable gate array (from here on referred to as an FPGA) is essentially a large array of combinational and sequential logic gates in a programmable environment. Each gate can be programmed to complete some digital logic circuit. Consideration of an FPGA versus a micro-controller for use in collide-3 AVM is necessary to determine the most accurate and fastest system to meet the high requirements of this project.
Summarizing the basic tasks that must be accomplished, in order to weigh in the use of an FPGA is necessary. In the initial stage of flight the system will be in a low power mode, during this time a monitoring system will be in place to poll the accelerometer for microgravity detection. After microgravity is achieved the system will activate an array of LED’s, send a pulse width modulated signal to open the experiments chamber doors, and finally start taking high shutter speed photos of the experiment. The camera in use will output a digital signal over
Ethernet which must be processed by the FPGA and stored to the solid state hard drive. The target frame rate of this system will be around 100 photos per second, which means the experiment will process a photo every 10ms on average. At that rate with an average file size of 1MB per photo, times 100 of those per second means we will be writing about 100MB per second without a buffer stage.
Because the system must be a hard real-time system in order for the experiment to be deemed successful, an FPGA can be beneficial since all operations going on are happening with minimum processing overhead, since an FPGA can be designed for each specific task unlike a microprocessor. Another advantage of an FPGA is its ability to do multiple tasks in parallel unlike a processor which must execute each instruction sequentially. FPGA’s can be programmed by using a few different methods, one simple way is schematic capture, which is simple pick and place design using block diagrams to describe your system.
Schematic Capture isn’t used for large projects due to the complexity required; hardware descriptive languages such as Verilog, VHDL, SystemC, etc. are used mainly because they allow a higher level abstraction essential to complex design.
For all implementations considered, Verilog will be the standard language due to the engineer’s on this team having most development time with it compared to the other languages.
One aspect of the environment that we had to consider for our system is the presence of ionizing radiation and high-energy electromagnetic energy in low orbit space. Ionizing radiation has the potential to flip the state of a memory cell; this is known as a “soft error” and is the common cause of single event upset
(SEU). SEU’s can affect user memory, registers, and memory cells. Because of
- 23 -
the extreme conditions of space, the components that will be considered will need to have gone through a process known as Radiation hardening to ensure mission critical data will not be affected.
4.2 Analysis of current FPGA boards
Having explained all the necessary requirements for an FPGA system, we can now look at different FPGA’s that are available to us. The main competitors in the market to choose from are Xilinx and Altera. Due to the need of Rad-Hard components, only Xilinx offers products geared towards the harsh conditions of low orbit space.
The virtex-5QV is the first high-performance space rated FPGA offered by Xilinx.
Xilinx chooses to use logic cells to determine logical capability, of which the
Virtex-5QV has 130,000 cells available. These cells allow the programming of various digital logic functions by using a ROM look up table. The virtext-5QV has a max temperature range of -65 to 150 degrees Celsius putting us within range of low orbit space temperature. In terms of turn on voltage required to power the device, 0.95 -
1.05 Volts is all that’s required. Of all FPGAs considered this one provided the most radiation hardened and tested components, making it a prime candidate for COLLide-3 AVM project.
The next device is the next step down, the Virtext-4QV. This Device actually contains more logic cells then the Virtex-5QV (over 200k). It contains a 350 MHz
PowerPC® core that can be easily dropped in, and a 400 MHz XtremeDSP TM.
This FPGA required 0.95
– 1.2 Volts to operate. Also featured are built in
Ethernet Media Access Control (MACs) to abstract the low level Ethernet protocol. The temperature range of the Virtex-4QV is -55 º C to 125º C making it less capable than the Virtex 5QV in terms of extreme temperature range.
However this board contains over 200,000 logic cells available, surpassing that of the Virtex-5QV.
Kintex-7 is actually the newer line up of Xilinx offerings, while not available in
Radiation hardened form, its use will be considered due to potential issues with procurement of the Radiation hardened FPGA mentioned above. The Kintex-7
FPGA is a high speed, low power, moderate cost solution if permissible use is allowed. Advantages to using this for the design would be its high transceiver speed, which reaches speeds of 12.5 GB/s, which greatly exceed the amount of data being received from the camera. It can also reach a LVDS (Low voltage differential signaling) speed of about 1.6 GB/s, which can potentially help with writing data to the hard drive. The Kintex also supports Full Duplex (Data can transfer both ways simultaneously) Serial communication with speeds of up to
800 GB/s. Also on board are 478K Logic cells, easily out pacing the other 2
FPGA’s considered thus far. Kintex temperature operation range can go from -
- 24 -
40C to 100C on its industrial grade series, however further testing would be required to determine how it would fair under such harsh conditions as a launch.
4.3 FPGA design
Now that the FPGA requirement’s and potential package solutions have been considered, it is time to discuss how the FPGA itself will perform the required tasks. The following tasks were divided under their own sub section to further expand on the challenges each one presents: µGravity detection, PWM line for motor control, LED Array power on, Ethernet Signal processing, Serial ATA processing, Display module, and finally File Storage Format.
The first element to consider for this design is micro-gravity detection sensor input. Any implemented design must take into consideration any false signals sent from the accelerometer, so that our experiment doesn’t start pre-maturely.
For this problem, a digital counter can be implemented, one of n-bit length, that increments itself every time the sensor sends a no gravity flag, and resets itself whenever a gravity signal comes in from the accelerometer. Once the counter reaches say all 1’s then this specific pattern can be matched by a sequence detector. An example of a 2-bit system is shown below in figure 4.3.1.
Figure 4.3.1 Once the final state is reached, a global flag can be set, initializing all other systems, or a cascade system could be used, where certain sub-systems can be powered on in a time delayed sequence.
- 25 -
Unfortunately the FPGA’s we are considering do not have any onboard PWM output lines, which means this had to be implemented in Verilog code. In order to reproduce a PWM line we simply need to toggle between on and off at a certain frequency within one clock cycle. Since this PWM will not operate at high frequency, the clock can be generated from the FPGA itself. Two things we had to consider are the Duty Cycle and the frequency. Duty cycle is simply how much time a pulse is active for over its clock duration, while frequency is simply how often it switches on and off in one clock cycle. Also this PWM line will not be variable frequency, making it even simpler.
An LED power on can be achieved simply by a controlled switch between the
LED arrays and a power source, a FET could achieve this goal, by connecting the base of the transistor to the I/O line for the power on flag. When the I/O line is set high it will close the gate allowing current through, but while no voltage is applied the mosfets gate will remain in depletion mode and will cut off any current from passing through as shown in figure 4.3.2.
Figure 4.3.2 Show cut off current pass.
In this Project the camera is sending a digital signal over a Ethernet wire, this wire is received onto the FPGA, processed and prepared for SATA transmission to the solid state drive. Ethernet speeds of about 100 Gbps can be achieved, again outperforming our design requirements. Xilinx FPGA’s contain an onboard
GTB transceiver useful for taking the signal from the Ethernet line and getting the signal into the system.
Serial Advance Technology Attachment is the protocol that was needed to interface with any Solid State Drive at a reasonable speed. Serial ATA can provide a transfer speed of up to 6 Gb/s, which is more than enough for the speed we are looking to transmit. Implementing this however may prove to be the most challenging aspect of this project, the Protocol involves many layers of bit packing and processing overhead in order to send and receive data, and implementing that into an FPGA would require grounds up approach.
- 26 -
Serial ATA Architecture consists of 5 layers of functions that must be carefully considered in order to implement correctly, as shown in the diagram below, those layers are: OS/Application, Command, Transport, Link, and Physical. Each layer adds its own overhead to the data bits, by packaging them with their own information, this is done to prevent errors and ensure data can be recreated after transmission as shown in figure 4.3.3.
Figure 4.3.3 Shows the cables connector to the Device and the Application
Physical Layer is the lowest level of the interface, it is responsible for generating the signal that will actually be transmitted over data bus, and to decipher signals received over the data bus.
Link Layer defines the encoding for the data being transmitted, and defines the control signals and protocol that reliably transmits packets of data between a transmitter and receiver. Link layer is also responsible for recovering the Clock signal, since the clock signal is implicitly determined from the actual data sent.
Transport Layer defines the format and functions of data structures that are exchanged between the transmitter and receiver. SATA refers to these data structures as FIS (Frame Information Structures). Transport layer is the bridge from hardware and software.
Command Layer defines the sequences of FIS frames exchanged to support all the command protocols that are defined in the SATA specification.
- 27 -
Application/Device Control are specific programming registers that must be written to actually give the ability of software to interface with this Data.
Essentially a SATA controller must be created; fortunately Xilinx provides documentation for implementing the physical layer, however the rest was implemented in the design. Another factor that was considered is Power management since the goal is a mobile application.
4.4 Display Module
The Display Module is essentially a method for a user to read current system settings, and change certain variables as they see fit, it will consist of a simple
LCD screen and a few push buttons to change Data. The variables that need to be changeable are, Experiment start time, LED turn on time, Camera turn on/off time, motor activation time. Users interaction with the application shown in 4.4.1.
Figure 4.4.1 Use Case for Display module
- 28 -
5.0 Microcontroller Research
5.1 Overview
COLLIDE-3 has many components that will need to be activated in a set order throughout the flights experiment. Specifically, we need to be able to read an input from an accelerometer, and send outputs to relays which will be controlling
LEDs, muscle wire, microstep drivers (both with a flat DC level and a PWM line), and a camera. Important features of the microcontroller for us will include: Flash memory available, number of I/O lines, clock speed, package type, operating voltages, output voltage levels, power consumption, robustness, temperature ranges, and ease of programming. Perhaps the most important feature of all, however, was how does it integrate with the camera when we decide on utilizing the microcontroller to process the data received from the camera’s Ethernet output line.
5.2 Requirements
Some features of our microcontroller are fairly set in stone, while others should be considered to eventually adapt to future iterations of the COLLIDE-3 experiment. Thus, we aimed at finding a microchip to interact correctly. For instance, while our current experiment needs a minimum of 7-8 controllable I/O pins, future versions of the experiment may add additional control variables, so upwards of 14 I/O pins would be ideal. Clock speed for most of the components is not essential; even the lights turning on a full second after they should have would not have a massive impact on the experiment. Outside of the camera, the only set frequency requirement is the 800hz that we wish to operate the microstep driver’s multiple PWM lines off of. If our project decides to implement an FPGA or other device to control the camera rather than using the microcontroller, we will need to try to match the clock frequency of the microcontroller to that of the FPGA/device.
Package type will be considered mostly for convenience/expansion. A DIP style pin layout is more intuitive and something we have more experience creating than a QFP/QFN package style. Also, while it obviously wouldn’t be ideal, it is possible to modify a DIP style pin on a PCB board with last minute wirings, while nearly impossible to do the same with a QFP/QFN.
Since one of our considerations is whether to have an on-board power source or to rely on the availability of one aboard the rocket, power consumption is of heavy consideration throughout the entirety of our project. Likewise, since we
- 29 -
had to provide the voltages to control the microcontroller, the operating voltage were considered. Finally, depending on the relays we use to be controlled by the microcontroller, output voltages were kept in mind, though we adapted the relay to match the microcontroller, rather than the other way around. It is unlikely that a microcontroller will operate in such a range that the industry doesn’t make relays to support it.
The chip we selected is robusted enough to pass a suborbital vibe-test. While the chip doesn’t necessarily have to be military grade, it also cannot be fragile. The purpose of suborbital flights, and also this AVM, is eventually to be manned flights, thus the chips does not experience vibrations, temperatures, or forces that humans are incapable of.
Another consideration for our microcontroller is the ease of which they can be programmed. One of the main advantages we see in microcontrollers over
FPGAs is that they can be written in languages such as C/Assembly, rather than
HDL/Verilog. If the programming of the microcontroller proved to be unjustifiably complex/unable to integrate with the LED display we plan to implement, any advantage of the microcontroller would essentially be lost.
Our final limiting factor for our microcontroller choice was either completely inconsequential or our most important consideration, depending on how we decide to handle the data coming out of the camera. The microcontroller must have a good way of handling data coming from an Ethernet port and transferring it onto whatever data storage device we choose, most likely a Solid State Drive.
Since data from the camera might be coming in at speeds as high as 100MBps, the microcontroller must also be able to handle high volumes of memory transfer at any given time. However, if we end up using a different method for storing data off of the camera (FPGA, Gumstix, etc), then we won’t need to consider this at all.
6.0 Microcontroller Choices
6.1 ATmega328/328P with Arduino Optiboot
The ATmega328 is a fairly popular microcontroller on the market, being only improved on by the 328P which offers the option of a picopower mode, and matches the requirements of our project quite well. It contains 32kb of flash memory, with .5kb of that being used for the bootloader. Flash memory works well with our project, since it is robust enough to survive the vibrations COLLIDE-
3 is likely to experience during flight. Also, while flash memory only survives
10,000 read/write cycles, it is extremely unlikely that we utilized the flash on the chip to anywhere near that capacity during COLLIDE3’s experiments. Since the
- 30 -
temperature range of the chip is listed as
–40 to 85 degrees C, the chip should be robust enough for our needs.
The Atmega contains between 28 and 32 total pins (depending on package type, discussed below), with 23 of those having I/O capabilities, and a staggering 6 of them capable of acting as PWM lines, far exceeding any amount future iterations of the AVM may need. The chip operates in a voltage range of Vcc = 1.8V-5.5V, which is fairly standard and was easy to supply. The maximum operating frequency of the clock is 20Mhz.
A good feature about this choice is its power consumption. Even the 328, which lacks the picopower mode of the 328P, offers many power saving tools. When operating at 1MHz and utilizing a 1.8V Vcc at standard temperatures (25 degrees
C), the chip will consume .2mA in active mode. However, the chip has a power save mode available which lowers consumption to .75uA, and a power down mode which further lowers power consumption to just .1uA. These features make the ATmega328/328P described as a “low-power microcontroller”, which was something heavily considered when we didn’t have an active power source available on our flights. All of the power saving modes (5 in total, though the ADC
Noise Reduction mode was irrelevant for our project) are selectable through software.
Mode Power Consumption Chip Status
Active
Power Save
.2mA
.75uA
Standby*
Power Down
.50uA
.1uA
Everything running
Asynchronous timer running. User can maintain timer base while rest of device sleeps.
Crystal/resonator running, rest of device is sleeping.
Registers saved, but oscillator frozen. All other chip functions disabled until next interrupt or hardware reset.
*
Standby mode allows very fast chip startup, producing stable clocks in just eight clock cycles.
Table 6.1.1 Shows the power consumption of each mode of the microcontroller and their chip status.
Package types encompass just about anything we would want depending on our
PCB design. Atmel offers the following choices for package type with the
328/328P:
- 31 -
TQFP, Thin Plastic Quad Flat Package
QFN, Quad Flat No Lead
PDIP, Plastic Dual Inline Package
Of these three, the first and the third are the ones most likely to be used in our design, depending on whether we want a through-hole chip (as offered by the third), or a surface mount chip (as offered by the first). It should be mentioned that the TQFP and QFN both are a 32-pin design, while the PDIP has 28 pins.
Programming for ATmega chips is fairly simple, and the same holds true for the
ATmega328/328P. The chip itself comes preburned with a bootloader, meaning it’s ready to have code uploaded to it without the use of any external hardware programmer. As for the creation of the code it used, the ATmega328/328P utilizes the Arduino 0023 software, which is simply an open-source language of
C/C++ functions that can be called in the code.
Finally, we have the data transfer side of the microcontroller. This is where the
ATmega328/328P, and evidently most (if not all) microcontrollers fall apart. We estimate that with our camera resolution and frame rate, upwards of 100MBps will be transmitted through the Ethernet cable out of the camera, through the microcontroller, and then written onto the hard drive. Unfortunately, the
ATMega328/328P protocol acts as follows; It sets pins to allow the reading of a packet, fills the buffer, then sets a different set of pins to allow the writing of the packet. Running at a clock speed of 14.76 MHz, the ATmega328/328P can only transfer 57.6kbps. This is obviously not even a noticeable fraction of the data we intend to transfer, meaning when we utilize this chip, we had to find a new method of data transfer.
6.2 ATmega644
The ATmega644 is very similar to the ATmega328/328P, with only a few minor differences, explained in the table below:
ATmega328/328P ATmega644
Flash Memory
Pin Count
Max I/O pins
32k
28 PDIP/32 TQFP/32 QFN
23
64k
44 VQFN, TQFP, 40 PDIP
32
Table 6.2.1 Shows the minor differences of the two Atmega models.
The ATmega644 obviously has the advantages of more flash memory and more pins capable of being assigned to I/O operations, but the increased pin count will
- 32 -
also increase the amount of our PCB board required to allocate to the microcontroller chip. We didn’t need to use the extra memory/pins from the 644, the 328/328P proved to be the more intelligent choice.
6.3 Parallax Propeller
The Propeller is one of many microcontroller chips offered by Parallax. Its main draws are its ease to integrate to external hardware components, and 8processors which can operate at the developers discretion, either independently or cooperatively. Its ease of integration to external components could be very useful for our LED control panel, while the multi-processors could ensure the ability to be running various protocols at any given time during an experiment.
The packages available for the Propeller are very similar to that of the ATmega
328/328P:
40-pin DIP layout
44-pin QFN layout
44-pin QFP layout
Again, the best candidates for our project would be the DIP or QFP layouts, with
DIP the front-runner. In both the 40-pin and 44-pin layouts, there are 32 I/O ports available (28 general purpose, the rest are utilized by the boot up protocols, then become available after), more than double the theoretical max needed for
COLLIDE-3. While none of the pins are explicitly stated as having PWM capabilities, the presence of eight processors means the timing hardware contained in the chip could be utilized to implement PWM signals.
Effective clock ranges are very high for the Propeller compared to the
ATmega328/328P, running at effective clock rates of 32kHz to 80kHz. Power input for the Propeller is 2.7-3.3V DC, which is very easy to supply. Power usage by the Propeller is not nearly as optimized as that of other chips on the market, but the user can have a lot of impact on the power consumption through intelligent programming. Obviously, lowering the clock rate can have significant impacts on power usage of the part, but also utilizing less of the eight processors can reduce power consumed by the microcontroller.
Programming for the Propeller ranged from very simple to intermediate programming skill required. This is due to the variety of languages that are compatible with the Propeller. Users have the option of using any of the following programming choices:
Spin
Assembly Language
C
- 33 -
Of the three option, Spin is by far the easiest and most common, with assembly requiring some sort of programming background to be able to implement properly. The Propeller can be programmed and compiled in a C environment due to a compiler provided by ImageCraft, but the compiler is considered in its
“End of Life” state, so it will not be considered for this project. Naturally, while spin has its upsides, it also has drawbacks compared to assembly language. The two choices are compared in the table below:
Language Advantages Disadvantages
Spin
Runs slower than pure Propeller assembly
Assembly
Very minimal programming difficulty
More space efficient
Avoids memory segmentation issues
Faster run time
Better for exact timing
I/O routines
Opcodes 4x larger than Spin
Memory segmentation issues must be considered by programmer
Table 6.3.1 Shows the advantage and disadvantages of spin and assembly language.
Since our group has experience with assembly language, and run time is most likely more important than space efficiency, the extra work required to create the routines through assembly might prove worth it if we decide on the Parallax
Propeller microcontroller.
The same glaring problem occurs with the Propeller that we ran into with the
ATmega328/328P/644, in which the amount of data reading/writing would not approach anywhere near 100MBps, which renders this microcontroller also useless if we were dead set on utilizing a microcontroller to transfer data from the
Ethernet line onto a hard drive. This was upsetting with the Propeller especially, since one of the advertised features is its ability to provide direct video output.
However, the resolution and speed of the video referred to by these statements from Parallax nowhere near approach the specifications COLLIDE-3 will deal with.
- 34 -
6.4 PIC16C57
The PIC16C57 is mostly known due to being used in the Parallax Basic Stamp 2 microcontroller module, which is the veritable flagship of Parallax, and for good reasons. It’s extremely easy to use, a lot of documentation is readily available for it, and if your project doesn’t need the complex features of more advanced microcontrollers (eight processors, video generation capability), it can do everything you would need. We decided to utilize the microcontroller for only the more basic features of our project, the PIC16C57 might pull ahead of the other choices just due to simplicity.
In terms of raw requirements, the PIC16C57 doesn’t pull away like the rest of the microprocessors, but it meets all of the standards set by us. A 20MHz processor speed is fairly standard, and is likely to mesh well with an FPGA if we were to implement one but we did not. 16 I/O pins is slightly more than our maximum projected pins required for future project expansion, so while other chips might have 30+ available, any over the max theoretical needed are just redundant.
Current draw is rated at 3mA in run mode, and 50uA in sleep mode (assuming a
5VDC).
Parallax offers the Basic Stamp (PIC16C57) in two different package types:
28-pin DIP
28-pin SSOP (Shrink Small outline package)
The SSOP is cheaper and smaller, thus freeing up more PCB real estate, but the
DIP design is far easier to solder/apply to a board. The DIP design is also likely to prove to be more robust in heavy vibration environments. Operating temperature ranges for the DIP is 0 to 70 degrees C, while the SSOP has a range of
–40 to 85 degrees C. The Basic Stamp 2 is also less vulnerable to static electricity than most microcontrollers on the market.
The input voltage for the PIC16C57 is 5V, and provides a 5V output as a high signal to any of its I/O pins. When found on the Basic Stamp 2, an input of 5V-
15V can be used, since there is a built in DC to DC voltage regulator that will step down any voltage from 6V-15V down to 5V.
Perhaps the biggest advantage held by the PIC16C57 is the language which it can be written in; Parallax’s PBASIC. PBASIC is intuitive, easy to use, and easy to get it to do what you want. I didn’t mention any PWM lines available on the chip, because it’s very simple to use PBASIC to force any of the I/O pins to act as a PWM line for a period of time. This, however, could be a downfall of this chip. Since the PIC16C57 only has one processor, it is likely not possible to create two separate PWM lines at the same time (as per required by the microstep driver to open the COLLIDE-3 door during the experiment). If multiple
PWM lines are indeed impossible to implement on the PIC16C57, our choice will be to either innovate a new idea to split the PWM line signals sometimes and not
- 35 -
other times, or we just simply have to ignore the PIC16C57 in our considerations for which chip to use.
As expected, the PIC16C57 fails in the same magnitude as the rest of the microcontrollers when it comes to data transfer capabilities. Microcontrollers in general don’t have large enough of a buffer/transfer capabilities to make them even valid candidates for our method of data transfer, but the PIC16C57, being designed specifically for very basic and simple uses, supports even less than the rest.
6.5 Microchip Comparison
We considered a total of four different microchips for our project: The
ATmega328, ATmega644, Parallax Propeller, and PIC16C57. Due to the scope of our project, we almost immediately assume that the extra benefits gained from upgrading the ATmega328 to the ATmega644 would go to waste. It is highly unlikely that the extra 32kb of flash memory will be utilized, or that we will need any additional I/O lines available on the chip. Thus, the increased size of the
ATmega644 would prove only to be a detriment over the ATmega328, costing us more of our board space without being able to use the additional features gained.
Therefore, we will rule out the ATmega644 from our considerations.
That leaves us with three remaining chips to compare. Of the three, the Propeller stands out much in the same way that the Atmega644 did; powerful by comparison, but in ways that we might not end up using and costing more space on our board to pay for it. The Propeller is a chip that we kept in consideration if we decide that the microcontroller absolutely has to be in charge of taking the video feed from the camera and putting it onto our hard drive (due to its excellent ability to read video feeds), but since in all likelihood we tried to find an alternate way to handle the data coming from our Ethernet line, the Propeller is not the chip we planned on using.
The two remaining chips are very difficult to choose between, and our project would probably run almost the exact same no matter which we choose. Both are the primary component of well known microcontroller boards; the Atmega328 being used on the Arduino Uno, and the PIC16C57 being used on the Parallax
BASIC Stamp BS2. Both are of relatively equal sizes and cost, with equal documentation and support available. Both definitely have a lot of merits to consider, so the table below focuses on the differences that are most pertinent to our project.
- 36 -
Power Consumption
I/O pins
Package Types
Total Pins
ATmega328
Very low
23
TQFP, QFN, PDIP
28-32, depending on package type
C/C++
PIC16C57
Average (in comparison to ATmega328)
16
DIP, SSOP
28
Programming
Language
PWM Lines
Vibration Capable
6
Yes
PBASIC
None
Yes
Table 6.5.1 Compares the ATmega328 and PIC16C57
To summarize the above, the ATmega328 wins in power consumption, though only by a few mA when our overall project supplies full amps to some components. Every bit of power can count on a suborbital flight though. While the
ATmega328 may appear to win with more I/O pins, both provide more than is currently necessary, so it’s not a huge advantage, and actually makes the chip take up slightly more space in the TQFP/QFN packages, sporting 32 total pins versus the 28 of the PIC16C57. However, both DIP style packages contain 28 pins, which is the setup we are most likely to utilize. Being familiar with PBASIC, the ease of which the PIC16C57 can be programmed is definitely a huge benefit, but programming the ATmega328 in C can hardly be considered difficult.
The ATmega328 has a very great selling point with its 6 dedicated PWM lines, compared to the zero found on the PIC16C57. While the PIC16C57 can temporarily create a PWM signal on any of its pins, it ties up the entire chip in the process of doing so. Since needed two individual PWM lines to be activated concurrently with other processes, finding a workaround for the PIC16C57 may prove to simply be too much trouble to consider. Both, however, appear to be equally suited to the ruggedness requirements imposed by the suborbital flight it will be used on.
Considering all of the above, we went forward designing our experiment around the ATmega328 chip. It encompasses everything we needed from a microcontroller, without sacrificing any capabilities like most of the other choices.
Anything it does better than we need doesn’t go to waste either. For example, while the massive amounts of I/O lines on some chips simply made them bigger for our purposes, the super-low power consumption of the ATmega328 serves in no way as a detriment, and is just a nice little plus that we get out of our choice.
As our experiment moves forward, we kept the Propeller chip in mind. While we hope our current design proves to be effective, we didn’t rule out the possibility that we might need the microcontroller to handle the video stream data, or at
- 37 -
least help in the processing of it. The other chips can be effectively forgotten, as we can’t imagine any issues that would arise during production that would be solved by the advantages provided by the ATmega644 or PIC16C57 over the
ATmega328 or Parallax Propeller.
What remains for the ATmega328 now is to convert it from a microchip into a fullfledged microcontroller board. As mentioned earlier, one of the draws of using the ATmega328 was the amount of documentation and support available with it.
Since the introduction of the Arduino Uno, the ATmega328 has been a favorite among Do-It-Yourself (DIY) projects, meaning finding the optimal setup for the chip tailored to our needs should be well within our abilities. Also, should anything not work as we expect, there are many documented ways to troubleshoot and test this chip, which severely drop the amount of time we spent troubleshooting in the building stage.
7.0 Microcontroller Board Research
7.1 Overview
Once a microchip was decided on, we had to integrate it into a full-fledged microcontroller board by adding the rest of the components often seen on a microcontroller. These include, but are not necessarily limited to:
Voltage Regulator
Clock Crystal
Reset Button (i.e. Normally “off” switch)
A way to communicate with USB/Serial/Ethernet ports
Since we have decided to utilize the ATmega328, we tailored our microcontroller board around integrating this chip. The ATmega328, as discussed earlier, runs with a Vcc of 1.8 to 5.5V DC, with an ideal/standard Vcc value of 5V. To achieve this, we will use the Fairchild Semiconductor KA7805 Voltage Regulator. This component can handle up to a 35V input and regulate it down to the 5V our
ATmega328 wants. We have the option of using either the TO-220 Power
Package, or the TO-263 Surface-Mount Package. Most of our designs have been geared towards using the DIP-style pins on our board, so while it may be subject to change, we assumed we were utilizing the TO-220 Power Package. Even if the rest of our board ends up in the surface-mount design, we may stick with the
TO-220 for the voltage regulator, simply because its upright-style design ends up using less overall real estate on our PCB board.
For the clock crystal, the ATmega328 integrates best with a 16 MHz external clock. For this, we will most likely want to use the “Resistance Weld Thru-Hole
Crystal”, model number HC49SLF by Fox. This crystal supports a frequency range of 3.2 to 70 MHz. We achieved a frequency of 16 MHz through connecting
- 38 -
two 22pf capacitors from this component to ground. Overall, this setup of crystal resonator ended up taking very little space up on our board.
Most microcontroller boards come with a sort of “reset button”. While for our final applications this probably won’t be essential, it will be very useful in the testing/debugging of our project, so we have decided to include one on the board. The simplest way to implement this is the B3F from Omron. While a physical “switch” could be useful in some implementations as a way to prevent the chip from doing anything for extended periods of time, most likely during our testing simply being able to send a signal to the ATmega328 “reset” pin will be sufficient, thus we will be going with the very basic push button style. This also takes up very little real estate on our board.
8.0 Microcontroller Design
8.1 Integration with COLLIDE-3
Since COLLIDE-3 as an experiment has already been built and tested (by tested, we mean while it hasn’t flown on a suborbital rocket yet, it has been on a vibrations table at Blue Origins facilities in Seattle), it makes sense to change as little as possible about COLLIDE-3 itself, but rather integrate our AVM into the designs already in place.
As you will see below in Figure 8.1.1
, the inputs that we’ll be needing from the
AVM into the COLLIDE-3 module are three power lines at 24 volts, two PWM lines (seen as one split into two ports on the schematic, our design will have individual lines), a power line for our camera of choice, a data transfer line
(shown as Ethernet for the original camera used), and grounding lines. A minor change that will be made, but won’t affect the functionality of COLLIDE-3, is that instead of a 24 volt input source, we will be assuming a 28 volt input source, since this is the power supply level that we have found to be more common among suborbital rocket power grids. As stated though, this will merely be a cosmetic difference, for the only direct input from those DC power sources goes to DC to DC converters, for which the CINCON EC7A-24S12 chip is rated for converting up to 36 volts down to 12, and the POWER TRENDS PT78ST106H is rated for converting up to 38 volts down to 6.
Obviously, we can’t use our ATmega328 to directly power all of the components within COLLIDE-3 itself, since the microcontroller puts out a high signal of 5V, and many of the components require more than that. Therefore, our design consisted of the ATmega328 microcontroller controlling a series of relays, which then provide power to each individual component. For the sake of not having to redesign COLLIDE-3 too much, even the components that the microcontroller
- 39 -
may be able to power itself (5V is probably close enough to the 6V required by a couple of the parts) by relays. The only probable exception to this is the PWM lines, since they were originally direct feed throughs from the AVM. However, if the microcontroller PWM line doesn’t provide enough of an amplitude to power the microstep driver, we had to find a relay that can switch fast enough to act as the control for those PWM inputs. Figure 8.1.1 shows the COLLIDE 3 schematics.
Figure 8.1.1- COLLIDE-3
- 40 -
8.2 The Microcontroller Board
Before we start connecting the microcontroller outputs to various relays and
PWM signals, we must first find the best way to physically build the board around the ATmega328 chip. We hooked up the chip to the crystal, voltage regulator, power source, and reset switch as seen in Figure 8.2.1, and then hook up the
USB to Serial communication board as seen in Figure 8.2.2:
Figure 8.2.1-Layout for ATmega328
- 41 -
Figure 8.2.2-Serial to USB Converter attached to ATmega328
8.3 Integrating with other components:
The above microcontroller board was integrate with the various other electrical components that was found aboard our AVM. Namely, these include the accelerometer, camera, and the UIM, along with any on board data storage we choose to utilize. In terms of our PCB, obviously the ATmega328 and all of its board critical components was traces and soldered onto it, along with the accelerometer since placement of the accelerometer is inconsequential. The
UIM, however, has connections leading to the PCB, but was not found on the
PCB itself, since it has to be in a user friendly location on our AVM, and our PCB will likely be tucked away safely. Likewise, our camera and external storage device have pin connections leading to the PCB, but since both need to be removed at some point or another, the only thing soldered and traced onto the
PCB was the breakaway connections or terminal blocks.
Given the pin layout of the Hitachi H48C 3-Axis Accelerometer, we connected it to the ATmega328 as shown below in Figure 8.3.1:
- 42 -
Figure 8.3.1-H48C 3-Axis Accelerometer attached to ATmega328
Pin 6 (Vdd) and Pin 3 (Vss) will be connected to our regulated 5V power supply on the PCB. Pin 4 of the ATmega328 was utilized to read the Zero-G flag (also
Pin 4) provided by the Hitachi H48C. The synchronous clock input and chip select input (Pin 1 and Pin 5, respectively) on the H48C was connected to the
ATmega328s crystal connections on Pin 10 and Pin 11. Finally, the Bi-directional data to/from host (DIO, Pin 2) will connect to Pin 11 on the ATmega328, which is its Digital Pin 5.
For starters, to power the camera, Pin 1 and Pin 2 on the 5 pin connector labeled
“Power” must be connected to a DC source with a voltage between 10.5 and 24.
The standard AC to DC power cord that comes with the camera regulates the
120VAC wall input to 12V DC. Since we are not guaranteed to have an AC source available on the plane, we will be using a DC to DC converter to step down the 28V DC source to 12V DC. Pin 4 and Pin 5 of the same connector was connected to ground.
Shown next in Figure 8.3.2 is how to connect the MotionBLITZ Cube2 to our
ATmega328 microcontroller:
- 43 -
Figure 8.3.2-MotionBLITZ Cube2 connected to ATmega328
Next, Pin 1 of the 8 pin connector labeled “Trigger” must be grounded. Pin 7 of the same connector is the trigger input for the MotionBLITZ Cube2, which was utilized to start and stop the recording of our experiment. We connected this to
Pin 18 of the ATmega328, which is Digital Pin 12. Pin 7 internally has a DC to
DC converter to 3.3V, which will convert up to a high signal for an input current of
5mA. The digital pins on the ATmega328 (specifically Digital Pin 12, which we have selected), should be able to achieve this.
Finally, when we decided to have an external data storage unit, such as a solid state drive, connected to the MotionBLITZ Cube2, we connect the Gigabit
Ethernet connection to the equivalent data port on the storage unit, such as the serial port for a solid state drive as represen ted in Figure 5. What isn’t shown in
Figure 5, since the point of the figure is more towards connection to the microcontroller, is how we interface with the data transfer. This is discussed in a different section. When we decide to utilize the internal storage capabilities of the
MotionBLITZ Cube2, we simply leave out the interface shown in Figure 5.
- 44 -
Remember that at preliminary stages of the AVMs life, there will not be a
MotionBLITZ Cube2 attached at all, but rather a GoPro HD Hero Naked camera.
No schematic is necessary for this, for the following reasons:
With the extended battery pack, the camera can record for 5 hours
(though it is limited by its 4 hour 21 minute internal storage). Thus, we didn’t connect it to the DC power shown.
As stated, it has 4 hours and 21 minutes of internal storage, removing the need for an interface to an external storage device.
Since it can record for longer than our expected total flight time, there is no need to control the GoPro HD Hero Naked at all with the ATmega328.
It can simply be turned on at the start and left on for the entirety of the flight. Thus, the interface with the ATmega328 shown in the schematic would not exist.
Therefore, the GoPro HD Hero Naked can act as its own entity in the experiment, and requires no integration whatsoever into the electrical components of the
AVM. So, when we are utilizing the GoPro HD Hero Naked instead of the
MotionBLITZ Cube2, we modified our program to ignore Pin 18 on the
ATmega328, and simply disconnect power to the 28 to 12 DC to DC converter that powers the MotionBLITZ Cube2.
9.0 Microcontroller Testing
There are many parts of the microcontroller’s functions that must be tested to ensure that our project as a whole was functioning off of the microcontroller as planned. First, naturally, we tested the microcontroller itself, and implement features to ensure that we never create a short passing through the microcontroller. Next, we had to test the PWM lines to make sure t hey’re creating the correct frequency to operate our stepper motor. Another function that was needed to be tested is ensuring that the microcontroller is activating the relays at the right times (i.e. our “on” current provided by the microcontroller is read by the relay as “on”). Additionally, we had to ensure that our serial to USB connector is properly transmitting. Finally, we need to see that we properly read in a signal from the accelerometer in a zero gravity environment.
- 45 -
9.1 Testing of the microcontroller itself
To begin, we had to install a safety feature onto our microcontroller board for our testing stages. By attaching an LED across the regulated 5 volt power supply entering our microcontroller, we were able to tell two things:
1. We always were able to tell when our board is receiving power
2. We immediately were able to identify when a short is present
The LED, as seen in Figure 9.1.1, will be lit up any time we have a power source attached and activated to our microcontroller. This way we won’t be messing with components while we accidentally left on the power supply. However, if we have our power supply on and the LED is still unlit, that means we have a short somewhere in our circuit and need to immediately cut power and debug.
Figure 9.1.1-Voltage added across regulated 5V supply
In the case of the light being on, we would continue with debugging as usual.
Just for the sake of completeness, however, we first took a multimeter and attach its positive end to Pin 7 of the ATmega328 (Vcc) and its negative end to Pin 8
(GND) to ensure a reading of 5 volts (this acts as a way of testing the voltage regulator). In the case of the light being off, we took a multimeter and begin searching for the supply of the short (after of course making sure the LED itself was hooked up properly). To do this, we took the multimeter (in Ohms mode) and attach the positive end to Vcc and the negative end to GND. If the reading is close to zero ohms, we have confirmed the short. From there, it’s simply a process of checking each connection and finding the one that bypasses a component by mistake and goes directly from our power source to the ground line.
- 46 -
9.2 Testing of the microcontroller with the FT232
Testing the serial to USB component (FT232) of the microcontroller board is a fairly straightforward process, but telling the difference between a failure of the
FT232 versus the ATmega328. To test it, we first assume that we have built our microcontroller board as laid out in the Microcontroller Design section of this paper with the FT232 attached, and tested that the microcontroller itself is at least attached and powered as described above. From there, testing of the
FT232 is as simple as connecting the board to a computer through a USB cable and creating a program in the Arduino programming environment to activate some part of the ATmega328. If the program runs as it should, then the FT232 is properly communicating with the ATmega328.
Of course, if the above test doesn’t work, the results may be deceiving. A failure could occur either through failure to communicate through the FT232, or a failure of the ATmega328 itself. Luckily, we have a way to differentiate between the two.
Before we hook up the FT232, we will first test the actual capabilities of our microcontroller to send a high and low signal to one of its pins. We are able to do this because we are purchasing a pre-bootloaded ATmega328. This means that by default, it will have the blink_led program loaded onto it and ready to run.
What this program does is switch Pin 19 (Digital Pin 13) on and off, essentially blinking an LED. It seems only appropriate then that we must confirm the successful running of this program by attaching an LED and ensuring that it is, in fact, blinking. The setup for this circuit is displayed in Figure 9.2.1:
Figure 9.2.1-ATmega328 hooked up to run Blink_LED
With the above test, we were able to tell the difference between a failure of the
ATmega328 and a failure of the FT232. This is the point of our testing where we would actually attach the FT232 to our board and try loading a program onto it.
- 47 -
This timing is ideal, since we already have one of the pins hooked up to an LED to test. With a quick reconfiguration of our schematic from Figure 9.2.1 to Figure
9.2.2, we are now ready to test the FT232.
Figure 9.2.2-FT232 configured to program the ATmega328 and output to Pin 19
By utilizin g Pin 19 for our test, we remove the possibility that it’s the pin on the
ATmega328 not functioning properly, since we have already tested its capabilities. In the Arduino programming environment, we will create a simple code that switches on and off the LED at a different rate than Blink_LED did in our previous test. If we can observe the difference, then the FT232 is successfully communicating with our microcontroller and we’re ready for programming it. At this point, we tested the rest of the Digital I/O pins to make sure they operate in the same manner as Figure 3 when connected.
- 48 -
9.3 Testing of the PWM lines
Next, we ensured that the PWM lines on our microcontroller are properly suited for providing the 800 HZ frequency required to drive the stepper motor. To do this, we will be attaching Pin 12 of the ATmega328 (Digital Pin 6, PWM) and Pin
17 (Digital Pin 11, PWM) individually to first an oscilloscope, and then to the CP and DIR inputs of our microstep driver, as seen in Figure 4. Attaching to the oscilloscope will give us the exact frequency output of the PWM lines, since if we simply attached it to the microstep driver itse lf we’d be guessing based on the speed of the door opening and closing. After we’re able to get an output signal reading of 800 HZ from Pins 12 and 17, we’ll switch them over to the configuration of Figure 9.3.1.
Figure 9.3.1- Pin 12 (Left) and Pin 17 (Right) Configured to test PWM
While the oscilloscope allows us to verify the frequency of the PWM line, attaching it to the actual component to be driven by it lets us verify that the amplitude of the signal will be large enough to power the QJ-215 (which is the microstep driver). In Figure 9.3.1, we simply attach power directly to all of our components, since all we wish to test is the PWM capabilities of the ATmega328.
This allows us to remove any potential variables from debugging other than ones related to PWM. Also, while the ATmega328 technically has 6 PWM lines that we could test, since we only need two for our final configuration, we don’t need to test the others. If we do find that the above steps don’t work as expected, it may
- 49 -
be beneficial to attach the four other PWM lines (Pins 5, 11, 15, and 16) in the manner shown above to see if the problem lies with Pins 12 and 17.
After testing the individual PWM lines, we tested to make sure both can be run simultaneously, which is required to be able to both open the door then close it later. To do this, we attached the ATmega328 to the QJ-215 as shown in Figure
9.3.2. Then program our microcontroller to pulse both Pin 12 and Pin 17 at 800
HZ. This should result in the QJ-215 opening the door of our IBS module (as seen in the background of COLLIDE-
3 section). Hopefully this will work, since it’s unclear whether the ATmega328 has the capability to provide a PWM signal to two pins at once. We will then apply the pulse to only Pin 12, which should close the door on the IBS.
Figure 9.3.2-Pin 12 and Pin 17 configured simultaneously to allow bi-directional door control
If it ends up that the capabilities of the ATmega328 do not include providing multiple PWM lines at the same time, some workaround will be found. Most likely this would involve a relay that would only allow the output from Pin 12 to reach both CP and DIR on the QJ-215 at designated times, with the relay being powered by one of the I/O pins on the microcontroller. This is shown in Figure
9.3.3.
- 50 -
Figure 9.3.3-Pin 12 and Pin 13 configured to a relay
Testing for this would then resume in the same manner as Figure 5. We had Pin
13 configured to close the relay connection during the door opening stage, and open the relay connection when the door then needs to close. This would be a low-then-high configuration if the relay is of the NC (normally closed, as pictured in Figure 6) variety, or high-then-low if of the NO (normally open) variety.
9.4 Testing of the Relays
An important part of our microcontroller board is the relays, since the
ATmega328 only sends 5 volts as an output and many of our components require more than twice that to activate. DC to DC converters won’t work for this application, since the microcontroller can only send around 5mA out on any individual line. This should be, however, plenty to activate a relay, which would then allow the required voltage to pass through it and go through the target component. To test that the relays operate in the manner we predict, we hooked them up to one of our LED arrays as seen in Figure 9.4.1:
- 51 -
Figure 9.4.1-ATmega328 activating LED array through a relay (Left), Visual representation of array (Right)
As seen in the figure, Pin 14 (one of the I/O pins) was used to drive the relays.
This is purely arbitrary. The reason for choosing an LED array is for the obvious visual indicator of how well the relay is working. To test these, we programed the
ATmega328 to switch Pin 14 from logic ON to logic OFF with periods of 5-10 seconds in between. Depending on whether the relay is normally open or normally closed, we should see the LED array switching between an on and off state. For the sake of our testing, let’s imagine we have chosen normally open relays, so Pin 14 being powered would result in the lighting of the LED array. If the LED array simply stays off the whole time, then our relay is not sensitive enough, and has a turn on current higher than what the microcontroller is capable of outputting. If the LEDs stay on for the duration of the program, then our relay is far too sensitive, reading even the off state of the microcontroller as enough to allow current to pass through.
The third case is where our reasoning behind using an LED array for testing proves to be more than just random component choice. In the case that the relay is only capable of passing part of the 12 volt supply, the LEDs will still turn on, but they will appear dim. If we had used a different component for our tests, we might have read half of the current passing through the output of the relay as either an on component or an off component, and reached the wrong conclusion about the relay. In this case, our relay has the correct sensitivity (assuming it dimly turns on and off at the right intervals), but is incapable of passing through the current provided by the 12 volt source. In this case, we would either have to upgrade to a better relay, or in a case where we have a very large current that had to pass through, we would have to switch from a solid-state relay to a mechanical relay. After switching to a new relay, we would run the above tests again, hopefully with more favorable results.
- 52 -
9.5 Testing of the input from the accelerometer
We had to ensure that the ATmega328 is capable of outputting everything necessary properly, so far, we have yet to put its ability to read a pin as an input to the test yet. To do this, we first created a very basic circuit to provide power to one of the pins and see if the ATmega328 recognizes the change in state, and then once we confirmd the success of that we took it a step further and make sure it can take in readings from different components.
The first stage of this testing is very basic and straightforward, and it is unlikely to operate in any way other than predicted. Still, this simple test is an important variable to remove from debugging more complex steps down the line. In terms of software, we wrote a program in the Arduino environment to constantly read in the state of Pin 18 (Digital Pin 12) and output the results to the screen, and then download the program onto the chip. On the hardware side, we had the
ATmega328 hooked up to the computer through the FT232 (so that it can constantly send its readout to the computer), and have a switch separating Pin
18 from a 5 volt source, as shown in Figure 9.5.1:
Figure 9.5.1- ATmega328 with controllable 5V to Pin 18 (Pin 22 is a GND pin)
With the above setup, we flipped the switch on and off, which should result in a display on the computer reading from 0 to 1. If this happens, then we have confirmed that our microcontroller works properly reading in a steady 5 volt signal as a high value. At this point, we continued to lower the voltage source to see what value the ATmega328 consistently reads as high, what values it tends to fluctuate for, and what values it reads as logic 0. It most likely requires 3.3 volts to read logic 1 on the screen consistently.
- 53 -
Next, since we know the microcontroller can read in a signal properly, we must confirm that it can read in a signal from an outside component, not just a power source. Specifically, we should ensure that it can read a signal from our accelerometer, the H48C. Since the Zero G flag is the only condition we ever care about being able to read from, we set up the microcontroller to take an input from Pin 4 (Zero G) of the H48C and turn it into something we can identify.
During this stage of testing, we assumed the tests found in the accelerometer testing portion of this paper were successful, so we know any problems encountered are on the side of the microcontroller. Of course, before we can get any sort of useful reading from the Zero G pin, we need a way to put the H48C in an environment which would activate the pin. We can achieve this by having the chip enter free fall. For obvious reasons, we don’t want to just be dropping our project in an uncontrolled environment. Therefore, for these tests we utilized Dr.
Colwell’s Drop Tower, as seen in Figure 9.5.2:
Figure 9.5.2- (Left) Full View (Right) Top View
The Drop Tower is often used when we have experiments that can be completed in very brief periods of microgravity (aka Zero G, free fall). The usable dropping distance within the Drop Tower is 12 feet, with multiple layers of memory foam at the base to absorb the impact shock of anything dropped. These 12 feet results in around .8 seconds of usable free fall time. While this may not seem like much, it is more than plenty for our purposes, since the H48C can reliably tell the difference between noise and true free fall in about a 100 millisecond period. It does this by checking all three axes against their threshold values and outputting
- 54 -
a Zero G flag any time all three of them are below their thresholds. This check occurs once every .4 milliseconds. False flags can obviously occur due to noise or vibrations, so we must account for this. We do this strictly on the software side.
In terms of hardware, we connected the ATmega328 to the H48C as shown in
Figure 9.5.3. This is mostly the same setup as seen in the design portion of this paper, except now with a mobile way to test the Zero G flag readout, which is the
LED across Pin 18 on the microcontroller. This will be a visual representation of our microcontroller reaching a point in which the H48C has convinced it that we are in a Zero G environment. It may prove unnecessary to have some of the accelerometers pins hooked up to our ATmega328, since we only care about the output of Pin 4, so once our test is successfully run with everything attached, we
“trial and error” another set of runs, in which we disconnect one pin at a time and see if we still get favorable results. Likely candidates for not needing a connection are Pin 2 (DIO) and Pin 5 (Chip Select, active-low).
Figure 9.5.3- Zero G flag testing setup
In terms of software, we programmed the microcontroller through the Arduino interface to constantly take in readings from Pin 4, likely one reading every .4 milliseconds to match the sampling rate of the H48C. Once it reads a high signal, it will begin a counter and continue to check the input from Pin 4, incrementing the counter every time Pin 4 reads high. If the input every goes low, the microcontroller will assume it was a false reading and reset the counter to zero.
However, if the counter reads a high signal enough consecutive times (enough to reach 100 milliseconds of sam pling, which at .4 milliseconds between each reading would be 250 times), it will consider itself in Zero G, stop the counter, and set Pin 18 high. Therefore, when we drop the
- 55 -
accelerometer/microcontroller/LED combo from the top of the Drop Tower, by the bottom the LED should be turned on.
The LED should also refrain from turning on prematurely if we shake it. If it does turn on prematurely, we adjusted the number that the counter must reach before accepting Zero G until we feel confident it will never be falsely triggered. Since on our flight we expect to have two full minutes of Zero G, with only around one minute worth of experiment time, we are likely to set a very high counter number to ensure no false firings. However, for the purposes of testing (since we only have .8 seconds to play with), we simply tested the theory of setting the flag with error prevention.
10.0 Windows Board
In addition to the microcontroller that we built, we also have a primary microcontroller. It must be compatible and sustainable for several connected devices, including the camera, the solid-state drive, and the AtMega micro-controller.
COLLIDE 3 will be initially ran with a consumer type camera and later with a high-end industrial camera. Dr. Colwell has several high-end cameras at his disposal so the goal was to choose a board that would be compatible to as many cameras as possible. Luckily we found one board has been compatible with all three cameras. EPIA branded P820-12 mainboard has a VIA Nano ULV processor (1.2GHz) which supports a Windows XP (as well as other versions of
Windows and Linux) install. All three cameras have software that is only compatible to Windows XP and later versions, thus making a Windows based board a requirement. Since each camera’s software was installed it introduces the opportunity to create custom scripts and batch files to automatically run their software when needed by the experiment.
Due to the intense data stream coming down from the camera a board would have to be able to support the standard interface for a solid-state drive and the resources necessary to sustain the data transfer. The P820 has a SATA II connector. A SATA II connection can sustain up to 3.0 Gb/s (or 300 MB/s).
Even with the highest resolution camera, after all settings (fps, resolution) have been made the transfer rate should only peak at no more than 110 MB/s; thus this will serve as more than needed to capture all images without having any issues. In addition to having a SATA II interface the P820 has been upgraded to include 2 Gigabytes of DDR2 RAM. Not only will this help in the data transfers but also with multitasking the camera software as well as the AtMega software
(Arduino 1.0) and all necessary batch files and scripts written to automate the experiment.
Writing to the AtMega microprocessor is most utilized through the Arduino 1.0 software program. It is also compatible to Windows XP and later versions. The
GUI of the Arduino 1.0 program is very user friendly and maintains a simple design interface. It is not resource hungry and is required only to write the
- 56 -
experiment procedure to the AtMega328. A batch file or script will be called when needed to start the program loaded with code where certain values have been loaded from the text file that was being used in connection with the CFA-
735 (user input module). Again, since the board is Windows XP based a simple batch file or script can load the program with said file and execute the “Upload” button to write the code to the AtMega328.
Additional required components of the primary micro-controller included hardware interfaces for current and future peripherals. To support this the P820 sports two 2.0 USB ports (with the ability to add four more), a VGA interface, a
HDMI interface, and a gigabit ethernet interface (see Figure 9 below). The gigabit Ethernet port will host the camera and the USB ports will be used for the user input module and to connect the AtMega micro-controller through a serialto-USB breakout board. With the current setup there is only a one-way communication going from the P820 to the AtMega micro-controller, however if in the future the experiment calls for the micro-controllers to communicate back and forth with each other the P820 includes Watchdog timer; which is a software to help monitor and sustain stable communication between two micro-controllers.
Figure 10.1 EPIA branded P820-12.
A final yet obvious requirement for the primary micro-controller is size. The
COLLIDE-3 will house many parts and thus space will be limited. Fortunately the
P820 has a Pico-
ITX form factor and is only 3.5” x 3.5” (see Figure 10 below).
The size is incredibly small considering the software and hardware support from the board.
- 57 -
11.0 Storage Space
11.1 Solid State Drives
The camera is shooting images at three hundred frames per second. The resolution is approximately three hundred and eighty-five by three hundred and eighty-five. The combination of these factors will require a storage device that possesses the ability to store a great amount of data in minimal time.
Considering speed as a requirement we looked at several different types of storage capabilities currently available on the public market. Off the top of our head the possible solutions we came up with are solid-state drives, universal serial bus flash drives (thumb drives), and possibly memory cards, however we did not include mechanical hard disk drives as an option.
We ruled out mechanical hard disk drives because of several issues we would most likely run into when building the Collider-3. One such issue would be the vibration test that all components of the Collider-3 will have to go through and pass. All mechanical hard drives are constructed using spinning disks and other moving parts, making them more sensitive to physical damage than their competitors and thus most likely would cause the hard drive to fail such a test.
Another possible issue could come up later on in the experiment would be ones concerning heat. Mechanical hard disk drives are known to produce the most amount of heat (due to the spinning disks reading and writing to and from memory) out of the current most popular methods for memory storage. Since the
Collider-3 will be going up in space and entering orbit we did not want any additional, unnecessary, and avoidable heat coming from any of our parts internally. Lastly, of all possible memory storage devices mechanical hard disk drives take up the most space. If we decide with an internal hard disk drive then we have to include an additional bracket with shock absorbing capabilities to minimize the impact of the experiment on the hard disk. Since we are all computer engineers and not mechanical this did not bode well with us.
Mechanical hard disks do have their advantages, such as very cheap memory
(~$.50 per gig) and widely available from many different manufacturers but we felt the negatives far outweighed the positives in making this decision.
At first thought solid state drives was our first choice and for many good reasons, one being the speed of transferring data from the camera to the storage device.
When looking at reading and writing speeds amongst consumer options for memory storage nothing can compare to solid state drives. The two solid state hard drives we found to be strong possibilities for our project are the Intel 320
Series (model no. SSDSA2CW120G3K5) and the OCZ Vertex 3 (model no.
VTX3-25SAT3-120G). One immediate similarity between both is the internal form factor. After researching around for both internal and external we found the
- 58 -
internal solid state hard drives to be in more of abundance, giving us more options to find the best one available.
Brand Intel 320 Series OCZ Vertex 3
Model #
Series
Device Type
Used For
Form Factor
SSDSA2CW120G3K5
320 SERIES
Internal Solid State
Drive
Consumer
2.5“
VTX3-25SAT3-120G
VERTEX 3
Internal Solid State
Drive
Consumer
2.5”
Capacity
Interface
120 GB
SATA II
120 GB
SATA III
Price
(NewEgg.com)
$190.99
(includes tax and s/h)
Table 11.1.1 Shows the comparison of the two solid state drives
$199.99
(includes tax and s/h)
Write speed is important to our project because the entire experiment will be held in micro-gravity and last only approximately two minutes give or a take a few seconds. Both solid state drives outperform many if not all current mechanical hard drives. The Intel 320 Series solid state drive uses Serial Advanced
Technology Attachment (SATA) II interface. This limits transfer rates to three gigabits per second (3.0 Gbit/s) or in a more usable form three hundred megabytes per second (300 MB/s). Even with this transfer cap the Intel 320
Series solid state drive will write up to a hundred and thirty megabytes per second (130 MB/s). On the other hand the OCZ Vertex 3 solid state drive has two different maximum write speeds dependent on the interface they are connected by. If using SATA II they can write up to two hundred and sixty megabytes per second (260 MB/s), however if the solid state drive is connected using SATA III then the maximum write speed increases to five hundred megabytes per second (500 MB/s). Both solid state drives provide impressive write speeds but since the OCZ Vertex 3 uses the latest SATA technology (SATA
III) it is able to write at almost four times the rate of the Intel 320 Series solid state drive. The reading speeds are irrelevant because no component inside the
Collider-3 will be reading from the solid state drive. It will not be until the
Collider-3 is back down on earth with researchers and scientists that the images and data will need to be read, however they are vital when comparing solid state drives for overall performance. The maximum read time for the Intel 320 series is two hundred and seventy megabytes per second (270 MB/s), again that is using the SATA II interface, and the maximum read time for the OCZ Vertex 3 is five hundred and fifty megabytes per second (550 MB/s), that is using the SATA
III interface.
- 59 -
Brand Intel 320 Series
Read Speed (SATA II 3Gbps) up to 270 MB/s
OCZ Vertex 3 up to 280 MB/s
Read Speed (SATA III 6Gbps) N/A
Write Speed (SATA II 3Gbps) up to 130 MB/s
Write Speed (SATA III 6Gbps) N/A
MTBF 1,2000,000 Hours up to 550 MB/s up to 260 MB/s up to 500 MB/s
2,000,000 Hours
Table 11.1.2 Shows the comparison of the two solid state drives in term of read and write speeds
The next factor to consider is passing the vibration test each component (and eventually the entire project as a whole) will be put through. Vibration tests are measured both in units of gravitational acceleration (g) and frequency (Hz). Then there are two modes a solid state drive will be tested in: operating and nonoperating. In operational mode the Intel 320 Series solid state drive was able to withstand 2.17 G’s or 700 Hz of vibration. In non-operational mode the Intel 320
Series solid state drive was able to withstand 3.13 G’s or 800Hz of vibration.
Brand Intel 320 Series OCZ Vertex 3
Shock Resistance 1,500G @ .5ms 1,500G @ .5ms
Vibration Resistance
(Operating)
2.17G
5-700HZ
2.17G
5-700HZ
Vibration Resistance
(Non-Operating)
Temperature
(Operating)
Temperature
(Non-Operating)
3.13G
5-800Hz
0-70
Celsius
(-55)-95
Celsius
3.13G
5-800Hz
0-70
Celsius
(-55)-95
Celsius
Table 11.1.3 Shows the comparison of the two solid state drives in terms of environmental stability.
The Collider-3 will be equipped to a rocket for the duration of the experiment but it has to be powered by its own battery supply, because of this we must carefully observe the power consumption of our products to assure individually nor as a collaborative group will they deplete the entire power source before the experiment was able to successfully complete. Knowing precisely how great the effect of the temperature will have on our batteries isn’t realistically possible; therefore we play the better safe than sorry card and try to keep our components as conservative as we can in terms of power use. Both solid state drives’ power consumption was recorded under two states: idle and active. The Intel 320
Series solid state drive consumed only one hundred micro-watts (100 mW) while in the idle state and increased a measly fifty more micro-watts in the active state for a total of one hundred and fifty microwatts (150 mW). The Intel 320 Series’
- 60 -
competitor, the OCZ Vertex 3, could not even stay in the zip-code as the Intel’s units of measurement. The OCZ Vertex 3 had a one point sixty-five watt usage while in the idle state (1.65 W) and nearly doubled that number in the active state where its power consumption was maintained at three watts (3 W).
Brand Intel 320 Series OCZ Vertex 3
Warranty (Parts) 5 years 3 years
Warranty (Labor) 5 years
Warranty Disclaimer Limited Replacement
Only
3 years
Limited Replacement
Only
Table 11.1.4 Shows the comparison of the two solid state drives in terms of warranty.
Unfortunately, in the beginning of their development, solid states had issues of being DOA (Dead On Arrival) devices. Additionally, either of the devices could fail to live up to its vibration and shock resistance and could fail while being submitted to the mandatory vibration test we have to evaluate them to. The good news here is that both solid state drives, the Intel 320 Series and the OCZ Vertex
3, come with a five year warranty (Intel 320 Series) and a three year warranty
(OCZ Vertex 3). That more than covers our experiment for the next six months.
Brand
Power Consumption
(Idle)
Power Consumption
(Active)
Intel 320 Series
100 mW
150 mW
OCZ Vertex 3
1.65 W
3 W
Table 11.1.5 Shows the comparison of the two solid state drives in terms of power consumptions.
Both solid state drives offer great capabilities based on speed, shock and vibration resistance and manufacturer warranty. The OCZ Vertex 3 has the ability to connect via SATA II or SATA III interface and while the Intel 320 Series is limited to only SATA II, which has a maximum throughput of three gigabits per second and SATA III has a six gigabit per second maximum throughput. OCZ’s
Vertex 3 beats Intel’s 320 Series when using a SATA II interface and more than doubles its speeds when the Vertex 3 is connected using SATA III. The Vertex 3 outperforms the 320 Series in almost every technical aspect except power consumption. Depending on what power supply we choose to implement in the
Collide-3 could determine which solid state drive we have the ability to use.
- 61 -
11.2 USB Flash Drive
Universal Serial Bus (USB) Flash Drives have the storage capacity of most solid state drives but take up much less space. They also use a much more common interface (either USB 2.0 or USB 3.0) which makes it a more flexible option when considering the other components for building the Collide-3 AVM; for example: if we went with a microcontroller implementing a USB interface will be easier than a SATA III interface. Another option would be using a gumstix to act as a middle man between microcontroller and the camera. We would have used the gumstix to handle the data transfers of images to the storage device and the benefit here is almost all gumstix come with several USB ports already installed. An additional benefit with going with a USB flash drive for our data storage is not having to worry about power supply since the USB flash drive will draw its power from the microcontroller board. This eases the worry about power consumption for the rest of our components.
Three USB flash drives available that seemed as potential fitters are: Imation’s
64 GB Pocket Pro, Mushkin’s Enhanced Ventrua Pro (64 GB), and Patriot’s
Supersonic Magnum (64 GB). All three USB flash drives use USB 3.0 interface and are cheaper than the solid state drives previously mentioned. Each USB flash drive has its own set of features that make it unique from the others, so despite the basic form and functuality there are extra capabilities the manufacturers have built in to give each one an edge above the next.
Brand Imation Mushkin Enhanced Patriot
Series Pocket Pro Ventura Pro Supersonic Magnum
Model #
Capacity
Interface
28068
64 GB
3.0
MKNUFDVP64GB
64 GB
3.0
PEF64GSMNUSB
64 GB
3.0
Price $119.99 $114.99 $129.99
Table 11.2.1 Shows the comparison of the three USB flash drives in terms of price and model.
Using a USB flash drive does provide us with some benefits that solid state drives do not, however it must be able to keep up with the data transfer rate we need from camera to storage space. The three USB flash drives being mentioned have some of the best read and write rates available for a USB 3.0 interface, but as with the solid state drives, the write speeds are far more important than the read speeds since we are concerned with keeping up with the data output of the camera. The Patriot Supersonic Magnum comes out on top with a write rate of one hundred and twenty megabits per second (120 MB/s).
Imation’s Pocket Pro came in second with a write speed of seventy-five megabits
- 62 -
per second (75 MB/s) and finally the Mushkin Enhanced Ventura Pro has a write speed of seventy megabits per second (70 MB/s). The Mushkin Enhanced
Ventura Pro and Patriot Supersonic Magnum have made their data transfers a bit faster by increasing the number of channels available for transferring data.
The Mushkin Enhanced has a quad-channel built into its USB flash drive and the
Patriot Supersonic Magnum has an eight-channel architect.
Brand
Series
Imation
Pocket Pro
Mushkin Enhanced Patriot
Ventura Pro Supersonic magnum
Read (in MB/s) 120
Write (in MB/s) 75
120
70
200
120
# of Channels n/a 4 8
Table 11.2.2 Shows the comparison of the three USB flash drives in terms of their read and write speeds.
Each USB flash drive comes with extra features that could help use, shall we choose to go with that particular device for data storage. The Mushkin Enhanced
Ventura Pro and Patriot Supersonic Magnum each have aluminum housing for added durability and shock resistance (the vibration resistance is unknown however we are presuming the device should be able to withstand such a test since it USB flash drives have no moving parts). These two flash drives also are backwards compatible to USB 2.0 interface, which could come in handy if for any reason the microcontroller or gumstix we implement has a USB 2.0 interface. All
USB flash drives come with standard warranties of one year full replacement.
Brand
Series
Imation
Pocket Pro n/a
Mushkin Enhanced Patriot
Ventura Pro
Yes
Supersonic
Magnum
Yes Backwards compatibility
(2.0)
Housing Plastic Aluminum Aluminum
Shock Resitance n/a
OS
Compatibility
Windows (7,
Vista, XP, 2000),
Linux Ubuntu 10.4
Cache n/a n/a
Windows (7, Vista,
XP) Linux
786K SRAM
Warranty 1 year 1 year
Table 11.2.3 Shows the comparison of the three USB flash drives.
15G n/a n/a
1 year
- 63 -
11.3 Flash Memory Cards
The final option we thought of to use as our storage space for storing images is a flash memory card. Flash memory cards are very small in comparison to solid state drives and use very little power to maintain; additionally they take up little room. Flash memory cards have come a long way in capacity, read and write speeds and price. The flash memory cards we looked at are available at retail stores to purchase (no waiting time for shipping).
The first flash memory card is a SanDisk Extreme Pro of size sixteen gigabits (16
GB). The Extreme Pro series by SanDisk is their fastest read and write memory cards to date. The second memory card is a Lexar Professional of capacity sixteen gigabits (16 GB). Lexar’s Professional series is also their top of the line memory cards with the best read and write speeds to date. Finally there is the
Transcend Extreme Plus of capacity sixteen gigabits (16 GB). This card by
Transcend is of the same speed as the others as well as memory capacity.
Brand SanDisk Lexar Transcend
Series
Model #
Extreme Pro
SDCFXP-016G-A91
Professional
LCF8GBCRBNA600
Extreme Plus
TS16GCF600
Capacity
Memory Type
16 GB
Compact Flash
16 GB
Compact Flash
16 GB
Compact
Flash
$69.99 Price $99.99 $76.24
Table 11.3.1 Shows the comparison of the three flash memory cards for price and model.
Read and write speeds on all three flash memory cards reach up to ninety megabits per second (90 MB/s). This just makes the minimal speed to compliment the camera’s transfer rate. Other concerns about being able to pass the vibration test are negligible since the memory cards are very small and contain no moving parts. They can withstand as much as the components can if not more. Each memory card can withstand a temperature range from negative twenty-five degrees Celsius to eighty-five degrees Celsius (-25C – 85C). The
Lexar Professional memory card comes with professional tech service available over the phone. The SanDisk Extreme Pro used silicon as a sealant to prevent any erosion due to humidity. Transcend’s Extreme Plus has a built-in ECC
Technology for detecting and correcting errors. All three flash memory cards come with a lifetime warranty by the manufacturer.
- 64 -
Brand SanDisk
Series Extreme Pro
Temp Range (in C) -25
– 85
Weight
Read Speed
Write Speeds
Warranty
<12 g
70 MB/s
90MB/s
Lifetime
Lexar
Professional
-25
– 85
<12 g
70 MB/s
90MB/s
Lifetime
Table 11.3.2 Shows the comparison of the three flash memory cards specs.
11.4 Final Comparison
Transcend
Extreme Plus
-25
– 85
<12 g
70 MB/s
90MB/s
Lifetime
When looking at all options (solid state drives, USB flash drives, flash memory cards) we first weighed certain features, such as read and write speeds, with a higher priority than others. Then we began comparing each type against the others before deducing the one product we will be using. There is no question that solid state drives have the best read and write speeds out of the three and since a high read and write speed will help us avoid any software problems when storing the images and handling the data transfers we gave this the top priority.
Size and power consumption were second and third in the priority list however these are more of hardware issues which are much easier to resolve than software issues (since the container for the Collide-3 will be large enough to keep us worry free from these concerns). Here is a table of the top three choices.
Brand OCZ Patriot SanDisk
Series VERTEX 3 Supersonic Magnum Extreme Pro
Model # VTX3-25SAT3-120G PEF64GSMNUSB SDCFXP-016G-A91
Capacity 120 GB 64 GB 16 GB
550 MB/s 200 MB/s 70 MB/s Read
Speed
Write
Speed
500 MB/s 120 MB/s 90 MB/s
Price $199.99 $129.99 $99.99
Table 11.4.1 Shows the final comparison of the three different options for storage.
All three choices meet the minimal write speeds we wanted for the Collide-3, however the OCZ Vertex 3 is more than five times that of the SanDisk and four times that of the Patriot Supersonic Magnum. For the duration for experiment we are roughly expecting it to last anywhere from thirty seconds to possibly two minutes. From previous experiments and calculated guesses we think the
- 65 -
camera will need to write about one-hundred megabits per second (this was calculated using the current shooting conditions such as frames per second and resolution). The SanDisk as well as the Patriot will suffice for this particular experiment however the OCZ provides flexibility to increase resolution or frames per second and still having the capacity to store the images on it. The most expensive components (LED’s, Camera) will already be provided to us without cost so the price difference is not that big of a factor.
All in all the OCZ Vertex 3 solid state drive is the best product to use as our storage device. Its combination of speed, capacity, and resistance (shock, temperature, vibration) make it an easy pick to carry out the task as well as make our job easier during integration and testing (for example: we will not have to program some kind of buffer to keep up with the camera’s fast write speeds).
The OCZ Vertex 3 easily handles the experiment under current conditions and still has the flexibility to be implemented into future renditions.
12.0 Camera Research
12.1 Overview
While the microcontroller, accelerometer, and display module are essential for the functionality of our AVM, the camera (and the hard drive it stores data to) is the component that actually allows us to recover scientific information from the series of events that our experiment creates. Without an optimal camera,
COLLIDE3 could execute perfectly and we’d still be left with nothing. Therefore, we must make sure that we have a camera optimally suited for our needs; a frame rate too slow will miss important collisions occurring between dust particles. A resolution too unrefined will not be able to differentiate one dust particle from two. Nothing will matter if the camera is too fragile to survive our flights, or if the design of the casing is too big to install, or worse yet has no way to install it.
Obviously, we wanted to leave as much of COLLIDE-3 alone as we can, and while it already had a camera chosen for it at one point, we are presented with an opportunity to make sure the one we moved forward with is optimal. Originally, the company COLLIDE-3 was designed to fly with provided us with a camera, leaving the choice out of our hands. The camera did well enough for what was needed, but since the camera still belongs to Blue Origin, we will need to be purchasing a camera no matter what to move forward with COLLIDE-3 and our
AVM. Therefore, while it made sense to leave all other components of COLLIDE-
3 alone as they were, we should have made sure there aren’t any better choices of cameras that will integrate better with our new AVM.
- 66 -
12.2 Camera Requirements
As with all components in our AVM, size, weight, and cost should be kept to a minimum. When choosing a camera, some method of mounting must be available on the frame, whether it’s through screw holes or some sort of attachment bar. Frame rates must be in the 60-300 range, with 60 being achievable at the 1024x1024 resolution. In the past version of COLLIDE-3, the camera footage was recorded over an Ethernet line, so for simplicity any camera which is connected through Ethernet will be considered as having an advantage.
Power consumption, like weight and size, should be kept to a minimum, though slight differences in power usage are likely to be inconsequential. While a battery powered camera might seem like an ideal solution, we most likely tried to avoid them, since any delay in a flights launch might risk running past the expected life of the battery, leaving the experiment a failure. Finally, availability of software for controlling the camera was looked into.
As something unique to a senior design project that was used for untested research, we also implemented a camera quite unlike the others we looked into.
The last camera that will be mentioned was done so strictly for the earliest stages of our research with the COLLIDE-3 module, when the flights we place it on are still prone to failure.
13.0 Camera Choices
13.1 Prosilica GE 1050 by Allied Vision Technologies
The Prosilica GE 1050 was the original camera provided by Blue Origin for
COLLIDE-3 (as seen by their label on said camera). The GE stands for its
Gigabit Ethernet interface, which is how it transmits its video feed data to an external storage device. At 1024x1024 resolution, it records at 59 frames per second. It has a DC power requirement of anywhere from 5V to 24V, and will consume 5 watts of power at 12V DC. Shown in figure 13.1.1 is the camera mentioned.
- 67 -
Figure 13.1.1-Top and back view of Prosilica GE 1050
As for size, the Prosilica GE 1050 weighs in at 178 grams. It size is; 80mm in length, 51mm in width, and 39mm in height. This is including connectors, but excluding the lens. Also, since it is the model previously used in COLLIDE-3, we already have a baseplate machined to mount it to, as seen in figure 13.1.2, and we have had experience with it passing vibrations tests under such mounting conditions.
Figure 13.1.2-Camera base plate with color coded mounting holes
As for software, Allied Visions Technologies provides a wide range of software development kits for controlling their cameras and acquiring images. Their GigE
Vision provides the framework to transfer up to 1000 megabits per second over an Ethernet line. GigE Viewer is a free application to stream the cameras view onto a computer. They also provide all the drivers you could require to integrate a camera into a system. However, our experiences with the software for this camera thus far have been less than encouraging. In fact, in our lab we were never able to get the camera to actually record footage without the software Blue
Origin provided themselves. While obviously it is possible to set the camera up to
- 68 -
record footage onto a hard drive, it’s certainly not done in as user friendly of a manner as Allied Visions Technologies makes it out to be.
As for price, the quote provided by Allied Vision Technologies is for XX dollars.
While this is very reasonable in comparison with the other cameras we will consider using, it is actually the biggest drawback of staying with the Prosilica GE
1050 for our AVM, and is why we considered changing cameras in the first place.
While we currently have three of these cameras in our lab, none of them belong to us, so we will need to purchase one for the purposes of COLLIDE-3 any time it flies on a suborbital rocket not owned by Blue Origin (a.k.a most likely the next few suborbal rockets were considering). The other two cameras in consideration are, in fact, purchased and owned by Dr.Colwell for purposes of experiments in his lab. While it’s true that they are intended for other experiments, simply disconnecting them from one setup and attaching them to another is hardly a difficult task. So, in essence, depending on the lifespan of the COLLIDE-3 experiment, choosing to utilize a new camera might save the entire cost of the camera.
13.2 MotionBLITZ Cube2 by Mikrotron
The second camera we were considering for integration into COLLIDE-3 was the
Mikrotron MotionBLITZ Cube2, as seen in Figure 13.2.1. Currently, our lab utilizes this camera for our “Drop Tower” experiment, where we achieve roughly
.8 seconds of microgravity through dropping an experiment alongside a camera in a controlled, tower environment. The experiment is actually meant as a less thorough, in-lab version of COLLIDE-3, offering the same environment and collisions as COLLIDE-3, just at a much less duration as a tradeoff for being able to be performed right in the lab over and over again. Therefore, since the camera is intended for an experiment mirroring COLLIDE-3, it makes sense to consider it for our needs.
Figure 13.2.1-Mikrotron MotionBLITZ Cube2 Front and Side View
- 69 -
In terms of specs, the recording speeds are quite impressive. At 1280x1024 resolution, the MotionBLITZ Cube2 can record at up to 500 frames per second, while at reduced resolutions it’s capable of achieving a staggering 45,000 frames per second. Truly this sort of frame rate would ensure absolutely every element of a particle collision was able to be witnessed. Its power input is either 10.5 to
24 volts DC from an external source, or it can utilize its internal battery for up to
30 minutes of recording or an hour of standby. While the internal battery would not be used as the primary power source on a flight, it still would provide a valuable backup in case power was lost after the experiment was set into motion.
Obviously, however, if power was lost before the rest of COLLIDE-3 was able to perform its functions, the camera still recording would hardly be useful. Its increased frame rate does come with a price in power consumption compared to the Prosilica GE 1050. At full resolution/frame rate (1280x1024, 500fps) it draws
15 watts of power during its continuous recording stage.
While the larger frame rates and resolutions are a definite plus for utilizing the
MotionBLITZ Cube2 over the original Prosilica GE 1050, its size and weight are also quite a bit larger. The camera size is; 94mm width, 70mm height, and
110mm length. It weighs in at 980 grams without its lens, but with its battery set.
As is visible in Figure 3, the camera does come with pre-machined through holes for mounting. The camera actually does physically fit on our current base plate designed for the Prosilica GE 1050, though obviously holes would have to be drilled in new locations to correspond with their placement on the MotionBLITZ
Cube2.
Its software, MotionBLITZ Director, is described as being user friendly, and we have had relative success with it in the past. Files generated from the camera travel over the Gigabit Ethernet LAN, and are stored as either standard BMP or
AVI-file formats. These files can be played back at 30-100fps at 512x512 resolution, depending on the PC they are replayed on. The unique ImageBLITZ feature offers a multitude of options for recording of data, from different recording trigger mechanisms to intelligently deciding a frame rate based on the preselected region of interest. The camera records onto a FIFO buffer, which is 4 gigabytes, and based on your trigger choice, will fill the buffer with a set number of frames and fill the rest with post-trigger recordings. Triggers can include:
1. The closing of the camera’s trigger switch
2. A trigger signal
3. Usage of ImageBLITZ
4. Clicking the “Stop” button in the MotionBLITZ software interface
Options 1, 3, and 4 are unlikely to be used. Option 1 requires physical access to the trigger switch seen in the side view of Figure 3. While future iterations of
COLLIDE-3 may occur on manned suborbital flights, this is certainly not an optimal solution. Option 3 is actually an innovative idea that could prove effective
- 70 -
if op tion 2 didn’t integrate so well into our design. Basically, ImageBLITZ watches a certain part of the image. If enough of the image changes, it sends a trigger.
Values ImageBLITZ records and compares are pixel value difference and relative size. This could be either the lights turning on/off in our experiment, or the projectile launching into the payload. If we were unsure about the timing of our experiment, this would certainly prove to be a great choice, but due to the nature of COLLIDE-3, it would be a complex solution for a simple problem. Finally, option 4 is also irrelevant, since we will not have the software interface running during the recording stage of the experiment. This leaves option two, which is electronically sending a trigger to the camera at a predetermined time. See figure
13.2.2 MotionBLITZ Cube2 Pin Layout
Figure 13.2.-MotionBLITZ Cube2 Pin Layout for Trigger Inputs, with physical connector representation
The connector in the top right of Figure 4 would connect to the eight pin female equivalent as seen in the side view of Figure 3. Pin 7 would be connected to an output from our microcontroller, to be activated at a predetermined time in the program based on the rest of the events occurring within COLLIDE-3. The minimum diode current for the trigger to read an active signal is 5mA, so the microcontroller must be able to provide this. These triggers can be applied to either the cameras non-circular recording mode, or its circular recording mode.
- 71 -
In non-circular mode, the camera can fill up the buffer in one of three ways:
1. No Trigger
2. Recording while trigger is active
3. Fixed number of frames per trigger (burst)
Option 1 allows the buffer to be filled when no trigger is present. Option two only allows recording to occur when the trigger value is high (the active state of the trigger is what the camera will read from; it is not edge-triggered). Option three is edge based. When it reads a rising edge from pin 7, it will fill the buffer with 1 to
1022 frames, and then wait for the next positive edge.
In circular mode, the oldest recorded frame will constantly be replaced with the newest once the buffer is full. For example, if the buffer can hold 1000 frames, once frame 1000 is reached, frame 1001 will replace frame 1, frame 1002 will replace frame 2, and so on. Here, activating the trigger (which can be read by either the rising or falling edge, the state is not the essential part) indicates which frames should be kept and which can be overwritten. The number of frames can be between 1 and 4049. To clarify, if a value of 1000 is chosen on a rising edge trigger, any time pin 7 reads as a rising edge, the last 1000 frames of the buffer will be kept, and the rest of the frame buffer will be filled up with frames. Instead of a concrete number of frames, the value can also be a percent of the total buffer. For our experiment, it seems more likely that we will choose to go with the non-circular mode. While it would be possible to have the camera constantly recording, then only save the very last thirty seconds after the experiment has run its course (which would be the part where the actual data occurs), this would be a very power inefficient method, and since through the microcontroller we have a perfect way to start the non-circular mode at the precise moment, it is hard to make a good argument for implementing circular mode. Also to note, circular mode can be set to begin recording immediately when the camera is powered.
After a recording is completed (which occurs any time the buffer is completely filled), the camera can transfer the images either to an attached hard disk, or directly to an SD card in the camera. While an SD card can hold a fair amount of space compared to what we needed for our experiment, it does have drawbacks compared to writing to an external solid state drive. Most SD cards write at 30 megabytes per second, which equates to two and a half minutes to clear out the buffer onto the card. The images will also be written in the Mikrotron specific format, meaning it could only be shown on the MotionBLITZ software. This is not much of a downside, since any video playback software is sufficient for our needs. The upside of the SD cards is that we wouldn’t have to worry about the formatting of the files onto the external hard drive, or the implementation of the drive at all.
- 72 -
With all of the glowing features of the MotionBLITZ Cube2 in comparison to the
Prosilica GE 1050, it’s time to mention the potentially crippling drawback, depending on how the data storage of the camera works. For the MotionBLITZ
Cube2-M3, the recording time at 1280x1024 resolution 500 frames per second, is only 3.3 seconds. The minimum time we plan to record images for COLLIDE-3 is
30 seconds, nearly ten times that. This means that while the MotionBLITZ Cube2 is capable of blowing the frame rate of our original camera out of the water, we can’t actually use the functionality unless we can transfer the data from the buffer onto our hard drive at the same rate it is written into the buffer, and the camera mentions no capabilities of reading and writing simultaneously.
With some simple math, if we utilized the 60 frames per second the Prosilica GE
1050 can achieve at 1024x1024 resolution, the MotionBLITZ Cube2 should theoretically be able to record 27.5 seconds before the buffer is full, just slightly short of our goal. The MotionBLITZ Cube2-M6, however, boasts a recording time of 6.5 seconds at a 1280x1024 resolution at 500 frames per second.
Theoretically, this allowed us 108 frames per second while still reaching the 30 second mark, or 54 seconds at 60 frames per second. This is assuming, however, that the 3.3 and 6.5 seconds of recording scales up proportionally as our frame rate scales down. Mikrotron does state that longer recording times are achievable at reduced values, but they do not state the rate of increase being proportional, thus we would have to put a lot of hope in our logic holding true.
Thus, if we decide on the MotionBLITZ Cube2, we will have to choose between falling about 10% short of our recording time goal, or purchase the MotionBLITZ
Cube2-M6, negating the advantage that we originally sought by branching out to other types of cameras in the first place of not having to spend money on one.
The price of the quote received for the MotionBLITZ Cube2-M6 was XX dollars.
13.3 Mikrotron EoSens MC1362
Our final option (aside from the secondary camera we would be implementing in earlier iterations of COLLIDE-3, as mentioned earlier under camera requirements) is another high-speed camera from Mikrotron, the EoSens
MC1362, as seen in Figure 13.3.1. This is a camera designed to fly with our
PRIME experiment, which has flown on the Zero-G parabolic plane multiple times. The concept of the experiment is very similar, with the end goal being the recording of microgravity dust collisions. Therefore, since the experiment is similar to COLLIDE-3 and the camera is made by the same company as the very promising MotionBLITZ Cube2, we shall consider its merits to determine if it warrants redesigning COLLIDE-3 around it.
- 73 -
Figure 13.3.1-Mikrotron EoSens MC1362 Side and Back view
In terms of image capture capabilities, the Mikrotron EoSens MC1362 compares in the same region as the other Mikrotron camera, rather than in the Allied Vision
Technologies range. At a resolution of 1280x1024, the Mikrotron EoSens
MC1362 can record at 500 frames per second, exactly identical to the
MotionBLITZ Cube2. However, it claims to achieve a maximum of 120,000 frames per second at its lowest resolution, though such a speed is far beyond the needs of COLLIDE-3 or our AVM. A table of pre-set resolutions and outputs, as provided by the manufacturer, is shown in Figure 13.3.2. These frames will be recorded with 1024 gray levels, or 10 bits of resolution. To operate, the camera requires a DC supply voltage of 8 to 24 volts. While it boasts the same frame rate and resolution as the other Mikrotron camera, it only draws 5 watts of power, which is equivalent to the Allied Vision Technologies camera, or 1/3 that of the other Mikrotron. It does not have an internal battery, however.
Figure 13.3.2- Preset profiles for the Mikrotron EoSens MC1362
The Mikrotron EoSens MC1362 is not a very large camera. Its measurements are; 63mm base, 63mm height, and 47mm thickness (excluding lense). It weighs only 300 grams (also without the lense). While it does come with machined and threaded holes for mounting, it has far less of them than the other cameras,
- 74 -
meaning the stability and likeliness of passing vibrations tests is lowered.
However, since it is smaller and weighs less, it simply take less supports to achieve the same level of ruggedness as the other choices.
Something that immediately stands out and separates the Mikrotron EoSens
MC1362 from the other choices is that it does not have an Ethernet port. Rather, the camera utilizes Camera Link communication protocols over serial ports.
Available on the camera is both a base camera link configuration and full camera link configuration, as seen in the back view of Figure 5. With the full camera link, a data transfer rate of 680 megabytes per second (80 bits of data) can be achieved. This would mean that the entirety of the extra frames per second could be transferred to our external hard drive. There is difficulty in this, however, as the camera can only operate with a computer, not a hard drive, attached to it. For the iterations of COLLIDE-3 that remain as an unmanned experiment, the
Mikrotron EoSens MC1362 would be extraordinarily inefficient to implement.
However, eventually our suborbital research will occur on flights that have researchers, and thus laptops, aboard, where the Mikrotron EoSens MC1362 would make much more sense.
Another curious fact about the Mikrotron EoSens MC1362 is the requirements for running the software. The camera actually comes with a circuit board, seen in
Figure 13.3.3, than must be installed into the computer that will be handling the data fed into it. It becomes far less mysterious now to see why the Mikrotron
EoSens MC1362 can manage a capture rate of 120,000 frames per second. It is unclear if any laptop available on the market currently could even handle the addition of said circuit board into its hardware, leaving the selection of the
Mikrotron EoSens MC1362 for a suborbital flight mission less and less appealing.
Figure 13.3.3-Circuit Board required for Mikrotron EoSens MC 1362
- 75 -
13.4 GoPro HD Hero Naked
This camera is definitely the “odd one out” from the rest mentioned. It’s not regarded as a high speed camera, it’s not designed for scientific experiments
(actually, it’s designed as a helmet camera for snow boarders and other extreme sports people to record their feats
), and, most importantly, it’s not super high priced. Due to the nature of our experiments, which take place on experimental suborbital rockets, there is always the chance of a complete rocket failure, which would naturally result in the loss of our experiment. In the early stages of
COLLIDE3’s life, these threats are very real; in fact it was such a failure that lead to the need for the very AVM that we are creating. As such, Dr. Colwell has requested that our experiment be capable of being integrated with a camera that doesn’t cost $10,000 for the first few times it runs, just to minimize our losses in the case of a system failure on our ride. Therefore, while the GoPro HD Hero
Naked is not the camera that will be used in the final, polished and published version of COLLIDE-3, it will still play an important role in the life of COLLIDE-3 and our AVM. Shown below is the camer mentioned above in figure 13.4.1.
Figure 13.4.1-GoPro Hero Naked, front and mounted view
The specs of the GoPro HD Hero Naked are not actually terrible, and likely yield usable data from our experiment during its life. At a resolution of 720p and
1280x720, it can achieve 60 frames per second, our low end goal for a camera.
Its memory is stored internally aboard a 32 gigabyte SDHC video card. At the above resolution and frame rate, the SDHC card records up to 4 hours and 21 minutes of footage. To put things in perspective, if we do a quick comparison of the GoPro HD Hero Naked with the MotionBLITZ Cube2:
GoPro HD Hero Naked can record at 60 frames per second onto a 32 gigabyte card for 4 hours and 21 minutes
The MotionBLITZ Cube2 can record at 60 frames per second onto a 4 gigabyte card for 27.5 seconds. If the card was 32 gigabytes like that on the GoPro HD Hero Naked, it would record 220 seconds, or 3 minutes and
40 seconds
- 76 -
With some quick math, we see that the GoPro HD Hero Naked stores over 71 times more footage per megabyte of storage, so while it is capable of keeping up with the frame rate of the MotionBLITZ Cube2, we see that the video quality suffers dearly for it.
In terms of other specs, since the footage is all internally stored we don’t have to worry about interfacing it with a hard drive during flight. It utilized a USB 2.0 cord to attach to a PC, and is also compatible with Macs. In terms of power, its rechargeable lithium ion battery can last approximately two and a half hours, which while technically enough for a flight, is something we shouldn’t rely on due to possible delays in launches. However, there is an option for a “Battery
BacPac” addition which will double the battery life. Five hours of life should be considered sufficient for our needs. In terms of size, the GoPro HD Hero Naked measures in at: 42mm in height, 60mm in width, 30mm in depth. It weighs 94g with its (standard) battery attached, and 167g once housed.
In terms of mechanical considerations, its ruggedness is described as
“shockproof, bombproof, waterproof”. Since this camera is designed to fly down a mountain on skiers who are likely to take a tumble occasionally, it is probably the best suited camera among all of our choices for surviving any sort of turbulences a suborbital rocket might experience. In terms of attaching the camera to
COLLIDE3, while it’s not as nice as the tapped screw holes found in the scientific high speed cameras, it’s designed for mounting onto a helmet, so difficulties retrofitting it onto a baseplate are likely to be minimal. In terms of pricing, the GoPro HD Hero Naked is listed at a reasonable $200, with the extended battery pack being an additional $50. Since the camera is 50 times cheaper than its scientific counterparts, losing it in a critical rocket failure would be far less painful than any of our other choices.
13.5 Camera Choice Comparison
Now that we have thoroughly examined our choices for perhaps one of the most crucial components of our AVM, we must weigh the pros and cons of each and come to a conclusion. First, however, it will be stated that the GoPro HD Hero
Naked will not be part of the comparisons; since the preliminary flights it will be used on are not critical for the final results of our research, we do not need to examine it as in depth as the rest, and it is already a given that it will be utilized for our early tests. This section instead will be discussing the Prosilica GE 1050 by Allied Visions Technologies, the MotionBLITZ Cube2 by Mikrotron, and the
EoSens MC 1362 also by Mikrotron. The most important considerations are laid out in the table below:
- 77 -
Camera
Frames Per
Second
Connection
On board storage?
Size (mm)
Weight (grams)
Software
Power Consume
Mounting
GE 1050
60 FPS at
1024x1024
Cube2
500 FPS at
1280x1024
Gigabit Ethernet Gigabit Ethernet
No
80x51x39
178
Difficult
15W
Already integrated into
COLLIDE-3
Yes
94x70x110
980
Easy
30W
Needs modifications to base plate
EoSens
500 FPS at
1280x1024
Base/Full
Camera Link
No
63x63x47
300
Complex
15W
Potentially unstable once connected
Table 13.5.1 Shows important considerations for a camera choice.
Some additional things to note include:
We would have had to purchase the GE 1050, while we currently possess the other two
While the Cube2 records at 500 frames per second, if we wished to utilize the on-board storage we would only get use of 60 frames per second for
27.5 seconds
The EoSens could only be used for manned flights
Before considering any further, the most recent point stated will take the
Mikrotron EoSens MC 1362 out of our considerations for the time being. While it may prove to be an ideal candidate for our AVM to integrate to a year or so down the road, at the moment there are simply better choices that meet all of our requirements in a more efficient manner.
Between the Prosilica GE 1050 and the MotionBLITZ Cube2, the choice is not so easy. The Prosilica GE 1050 pulls way ahead in terms of size, weight, and power consumption, along with the fact that it has already been integrated into
COLLIDE-3 once and has proven to work well enough. The MotionBLITZ Cube2, however, is capable of recording far superior footage with onboard storage capabilities, and even an internal battery to make up for its increased power usage. We would also not have to purchase the camera, since the one we have in the lab was purchased by Dr. Colwell, instead of loaned to us by Blue Origin.
- 78 -
Perhaps an even bigger draw of the MotionBLITZ Cube2, however, is the amazing software provided for it by Mikrotron. It’s very intuitive in its use, it has ingenious options for how to trigger recordings, and more importantly we’ve actually had success in the past setting it up and getting data off of it without the use of software provided to us by Blue Origin. Also, as seen in Figure 4, the way to trigger recordings outside of the software is designed almost perfectly to work with microcontrollers.
One final consideration is due to the fact that we implemented our camera in such a way that the first stage of the design will utilize the GoPro HD Hero Naked with on board data storage. Since the MotionBLITZ Cube2 can be configured to use the same style of on board storage, we have decided to forsake the camera choice of Blue Origin and switch our design to work with the MotionBLITZ Cube2.
In the end, for our experiment, we decided to go with the StreamView-LR for the demonstration of our final product. The camera is arguably the most essential piece to the experiment. It has to have the ability to record at a resolution clear enough and a frame-rate fast enough to enable Dr. Colwell to dissect the effects of the experiment in micro-gravity.
Dr. Colwell has several high-end cameras at his disposal however for initial projects he will be using the StreamView-LR (see Figure 8 below). The
StreamView-LR has a max resolution of 640 x 480 (VGA) which has sufficed on past experiments but also a pixe l size of 7.4 x 7.4 µm. Even at this max resolution the StreamView can still maintain a 200 frames per second rate, maximizing visual data that was retained onto the solid state drive. An additional ability of the camera is the integrated sensor can record in either 8-bit monochrome or in 24-bit color. Currently Dr. Colwell records the COLLIDE-3 experiment in monochrome however if that changes in the future this camera has the capability of adapting.
Figure 13.5.1 SVSI’s StreamView-LR
At a resolution of 640x480 and a frame-rate of 200 frames per second the data transfer rate is about 100 mega-bytes per second. Recognizing this, the
StreamView includes a gigabit interface to make such data acquisitions easier.
The mainboard has a gigabit interface and the project will use a solid-state drive with a SATA II interface (capable of transferring data at 300 megabytes per second), thus the combination of both will compliment the StreamView-LR nicely.
- 79 -
The container that will house the entire COLLIDE-3 experiment has limited space so size was also an issue in deciding on a high-end camera. The StreamView, despite its many features, is only 1.5” x 2.0” x 3.2”.
14.0 Camera Testing
Even though the MotionBLITZ Cube2 is a stock camera that we ourselves have not created, we still will be controlling it through various systems, so we need to test to make sure we have properly integrated it into the rest of our system.
There are two ways that the camera will be connected into our AVM; the setup where it utilizes its own onboard memory to record footage, and the setup where it transfers the footage directly to a solid state external drive. In terms of what we actually have to test, we checked to make sure our microcontroller is properly providing power to the camera at predesignated times, and that our trigger commands are acting in such a way that we record the correct footage. If we’re writing onto an external solid state drive, we also checked to make sure that the footage is successfully written.
14.1 On board storage
First we tested the integration of the MotionBLITZ Cube2 using solely its own on board storage capabilities. We did this since all of these steps was also used once we implement the solid state drive, the only difference being that the solid state drive adds another step at the end. To begin, we tested using the
ATmega328 to turn on and off the camera. Doing this will involve adding a normally open, mechanical relay and an LED to the schematic shown in the camera design portion of this paper, as well as connecting the microcontroller to power, rather than the trigger. This setup is shown in Figure 14.1.1:
- 80 -
Figure 14.1.1- MotionBLITZ Cube2 configured to be turned on/off by the ATmega328
The microcontroller was programmed to send a high signal to Pin 18 (connected to the relay) and Pin 19 (connected to the LED) simultaneously for a period of one minute, and then it sends a low signal. The LED represents when the camera should have power, while the power indicator on the MotionBLITZ Cube2 itself tells us if it is truly on. If the camera does not turn on with the LED, we disconnect the setup from the microcontroller and see if the 12 volt source alone can power the camera. If this is not the issue, then the relay is likely to blame.
Similar to the possibilities of the relays described in the microcontroller testing section, possible reasons for the camera not turning on could either be the relay not being sensitive enough (a mechanical relay could take more power than the
ATmega328 can offer to switch on), or the relay simply can’t handle the current draw of the camera, which does peak at 15 watts of power. In the first case, while it may seem like an inelegant solution, we could have the microcontroller power a solid state relay, which then powers the mechanical relay. In the second case, we would find a relay capable of handling the large amounts of current likely to be drawn by the camera.
Since the camera is requires more power in times of recording than in times of simply being turned on, we have to ensure the relay is capable of fully powering the camera through all operations. Once the above testing proves successful, we will keep the same power setup but connect the MotionBLITZ Cube2 to a computer and begin recording footage. If the relay is unable to keep up with the higher requirements imposed on it by the camera operating on a higher level, the recording will stop and the camera will power down, indicating that while the relay is capable of starting up the camera, it is still not sufficient for our needs.
- 81 -
Once the power for the camera is configured, we implement the triggering mechanism. The layout for this are nearly identical to what was seen in the microcontroller design section, but with a similar LED attached like seen in Figure
14.1.1, and the system also controlling power. This is all laid out in Figure 14.1.2:
Figure 14.1.2- Trigger mechanism implemented in MotionBLITZ Cube2
Of note here is that instead of powering a relay, the microcontroller is hooked directly up to the trigger input of the MotionBLITZ Cube2. Since the trigger input reads a high value at 3.3 volts, and only needs 5mA to drive that value, the microcontroller should be able to get it to read a high input on its own. LED2 serves much the same purpose as LED1, in which it will be used to visually represent when the ATmega328 should have triggered the camera. In terms of software, in the Arduino environment we will be configuring this to begin by powering on the camera in the fashion described previously.
After a delay to give the camera time to start up, a high signal will be sent to Pin
13 and Pin 14 on the ATmega328, signaling the start of a recording. A second later, the signal will go low. This won’t affect anything, since the camera only reads the positive edge of a trigger. Around thirty seconds later, we will apply a second high signal to Pin 13 and Pin 14, signaling the end of the recording.
Based on the resolution and frame rate selected on the camera, we should now have anywhere from 3 to 30 seconds of footage on our camera. We will verify this by attaching the camera to our computer, booting up the software provided by Mikrotron to grab the data off of t he camera, and making sure it’s the right time period. We can verify this by having a stopwatch in front of the camera during its recording stage. If we do not have the proper footage on the camera at this point, and LED2 is lighting up at the correct times, it would mean that we most likely need the microcontroller to power a relay instead of the input itself.
- 82 -
14.2 Solid State Drive storage
For us to test this part of the AVM, we need to first have all of the above steps tested and working. Assuming we have done this, we can move onto directly storing footage captured during recording onto our solid state drive. The only difference between this setup, which is shown in Figure 14.2.1, and that of Figure
14.1.2, is the presence of the solid state drive, and the component buffering the two which will implement the SATA III protocols.
Figure 14.2.1- MotionBLITZ Cube2 now configured to transfer data to solid state drive
Testing of this is also very similar to what we’ve done previously, and we assumed the only part we’re testing for failure is the connection between the
Ethernet on the camera and the serial port on the solid state drive. After we run through our record routine, we connect the external drive to our computer and load the footage off of i t. Hopefully at this point we’ve converted it properly into a readable format. If not, there is an issue with our SATA III protocols, and we’ll have to redesign the converter and try again.
- 83 -
15.0 PCB Layout
On our traced PCB board, we decided to include the ATmega328 (with its crystal and voltage regulator), the FT232, and our H48C. The UIM will plug into the microcontroller through the serial to USB port when we are not programming the
ATmega328, since at those times the FT232 would be connecting the microcontroller to a computer. Our PCB design is shown below, in Figure 15.1.1:
Figure 35.1.1-PCB Tracing
Wire jumpers were used to connect most of the H48C connections, and most of the I/O pins on the ATmega328 will be ran externally to a through hole board with relays soldered on. The reasoning for this is that if we ever wish to change what components are utilized by COLLIDE-3 or the AVM, such as anything that would require a higher current, we would be able to replace our relays easily to accommodate the new demands.
- 84 -
16.0 Specifications (Hardware)
16.1 Hardware
With all the research and comparison that we did. We can come to the conclusion to pic these hard to be purchase. The first is the accelerometer. We pick the Hitachi H48C. It’s operating voltage is from 4.5v(min) to 5.5v(max). It’s sensitivity is 366.3 mV/g. It can operate from -25
°C to 75°C. It’s zero-g voltage output is about 3.3V when it it goes high and the output delay is 1ms.
It’s high level voltage input is .7
v and low level voltage input is .3v. It’s sample rate is 200 sps
The next important component is the microcontroller. We went with the Atmel
ATmega328. I t runs at .2mA with everything active. During power save mode, it’s at .75uA with asynchronous timer running. With this feature, user can maintain timer base while the rest of the device sleeps. In standby mode, it’s using a bare minimum of .50uA. It has a 32k flash memory, which is more that enough for the many task we are giving it.
Without the next component, we won’t have an experiement to look at and study.
This component is the solid state drive. We went with the OCZ Vertex 3, model number VTX3-25SAT3-120G. It is SATA II as well as SATA III compatible. One of the main reason for using a SSD is for the write speed, shock resistance, and vibration resistance. It’s write speed on SATA II is up to 550 MB/s. It can withstand a shock of 1500G at .5ms and a vibration resistance of up to 2.17G 5-
700Hz. It consumes 3 watts when active at a temperature of 0-70 celsius. This solid state drive have the capacity of 120gb.
Another hardware component that we have which is not needed but is a plus to our experiment is the display module(DM). With this module, Dr. Josh Colwell can change the variable and know what the variables are currently programmed into the experiment. We went with the Crystalfontz America model 635. It operates between 0 to 50 degree celsius and non-operational temperature is -10 to 60. Overall dimension is 142mm x 37mm and viewable dimension is 82.95mm x 27.50
mm. It’s voltage supply minium is 4.75v, nominal operating at 5v, and it maximum voltage supply is 5.25v. It weighs at only 71 grams. It also have buttons for input but for our purposes, we only use it as a disply and not an input module.
- 85 -
17.0 Software Design
17.1 Functional Requirements
The Functional Requirements represent a list of tasks that this experiment must perform correctly in order to be considered a success. Tasks not mentioned will be non-Functional requirements, such that the focus of the development team will be to accomplish the Functional Requirement and only after those have been fully implemented will the non-functional requirements be implemented.
Experiment must start only when micro-gravity has truly been reached
Power to the peripherals must happen in a staggered process
Data captured from the camera must successfully be stored on the SDD
17.2 Software Requirements Specification
Good software can make the difference between success and failure of this mission, therefore it is important that the software requirements are thoroughly defined and established in order to determine the completeness of this design.
Since this is going to be a low level embedded project, C was the language used to implement all software. The software will compromise of 3 modules that will handle the overall operation of COLLide-3 AVM; these are Interfacing, Control, and Input/Output. This software will be designed with the following requirements:
Atmel ATMega328
Crystalfontz CFA635-YVE-KS1
Hitachi H84C Accelerometer
Mikrotron EoSens MC1362
Stake Holder Description
Dr. Colwell
Development Team
Needs COLLide-3 AVM to successfully launch experiment
Successfully learn to develop software/hardware
Dr. Richie To oversee Engineering standards are upheld in development of Project.
Table 17.2.1 Shows our stake holders for our project.
- 86 -
Event Table:
The following table compromises the external events the software must respond to, followed by a detailed description of each event.
Event Name External Stimuli Software
Response
Internal Data
Boot up
User input
µGravity Flag
User powers on
Device
Software is initialized, reads instructions memory
Internal variables and data structures are initialized to default settings.
UIM is used to change settings
Hardware interrupt generated, software is must handle interrupt while not losing any data
All data in registers pushed are onto stack, data from interrupt is pulled and processed
Accelerometer detects a microgravity environment
Software will keep track of how many times a microgravity flag is obtained.
Variable
FlagCount is incremented or zeroed depending on input
Experiment Start Experiment has reached microgravity
Software turns on all peripherals in a staged manner
Data is prepared to be received via
Ethernet
Experiment End Experiment cut off time has been reached
Shut peripherals down Close any files or variables
Table 17.2.2 Shows the events that the software have to response to.
Boot up: On startup of microcontroller, the CPU will load the IR register with the first line of code available in the EEPROM of the device. All data structures and variables will be initiated to their default values and displayed
User Input: The user will have the option to change the following options:
Experiment start time, experiment duration, led turn on time, camera turn on time. The UIM will generate a hardware interrupt and all these values will be saved in one sweep.
- 87 -
µGravity:
Because the accelerometer will send false positives before microgravity is reached, whenever an interrupt from the accelerometer comes in, we will add that value to a counter which when it reaches its max specified value, we will then start the experiment.
Start: When the counter for micro-gravity has reached is value and confirmed micro gravity, the Atmel ATMega328 must begin the process of powering on the LED array, sending the PWM signal to the Stepper motor, and send the signal to the camera to start recording, all of this must occur at the times specified by the user, or default values already stored in memory.
End: An experiment duration variable will dictate how long this experiment will last; this is so this AVM can be used on multiple experiments of varying length. When the end is reached, LED array must be turned off, Camera must be turned off, and any data being written to the SATA SDD must be finalized. Any file pointers must be properly closed and all active processes must be finalized.
17.3 Non-Functional Requirements:
Non-Functional requirements represent a list of tasks that will be considered a supplement to the core requirements listed in the functional requirements; these are mostly for optimization and added features and for the sake of the software will be implemented once the Functional Requirements are fully operational.
User input
Timing accuracy
File Allocation Table
To expand on the Non-Functional Requirements, the reason these tasks are considered non-functional is because they are deemed to be features in addition to the main point of this experiment, which is to record an experiment in suborbital space and save that data. User input can be achieved through reprogramming of the EEPROM with the new variables, Timing accuracy is not as critical as long as it happens within an acceptable boundary, and implementing a File allocation table might be to difficult to accomplish in the scope of this project.
- 88 -
18.0 Software management plan
18.1 Team Organization
This team is comprised of 4 engineers – Walter Castellon, Tri Tran, Mohammad
Amouri, and Josh Steele, of which in terms of software development will be split and given tasks according to each ones strengths and weakness. Since Tri and
Josh have the most hardware experience they will focus on hardware implementation and development whereas Walter and Mohammad will focus on software development. However since this is a group effort all members will take on the role where they are needed most, and the lines between strict software development and hardware development may be blurred to fit any requirements.
18.2 Software Life Cycle Process
For this project the waterfall model with prototyping will be followed. The primary reason for the selection of this model is the short life span of this project. The waterfall model aspect allows for a more direct approach to the engineering of a one life term product. The prototyping aspect will be useful in not only familiarizing the project members with exposure to new concepts such as programming applications for an embedded system, but also be extremely useful to find the best methods to accomplish each requirement specified as shown in figure 18.2.1.
Figure 18.2.1 Waterfall model
- 89 -
18.3 Quality Assurance
Quality assurance activities was based on phase completions of the application.
Once a certain part of the project is completed, it was tested through either simulation or prototyping by the programmer. Through testing of each of the functional requirement will then be done by each of the engineers to find errors in logic or unhandled exceptions.
18.4 Detailed Design
The following is a detailed design of the software implementation of COLLide-3
AVM. Although the project will not be using an object oriented approach in terms of data structures, uml diagrams will be shown to demonstrate the connection and flow of each module in the software. In the below diagram in figure 18.4.1, the three activities of powering on the peripherals were shown in a staggered manner to demonstrate the delay needed in each stage of the power on process, this is to make sure that when the camera is ready to start filming, all other components are active and ready to start the experiment. At the end of the experiment all data will be written to the SDD, afterwards all peripherals can be shut down simultaneously.
Figure 18.4.1 Collide 3 AVM
- 90 -
Another activity that needed to be defined also is the UIM, which will send and receive data over i2c communication protocol. CrystalFontz recommends the following Data Structure for configuring the packet structure. In order to implement this UIM we will have to convert our commands to the following format: <type><data_length><data><CRC>, m where type is a response or a command being generated, data_length tells us how much binary data is being sent, the data or payload is the actual transmitted binary digits, and crc is a cyclic redundancy check, which is a 16 bit checksum used to detect any errors in transmission. Along with this will be the implementation of the command line interface that will be displayed on the screen of the UIM. That will essentially be a short menu where the user can input his changes and have them saved. The three main settings on the display will be LED Settings, PWM Line Settings, and
Camera settings. From there the user will be able to change the turn on, duration, or end time for each individual component in the system. Below is a diagram figure 18.4.2 depicting the basic user interface envisioned, each entry will lead to a new screen with the corresponding values being displayed.
Figure 18.4.2 Basic user interface envision.
These three settings each correspond to variables in this program, led_start , pwm_start , and camera_start . These variables will be time, in ms that as mentioned earlier will dictate the start time of each task, this time will be relative to the start of the experiment, so if a 5 ms delay between each stage was to be implemented, led_start would be 5, pwm_start would be 10, and camera_start would be 15, etc. Any time these variables are updated a hardware interrupt will be generated, at that time all data the registers will be pushed onto a stack, the new data will be collected and processed, then all the variables will be popped off the stack and the program will return to its execution before the interrupt occurred.
The actual C program that will be developed for the COLLide-3 AVM will have all of these components in one executable file that will handle all of these tasks. It will essentially be a sequential process from beginning to end, which is why an embedded system is ideal, no need for complex concurrency.
Since the ATMega 328 doesn’t contain a dedicated PWM line, we will have to simulate one in code using an I/O pin onboard the ATMega 328. In order to complete this task we will essentially create a two variables delay_1 and delay_2,
- 91 -
both of these variables will be a length of time in ms, so at the start, delay_1 and delay_2 will be initialized to their values, when delay_1 expires a i/o pin will be switched low, and when delay_2 expires, that same pin will be switched high.
This process will continue until the pwm duration variable is realized. The inverse of the two delays added together will equal the frequency of the pwm line, and the length of time of delay_2 divided by the total delay will equal our duty time.
As an example if they were both 5ms then the frequency would be 100hz and the duty cycle would be 50%. This is a easy and convenient manner of creating
PWM as you can theoretically use all your I/O pins as PWM lines. A simple manner of implementing this task is with a software state machine, which can be two functions that call each other until time length has expired, however it is important to avoid a live lock or race conditions, so a timeout variable will also be necessary, a count that would be the maximum allowed calls to the function.
This function will need to be thoroughly tested as a lock condition here can cause damage to the COLLide-3 AVM module. http://www.societyofrobots.com/member_tutorials/node/236
The next thing to consider is how data will go from the camera to the SDD, this will be the most critical aspect of the design, as success or failure will be determined by our ability to accurately capture and store the images from the camera. Because of the critical nature of the transfer process, the first thing that the microcontroller will do is disable all interrupts; this will ensure no process will interfere with the file transfer. 2 separate transfer protocols need to be implemented in order to be able to send and receive data to the peripheral components; those are Ethernet and Serial ATA. We will first discuss the
Ethernet implementation then move to Serial ATA, and finally the process that will transfer from one to the next.
Ethernet protocol uses Manchester encoding as its means of transmitting binary data. Manchester encoding is convenient since it allows us to not depend on an external clock in order to sync binary data in transmission; a clock can be sampled at the start and us ed as just a base for transmission. Manchester’s method of encoding is simple to implement, whenever a 1 is transmitted you start high, and half way through transmission you switch low, for a zero it’s the opposite, you start low and at the half cycle you switch high. A Manchester encoded sequence can be generated by using bit shifting, representing each bit as a Byte; a 1 can be represented by having a 1 in the upper half of the byte, and a 0 in the lower byte. The same can be done for a zero, put a 0 in the upper half and 1 in the lower half of the byte. This is a simple method to implement
Manchester encoding in figure 18.4.3.
- 92 -
Figure 18.4.3 from https://commons.wikimedia.org/wiki/File:Manchester_encoding.svg
Next is the context that is transmitted over the Ethernet line. Similar to the UIM module we will have to create another data struct that holds the info in the fig below. The Ethernet Frame will wrap up the data into a package to be delivered and decoded by the microcontroller. Since the microcontroller will only be receiving data it will make streamlining the functions easier. The preamble is what sets the clock rate at the beginning; it will send an 8 Byte pattern of
10101010 for 6.8µs. Because the start and source address will always be the same, once the first 2 addressed are acquired the following’s frames can have their field ignored. Next we will have the variable that will tell us the length of the data, this will be stored into a variable, which will be used in the boundary for a for loop to compile all the following data. Finally 4 Bytes will be collected for error checking. We will be ignoring this value, Ethernet uses CSMA in order to detect collisions, due to the fact we only have 1 connection this won’t be needed.
Shown below is the Ethernet frame in figure 18.4.4.
Figure 18.4.4 from http://www.doc.ic.ac.uk/~nd/surprise_97/journal/vol1/mhl/ether01.gif
- 93 -
Data will be collected until enough packets have been collected to form a block on the SDD. So essentially a container will be created that will aggregate all binary data received, the reason we are doing this is to make sure when we write to the SDD an entire block is written at once. This is important because since we are not writing with a file allocation table we want all the data to be accessible sequentially. When data is sent to a Solid State Drive, the drive will determine how many blocks it needs to fill the data being sent, then the data will be divided into even block sizes, if there is remaining Bytes the Solid State Drive will use an entire block to write the remaining Bytes, leaving the unused portion inaccessible. If this were to occur it would create a gap in the data from the camera, causing it to become unreadable. This process will require through testing ensuring it functions as described.
Finally is the Serial ATA function that we must implement. Serial ATA is a high speed protocol allowing speeds of around 6GB/s. Utilizing this speed to its potential was beneficial in preventing bottle necks. In terms of software we will be focusing on the upper layers of the protocol, and leaving the lower physical layer up to the hardware design. Similar to Ethernet, SATA will send data in packets. A SATA Frame will consist of the following 4 segments: SOF which indicates the start of a frame, Payload which is the data being transmitted, CRC which is a cyclic redundancy check, and finally an EOF, end of file delimiter. Our software must convert the data received from the Ethernet into data that can fit into this structure. For the sake of simplicity we kept the size of the packets the same as those for frames, however there are less packets than those for
Ethernet so we had to translate these values to make them fit.
Finally on the list is the Transfer function that will govern the Ethernet and SATA functions. This function will make the calls between collecting a frame from
Ethernet and sending a packet to SATA. Because we have very limited memory in the ATMega 328, we will have write to memory 20KB, then write to SATA
20KB, this process must happen in this manner to prevent out of memory errors or overflow error. We will achieve this using a memory full flag, a Boolean value that will be set to true when 20kb of data has been written. When this occurs we will then dump all data onto SATA Frame packets and send it over to the Solid
State drive, and then clear the memory for the next 20KB.
So in total there were about 4 main activities that must be handles by the AVM software. Each activities were developed in a modular manner, such that changes to one will not affect the functions of the other activity. The initial activity will implement the UIM and accelerometer accumulation described earlier, it will also store the delay time of each component, once the experiment has started these functions will be halted and the Transfer activity will be initialize. This will switch between receiving data from the camera, and sending it over SATA, the
UML diagram below helps describe the system and how each module interacts with each other. Ultimately this will facilitate all the events described on our events table. Shown below in 18.4.5 is class diagram.
- 94 -
Figure 18.4.5 Class diagram
- 95 -
19.0 Software Testing
19.1 Introduction
Due to the large expense of running COLLide-3, it is critical that this software gets the job done right the first time. As such it is important that every aspect of software is thoroughly tested and verified to work correctly. The objective for all test procedures to be outlined is to verify and validate that all obligations are successfully met and all implemented function requirements operate as defined in the software design portion of this document. All test procedure will test for the following:
Software operates and handles any exceptions generated during operation time
All function requirements meet defined standards
Implementation design takes into account unusual operation modes
Implementation does not produce any unintended results.
19.2 Test Environment
The primary test environment to test software will be AVR Studio 5 Integrated
Development Environment. The IDE features full support for developing and debugging embedded Atmel AVR applications with an embedded C compiler, assembler, and simulator. This was ran in a Windows XP-32 bit environment.
Testing will be conducted at two levels, the first level will be tested by the primary developers, testing Functions as they are implemented. The second set of testing will be done by the entire development team for quality assurance and to perform redundancy testing of implementation, functionality, and overall implementation of COLLide-3 AVM, to ensure this product meets all design specifications.
The secondary testing was done with the AVM module in hardware. This was done at the final stage of project development and only after all other milestones has been met, this is to catch any errors that may not be observable under simulation and to get a real world sample of what AVM will have to work in.
- 96 -
19.3 Stopping Criteria
Testing procedures was done in an iterative fashion. Functionality essential to successful operation and required features were primary test procedures, secondary test procedures consisted of non-functional requirements as listed in software design. Stopping criteria can only be achieved by 100% completion of
ALL primary test procedures. Requirements will be tested by Q&A testers after each release version to ensure functionality and adherence to all obligations. All other test procedures will first be tested at the unit level by the developer. Once the implemented functionality has been validated by the developer it will undergo
Q&A testing to verify functionality as well as check for any errors or unintended results.
If any errors are found while testing, the test procedures was executed until completion or an error prevents completion. This was done in order to maximize efficiency and catch as many errors or issues per test as possible, an archive of failed test procedures were logged.
If errors are found during unit level testing the developer will complete the test procedure until a fatal error is encountered. Once the test procedure is complete the developer will fix all issues found and then run the test procedure again. This process will repeat until the test procedure is ran to 100% completion for primary test.
If errors are found during Q&A testing, the tester will run the test procedure until completion or a fatal error is encountered. The person conducting testing will email their results of their test to the developer responsible for the implementation that was tested. Once the developer has resolved the issue that failed testing, they will re-conduct unit level testing to validate their correction fixed the issue, and did not create any new deficiencies. This process will repeat until Q&A test is conducted successfully and the implemented functionality can be validated and verified.
19.4 Description of Test Cases
Test Title: Software reliability test
1. Test Objective:
To perform stress testing of COLLide-3 AVM to ensure successful and prolonged operation within acceptable levels. Making sure that the AVM would still be working in different scenerios for future changes or use.
- 97 -
2. Test Description:
The following will be tested:
Long term reliability of COLLide-3 AVM Software
Stability of essential and supporting functions
3. Test Conditions:
Software reliability tests will be conducted using AVR Studio-5 simulation and once product is finished then with physical hardware. Tester will perform various actions to ensure reliability of software for duration of 30 minutes to test continued operations of Space Ace.
4. Test procedure Steps:
Step Condition/Action Intended Results
1. Software initialized is All functions are ready, and all data structures are initialized.
Fail Criteria
Any noticeable deviation of software, or failure to initialize
2. Initialize UIM Software correctly sends and received data to UIM
UIM does not recognize commands from Micro-
Controller, or Micro fails to receive data
3. Accelerometer will be simulated
Accumulator increments on positive signal from sensor
Accumulator does not increment, or fails to process signal
4. 25 minutes of standby
The software will remain running for 25 minutes
Within those 25 minutes a software exception is generated or goes into unplanned state
5. Repeat of test The software will retested after 25 minute operation, all functions should still be operational
Any function becomes unoperational or AVM becomes unresponsive.
Table 19.4.1 Shows the test procedure steps
- 98 -
Test Title: Experiment Start
1. Test Objective:
To test AVM experiment mode initializes all components.
2. Test Description:
The following actions will be tested:
AVM peripheral control
AVM peripheral time constraints.
3. Test Conditions:
From the simulator, peripherals will be a emulated by having a method of inputting hard-coded test condition. In the physical test environment the actual peripherals will be present.
Step Condition/Action Intended Results Fail Criteria
1. Software initialized
2. Accelerometer is set to High is All functions are ready, and all data structures are initialized.
Any noticeable deviation of software, or failure to initialize
Accumulator increments experiment condition is met until start
Experiment Start isn’t reached.
3. LED is activated LED activates under default timing constraints
LED does not turn on, or not under correct time
4. PWM activated is PWM operates under correct frequency and under default timing constraints
PWM does not turn on, or not under correct time, or incorrect frequency
5. Camera activated is Camera activates under default timing constraints
Camera does not respond or not on correct timing constraint
6. Experiment end time is reached
All peripherals are turned off
Any peripheral stays on, or are not properly shut down
Table 19.4.2 Shows the test conditions
- 99 -
Test Title: Protocol Networking
1. Test Objective:
To test AVM Ethernet and SATA protocol interface correctly with microcontroller
2. Test Description:
The following actions will be tested:
AVM peripheral control
AVM Protocol control
3. Test Conditions:
From the simulator, peripherals will be emulated by having a method of inputting hard-coded test condition. In the physical test environment the actual peripherals will be present.
Step Condition/Action Intended Results
1. Software is All functions are ready, initialized
2. Experiment is started
Fail Criteria
Any noticeable deviation of and all data structures software, or failure to are initialized. initialize
All peripherals activate Peripherals don’t activate
3. Ethernet frames begin transfer
All Ethernet packets are received by microcontroller and correctly decoded
Ethernet packets are loss or not correctly decoded
4. Sata frames begin transfer
All SATA packets are sent to SDD and correctly transmitted
SATA packets are lost or incorrectly decoded
5. Transfer function
Transfer function correctly switches between receiving
Ethernet and Sending
SATA Frames
Table 19.4.3 Shows the test conditions
Transfer function gets stuck in one state, does not switch at correct times, or generally fails to handle Transfer
Test Title: UIM Control
4. Test Objective:
To test AVM UIM correctly interfaces with microcontroller
- 100 -
5. Test Description:
The following actions will be tested:
AVM UIM Control
AVM UIM data structures
6. Test Conditions:
From the simulator, the UIM will be a series of HARD CODED test cases, for the physical test the UIM will be on board and present for the tester to interact with.
Step Condition/Action Intended Results
1. Software is All functions are ready, initialized and all data structures are initialized.
2. UIM Changes
LED turn on/off time
Microcontroller correctly receives new variables for LED Turn on/off time
3. UIM PWM turn on/off is changed
Microcontroller correctly receives new variables for PWM turn on/off time
4. UIM Camera turn on/off is
Microcontroller correctly receives new changed variables for PWM turn on/off time
Table 19.4.3 Shows the test conditions
19.5 Test Procedure Results
Fail Criteria
Any noticeable deviation of software, or failure to initialize
LED turn on/off time are not updated
Microcontroller turn on/off time are not updates
Microcontroller turn on/off time are not updated
Successful completion of Software reliability was achieved when both simulation and Physical testing have both passed the test with 100% completion. Tester logged all results and make note of any unusual behavior.
- 101 -
20.0 Research Software
20.1 Display Module
Once we select the specific model to use as our display module we had to start writing the software to allow it to communicate with the microcontroller and the microcontroller to the display module and this depends on what kind of bus the display module uses. From the four display module options we selected there are several different buses in which we could write to and from our display module, they are: RS-232 (Recommended Standard 232), I 2 C (Inter-integrated Circuit), and Universal Serial Bus (USB). All three have advantages and disadvantages to them even though the current most used bus in consumer electronics is the
Universal Serial Bus (USB).
20.2 RS-232
The RS-232 is commonly used in serial ports between a Data Terminal
Equipment (DTE) and a Data Circuit-terminating Equipment (DCE). Please see
Figure 19.2.1 for a visual representation of the communication lines between the
Data Terminal Equipment and the Data Circuit-terminating Equipment. Initially
RS-232 was the standard feature in a personal computer for connecting modems, printers, mice, hard disk, un-interruptible power supplies (USP), and other devices; however the universal serial bus (USB) standard has replaced it because the RS-232 was limited on transmission speed and also possessed a large voltage swing (usually between -12v and +12v). There can also be an absence or misconnection of flow control (handshaking) signals, resulting in buffer overflow or communications lock-up. For the cable in use there is a potential for incorrect communications function that will result in the reversal of the “Transmit and Receive” data lines as well as one or more handshaking lines.
The maximum length of a cable using RS-232 is fifty feet (50 ft) and the maximum data rate of the RS-232 is twenty kilo-bits per second (20 kb/s). A RS-
232 uses a twenty-five (25) pin connector which compared to the universal serial bus (USB) connector is quite large and bulky.
In the RS-232 the frame consists of one start bit, seven or eight data bits, parity bits, and stop bits. The start bit is used to signal the beginning of a frame and the stop bit is used to signal the end of a frame. The only bit that probably needs a bit of explanation is the parity bit. Parity is used to detect transmission errors.
If the receiever checks the parity bit when the frame arrives and it is the wrong parity, then the receiver knows an error occurred in transmission and the receiver can request that the transmitter re-send the frame. The bit time is the basic unit
- 102 -
of time used in serial communication. It is the time between each bit that the transmitter outputs. This is used to synchronize the transmitter and the receiver.
20.3 Inter-integrated Circuit (I
2
C)
Inter-integrated circuit (aka two-wire interface) was invented by Philips and used between low-sped peripherals like a motherboard, embedded system, mobile phone, etc. The Inter-integrated circuit has a seven to ten bit address space and the common bus speeds are one hundred kilobits per second for the standard mode and ten kilobits per second for the low-speed mode. In a lot of embedded systems more recent revisions of Inter-integrated circuits are used where there are “fast modes” that can reach up to one megabit per second and even a high speed mode that can get up to three and half megabits per second.
Inter-integrated circuit has three different types of messages. Each message, as defined by Inter-integrated circuit, begins with a START and ends with a STOP.
These three types are:
Single message: master writes data to slave
Single message: master reads data from slave
Combine messages: master issues at least 2 reads/writes to one more slaves
Inter-integrated circuit is popular for its simplicity and flexibility; however there are more features that add to its popularity. Inter-integrated circuit only requires two bus lines (which we will go into further detail later) and has no strict baud rate requirements (as opposed to the RS-232. All components have a very simple master and slave relationship and each component or device connected to the
Inter-integrated circuit bus is software addressable by a unique address. Finally
Inter-integrated circuit provides arbitration and collision detection.
The two wires as required by the Inter-integrated circuit are called SCL (the clock line) and SDA (the data line). To synchronize all data transfers over the Interintegrated circuit we would use the SCL line. These two lines are connected to every device on the Inter-integrated circuit bus.
Data is transferred in eight bit sequences. The eight bit sequence is placed on the SDA line (the data line) starting with the most significant bit. Then the SCL line (the clock line) pulses high then low. The SCL line has to pulse nine times to send an eight bit data sequence (one for every bit and the ninth one to send back an acknowledge bit). See Figure 20.3.1 for a diagram of the SDA line and the
SCL line. The receiver sends the acknowledge bit (ACK bit) to indicate it has receive the last bit of the byte and is ready to receive another eight bit sequence;
- 103 -
however if the receiver does not send back an acknowledge bit then it means it is not ready for further data and the master should stop transferring.
Figure 20.3.1. SDA line with 8 bits and one acknowledge bit (ACK). SCL line with 9 pulses, one for every bit and one for the ACK bit.
The inter-integrated circuit software protocol, as previously mentioned, has a master and slave relationship between each component attached to the interintegrated circuit bus. Transmissions always have a start and stop sequence at the beginning and at the end of each of them. Here are examples of the protocol for a master component writing to and reading from a slave component.
Master Writing To Slave
1. Send a start sequence
2. Send the inter-integrated circuit address of the slave with the read/write bit low
3. Send the internal register number that needs to be written
4. Send the eight bit date sequence
5. If necessary send the rest of the eight bit sequences
6. Send a stop sequence
Master Reading From A Slave
1. Send a start sequence
2. Send 0xC0
3. Send 0x01
4. Send a start sequence again
5. Send 0xC1
6. Read data byte from CMPS03
7. Send the stop sequence
The standard clock speed for inter-integrated circuit is up to one hundred kilohertz. In fast mode the speed increases to four hundred kilo-hertz and then there is high speed mode which is up to three and a half mega-hertz.
- 104 -
20.4 Universal Serial Bus (USB)
The universal serial bus replaced the RS-232 when it was introduced in the mid-
1990’s. It re-standardized all computer peripherals such as keyboards, pointing devices, printers, external hard drives, etc. The data sent through the bus follows Intel’s Little Endian specification where the bytes are written and read fro the least significant bit (LSB) to the most significant bit (MSB). These packets are then encoded or decoded using NRZI (Non Return to Zero Invert) or bitstuffing. Bit stuffing is the practice of inserting a zero after every six consecutive ones int eh data stream forcing a transition to the receiver every seven bits to guarantee the data and clock lock. Bit stuffing is used to make sure the signal transitions are adequate.
Universal serial bus communications takes place between the host and endpoints located in the peripherals. An endpoint is a uniquely addressable portion of the perifpheral that is the source or receiver of data. The endpoints’ address is defined by four bits. Each endpoint returns a descriptor which is a data structure that tells the host about the endpoints configuration and expectations. Descriptors include transfer type, max size of data packets, interval for data transfers and in some cases the bandwidth needed.
All data packets begin with a synchronization (SYNC) field, which is a coded sequence designed to provide a maximal transistion density. Its used by the input circuitry to align the incoming data with the local clock. The synchronization from the intial transmitter is eight bits in length, unless it is for high speed in which case it is thirty-two bits in length. The last two bits in the synchronization field are used to identify the end of the synchronization field and the beginning of the packet idendtifier (PID). The packet identifier immediately follows the synchronizaition field for every data packet. It consists of two fields: one is a four-bit packet type field and the other is a four-bit check field. See Figure 20.4.1 for a diagram representing the eight-bit packet identifier. The purpose of the packet identifier is to indicate the type of packet, the format of the packet, and the type of error detection applied to the packet. The check field of the packet identifier gives it reliable decoding so there are no miscommunications in interpretin the packet. The check field is created by taking the one’s compliment of the packet type field. Errors are detected if the check field’s bits are not compliments to the packet type field.
Figure 20.4.1. The first four bits represent the packet type field. The last four bits represent the check field bits. These check field bits should be one’s compliment to the packet type field.
- 105 -
Universal serial bus supports four different types of data transfers: control, isochronous, bulk and interrupt. Control Control transfers exchange configuration, setup, and command information between the device and the host.
CRCs check the data and retransmissions when needed to guarantee the correctness of these packets. Bulk transfers move large amounts of data when timely delivery isn't critical. Typical applications include printers and scanners.
Bulk transfers are fillers, claiming unused USB bandwidth when nothing more important is going on. CRCs protect these packets. Interrupt transfers, though not interrupts in the CPU-diverting sense, poll devices to see if they need service.
Peripherals exchanging small amounts of data which need immediate attention
(mice, keyboards) use interrupt transfers. Error checking validates the data.
Finally, isochronous transfers handle streaming data like that from an audio or video device. It's time sensitive information so, within limitations, it has guaranteed access to the USB bus. No error checking occurs so the system must tolerate occasional scrambled bytes.
There are two current standards for a universal serial bus: 2.0 and the most recent 3.0. The 2.0 standard was released in the year 2000 and is found on the majority of products. This standard can achieving a data transfer rate of up to four hundred and eight megabits per second. The 3.0 standard was released in the year 2008 and it had two upgrades over the standard 2.0: speed and power consumption. The standard 3.0 can achieve a data transmission speed of up to five gigabits (or six hundred and forty megabytes) per second. The standard 3.0 also achieved its goal and lowered its power consumption. As an added bonus to phase the 3.0 standard in easily it is also backwards compatible with the standard 2.0.
All three types are popular enough to find the needed information to be able to write and program a communication interface between our universal input module and the microcontroller; however the ultimate decision for which bus we will be essentially using will come down to which specific display module we choose. The manufacturer has makes the display module have a specified interface to code with but then we can choose which we can communicate with the microcontroller with. While the gives us some flexibility to choose which interface we rather go with (especially considering data transfer rates and power consumption) just to simplify things we will probably maintain the same interface that is already built-in the display module. The universal serial bus is the most powerful in terms of data transfers but since the there should be minimal data to be transferred between the display module and the microcontroller that may be more than we need. We were biased towards the simplest communication protocol since, in the case of the display module communicating with the microcontroller, we are not that concerned with high data transmission speeds.
- 106 -
21.0 Display Module
One aspect of the Collide-3 that we are responsible for implementing is a display module. The display module will allow a scientist or astronaut to make changes to the Collide-3 experiment. These options include: experiment begin time, experiment end time, and experiment run time. To make these options easier to access we decided to use a simple keypad interface in combination with a liquid crystal display. The liquid crystal display will provide basic information reflecting a menu and possible selections. The keypad will be used to navigate through the menu, make selections, and change the current state of the experiment.
Another option we considered momentarily was a touch screen display, thus bypassing the use for a physical keypad. The touch screen would also provide a more appealing user interface (since its graphics ability would be greater than that of a basic liquid crystal display) as well as an easier process to navigate through menus and make the desirable changes. Despite the positives a touch screen would have brought to a display module the difficulties were not worth it in our humble opinion. First was price difference and since we may need to order backups of each part in case of something going wrong during our building phase next semester we do not want to waste money on an unnecessary component such as having a touch screen interface for the display module. Second is the ability to pass our physical tests (vibration tests). Touch screens are more sensitive than a basic liquid crystal display with a keypad attachment and would have failed or have a much higher probability of failing these tests. Last is the software integration would have been much more difficult which then would have placed an unnecessary burden on us while taking away time from more important factors of the experiment.
Once we decided on using a liquid crystal display with a physical keypad we also decided to find both already integrated together preassembled as opposed to finding first the liquid crystal display and then a compatible physical keypad and then soldering them together or building a panel to make them fit properly in good fashion. By purchasing a preassembled unit we are saving ourselves a great deal of extra work both on the hardware end and software end. The only downfall here is since it is preassembled if one part of the unit (whether it be the liquid crystal display or the physical keypad) goes wrong we most likely would have to purchase another unit, however the unit itself is inexpensive and has no limited availability.
Preassembled liquid crystal displays with a physical keypad were very difficult to find online, however we did find one website with many options. From their selection we came across four strong candidates for the job each with their own set of features. The four models we are currently considering are: CFA533-TMI-
KC, CFA633-TFH-KS, CFA635-TFE-KS1, XES635BK-TMF-KU.
- 107 -
21.1 CFA533-TMI-KC
This unit’s physical keypad consists of: four directional buttons (up down left right), an enter key (check symbol), and a cancel button (red x symbol). It uses a sixteen bit packet-based protocol to transfer inputs and output between it and the microcontroller. The benefit of using a sixteen bit CRC packet-based protocol versus stream-based communication protocol is with the packet based protocol it is much more immune to line noise, environmental interference, and other external factors that could cause the display module to make changes to the experiment that are not as directed by the user. This unit is created for low-light conditions since it has a backlit keypad and liquid crystal display.
The display itself is liquid crystal display with two lines of text and each line can fit up to sixteen characters. See figure 21.1.1 It is designed for low-light or dark environments. It has an edge-lit white light emitting diode (LED) backlight with negative blue liquid crystal display. This means the characters displayed are white on a blue background. This is called negative mode and can be read in normal to dark lit environments, however in extremely sunny and bright environments the display may seem washed out and hard to read.
Figure: 21.1.1. CFA-533 liquid crystal display with physical keyboard.
Brand
Model #
Crystalfontz America, Inc
533
Backlight Type
Backlight Color
Fluid Type
Image (positive or negative)
LCD Glass color
Polarizer Film Type
View Angle (O‘Clock)
LED-
WHITE
STN
Negative
Blue
Transmissive
6:00
-20 to 70 Temperature Range (in degrees
Celsius)
Overall Dimensions (W x H in mm)
Viewing Area (W x H in mm)
110.5 x 35.0
61.0 x 15.8
Weight (in grams) 41
Table 21.1.1 Shows the description of the Crystalfontz America UIM.
- 108 -
The CFA533 can withstand decent environmental factors when considering temperature. As most devices the range of temperatures it can endure depends on the state of the device (operating or non-operating). Under operating conditions the CFA533 can bear an environment as low as negative twenty degrees Celsius (-20 C) and can suffer a maximum temperature of seventy degrees Celsius (70 C). If the CFA533 is not being operating the temperature range it can bear changes slightly. When the CFA533 is in non-operational mode it can only handle a low temperature environment of negative thirty degrees Celsius (-30 C) and a maximum temperature of eighty degrees Celsius
(80 C). In either mode (operational or non-operational) the CFA533 can endure a humidity level of ninety percent (90%).
Brand CrystalFontz
Series
Lowest Temperature in
Non-Operational Mode (in Celsius)
CFA533
-30
80 Highest Temperature in
Non-Operational Mode (in Celsius)
Lowest Temperature in Operational -20
Mode(in Celsius)
Highest Temperature in Operational
Mode(in Celsius)
(in Celsius)
70
Maximum Humidity
(Operational and Non-Operational)
90%
Table 21.1.2 Shows the Crystalfontz’s specs
The CFA533 power supply requirements are minimal (only a single supply is needed) which helps tremendously since it has the potential of being a power hungry had we gone with a more sophisticated display and keypad function.
Luckily only basic information needs to be read on the liquid crystal display and only a few criteria needs to be changed via the physical keypad, thus minimizing how big the display really needs to be and how many physical buttons need to
- 109 -
connected. These factors might persuade us to implement a small battery to power the liquid crystal display as well as the physical keypad and its backlight.
Brand CrystalFontz
Series CFA533
Power Supply Voltage (V
DD
) Minimum 3.3V
Power Supply Voltage (V
DD
) Maximum 5.5V
Pull-in Voltage 3.2V
Drop-out Voltage 3.0V
Items Enabled Typical Current Consumption
+5V for logic (LCD + microcontroller) <20mA
+5V for logic (LCD + microcontroller) + backlight
<100mA
Table 21.1.3 Shows the Crystalfontz’s electrical specs
21.2 CFA633 Serial
The CFA633 is very similar to the previous talked about model with a few differentiations. The CFA633 has a physical keypad that consists of the same four directional buttons (up down left right), an enter key (check symbol), and a cancel button (red x symbol). Additionally it uses a sixteen bit packet-based protocol to transfer inputs and output between it and the microcontroller. As talked about before the benefit of using a sixteen bit CRC packet-based protocol versus stream-based communication protocol is with the packet based protocol it is much more immune to line noise, environmental interference, and other external factors that could cause the display module to make changes to the experiment that are not as directed by the user. The CFA633 has a backlit keypad and liquid crystal display.
The display itself is liquid crystal display with two lines of text and each line can fit up to sixteen characters on each line (16x2). This display was designed for bright environments and can still be read in an environment with a great amount of light present; however this display in turn will be harder to read in low-light or dark environments. It consists of black text on a white background and has an edge-lit white light emitting diode backlight.
- 110 -
Brand
Model #
Backlight Type and Color
Fluid Type
Image (positive or negative)
LCD Glass color
Crystalfontz America, Inc
633
LED-WHITE
FSTN
Positive
Neutral
Polarizer Film Type
View Angle (O‘Clock)
Transmissive
6:00* (Figure 20.2.2)
Temperature Range (in degrees
Celsius)
-20 to 70
Overall Dimensions (W x H in mm) 110.5 x 35.0
Viewing Area (W x H in mm) 61.0 x 15.8
Weight (in grams)
Table 21.2.1 Shows the Crystalfontz 633’s specs
42
Figure 21.2.2
: 6:00 O’clock viewing angle versus a 12:00 O’clock viewing angle
The CFA633 has a similar temperature range as the CFA533. It can withstand a decent range of environmental temperatures but again this also depends on the current state of the display (whether it is in the operational mode or non-
- 111 -
operational mode). If the CFA633 is in operational mode then it can bear an environment as low as negative twenty degrees Celsius or as high as seventy degrees Celsius. If the CFA633 is in a non-operational mode then it can endure a low temperature environment of negative thirty degrees Celsius and a maximum temperature of eighty degrees Celsius. In terms of humidity, the
CFA633 can handle an environment of ten percent humidity to ninety percent humidity non-condensing.
Brand CrystalFontz
Series CFA533
Lowest Temperature Non-Operational
Mode (in Celsius)
Highest Temperature Non-Operational
Mode (in Celsius)
-30
80
Lowest Temperature Operational
Mode (in Celsius)
Highest Temperature Operational
Mode (in Celsius)
Minimum and Maximum Humidity
(non-condensing)
-20
70
10%-80%
Table 20.2.2 Shows the Crystalfontz CF 533 ’s temperature and humidity specs
One major difference between the CFA633 and the CFA533 is the CFA633 has included fans which have their own separate uses depending the experiment or project it is being integrated into. With our project we most likely will not need these fans however we must be aware of their effect on power consumption.
This model series has a slightly different voltage range than the similar CFA533 because of said fans and even though our experiment at this current stage does not need these fans it may be useful in the future.
- 112 -
Brand
Model #
Voltage for LCD Module Minimum
CrystalFontz
CFA633
+4.75v
Voltage for LCD Module Nominal
Voltage for LCD Module Maximum
+5.0v
+5.25v
Supply voltage for backlight Minimum +11v
Supply voltage for backlight Nominal +12v
Supply voltage for backlight Maximum +13v
Supply voltage to run fans Minimum +4.75v
Supply voltage to run fans Nominal +12v
Supply voltage to run fans Maximum +13
Typical Current Consumption
+5v for logic (LCD + microcontroller
Specification
12 mA
+12v for backlight (at 100%)
Note**
TBD by manufacturer
**Maximum continuous current draw must be <1.5 A per fan connecter
(total 4 fan connectors) but no more than a total of 4 A (for all 4 fan connecters being connected)
Table 21.2.3 Shows the Crystalfontz CFA633’s electrical specs
21.3 CFA635 Serial
The CFA635 adds on to a set of features as previously mentioned in the last two examples made by Crystalfontz. The most notable difference with this particular model is the bigger display (which will be discussed in a moment). The CFA635 retains the same button layout with four directional buttons, one enter button
(depicted by a green check), and a cancel button (depicted by a red ‘x’). This model takes advantage of a sixteen bit packet-based protocol to transfer inputs and output between it and the microcontroller. The benefit of using a sixteen bit
CRC packet-based protocol versus stream-based communication protocol is with the packet based protocol it is more immune to line noise, environmental
- 113 -
interference, and other external factors that could cause the display module to make changes to the experiment that are not as directed by the user. This is important because once the experiment is in flight we do not want any changes made that would alter the results negatively.
The display is twice as big height wise than the previous models (CFA533 and
CFA633). The CFA635’s display is twenty characters per line of a total of lines on a liquid crystal display yet it maintains a encasement (only thirty seven millimeters in height). The CFA635 has a white edge backlight powered by light emitting diodes and the background is neutral (meaning it is a light background) with dark characters to display. An extra feature included in the CFA635 is that the light emitting diode indicators (four of them) are all bicolor (red and green) and can be controlled by a host software giving us the ability to change the colors
(such as yellow or orange). We could use this to hint at what menu or submenu the user is in. The characters on the liquid crystal display are also contiguous in the ‘x’ and ‘y’ directions so we could program the display bar graphs without gaps in either a horizontal or vertical direction. There is also a “Scrolling Marquee” feature that will allow us to produce a message that will continuously scroll across the display. This feature could be useful to inform the user of the current settings of the experiment.
Brand Crystalfontz America, Inc
Model # 635
Backlight Type
Backlight Color
Fluid Type
Image (positive or negative)
LCD Glass color
Polarizer Film Type
View Angle (O‘Clock)
LED
WHITE
FSTN
Positive
Neutral
Transflective
12:00
Temperature Range (degrees Celsius) 0 to 50
Overall Dimensions (W x H in mm) 142.0 x 37.0
Viewing Area (W x H in mm) 82.95 x 27.50
Weight (in grams) 71
Table 21.3.1 Shows the basic description of the Crystalfontz 635
- 114 -
One downfall for the bigger more complex yet versatile display of the CFA635 is its lower capacity to handle more extreme environments. The temperature range for both operational and non-operational modes is not as capable as the previous models. When the CFA635 is in operational mode it can a temperature as low as zero degrees Celsius and a temperature as high as fifty degrees Celsius. In nonoperational mode the CFA635 does slightly better withstanding environmental temperatures. It can withstand a temperature environment as low as negative ten degrees Celsius and as high as sixty degrees Celsius.
Brand Crystalfontz
Model #
Operating Temperature
(Minimum in Celsius)
CFA635
0
50 Operating Temperature
Maximum in Celsius)
Non-Operating Temperature
(Minimum in Celsius)
-10
Non-Operating Temperature 60
(Maximum in Celsius)
Table 21.3.2 Shows the Crystalfontz 635 operating and non operating temperatures
This unit also brings its own variations to power consumption requirements and limits. Since the CFA635 model has an additional four light emitting diodes to the display the voltage range is a bit more complex depending on what features we decide to use. The current consumption increases dramatically if we activate the backlights and use all light emitting diodes.
- 115 -
Brand
Model #
Voltage Supply Minimum
Voltage Supply Nominal
Voltage Supply Maximum
Items In Use
LCD and Keypad
Backlights
All LEDS’s
(4 Red + 4 Green)
OFF
ON
OFF
OF
OFF
ON
ON
ON
GPIO Current Limits
Crystalfontz
CFA635
+4.75v
+5.0v
+5.25v
V dd
Current Consumption
= 4.75v
24 mA
109 mA
140 mA
225 mA
V dd
= 5.25v
26 mA
131 mA
162 mA
267 mA
Specification
25 mA
10 mA
Sink
Source
Table 21.3.3 Shows the Crystalfontz 635 electrical specs.
21.4 XES635BK-TMF-KU USB
The XES635BK-TMF-KU has a similar display ability as the CFA635 but with different color features. The XES635BK-TMF-KU liquid crystal display with a physical keypad that includes the standard (as compared with the previous models) four directional buttons, the enter key (depicted by the green check), and the cancel button (depicted by a red ‘x’). The XES635BK-TMF-KU is different from the previous models in that it has a universal serial bus (USB) interface rather than a serial interface. There is an integrated white edge light emitting diode backlight for the keypad and the. Just like the CFA635 there are four bicolor (red and green) light emitting diodes that are controlled by software written into the host; also the light emitting diodes brightness can be controlled by software written to the host.
- 116 -
The display has a couple of more features than the CFA635. There are three color options that can be implemented into the display. You can have a yellowishgreen backlight display in “positive” mode and the keypad can be backlit with the same yellowish-green backlight. Another option is having a white ba cklight display in “negative” mode but with the keypad being illuminated by a blue backlight. Finally, we can have a white backlit display in “positive” mode with a keypad illuminated by a white backlight. A similar feature between the
XES635BK-TMF-KU and the CFA635 is the characters being displayed are contiguous in both the ‘x’ and ‘y’ direction allowing to display bar graphs without gaps in either the vertical and horizontal direction. The XES635BK-TMF-KU and
CFA635 also share the ability to have a “Scrolling Marquee” on the display.
Brand Crystalfontz America, Inc
Model # XES635BK-TMF-KU
Backlight Type
Backlight Color
Fluid Type
Image (positive or negative)
LCD Glass color
Polarizer Film Type
View Angle (O‘Clock)
LED
WHITE
STN
Negative
Blue
Transmissive
12:00
Temperature Range (degrees Celsius) 0 to 50
Overall Dimensions (W x H in mm) 145.0 x 39.29
Viewing Area (W x H in mm) 80.95 x 25.50
Weight (in grams) 297 (this includes case and cables)
Table 21.4.1 Shows the basic description of the Crystalfontz XES635BK-TMF-KU
Like all devices discusses so far the XES635BK-TMF-KU has a temperature endurance unique to both operational and non-operational modes. These specifications are shared with the somewhat similar CFA635. In operational mode the XES635BK-TMF-KU can withstand a minimum of zero degrees Celsius and a maximum of fifty degrees Celsius; however in non-operational mode the
- 117 -
XES635BK-TMF-KU can do a little better and bear an environment as low as negative ten degrees Celsius and as high as sixty degrees Celsius.
Brand Crystalfontz
Model #
Operational Temperature
(Minimum in Celsius)
Operational Temperature
(Maximum in Celsius)
XES635BK-TMF-KU
0
50
Non-Operational Temperature
(Minimum in Celsius)
Non-Operational Temperature
(Maximum in Celsius)
-10
60
Table 21.4.2 Shows the Crystalfontz XES635BK-TMF-KU operating and non operating temperatures.
The voltage requirements are very similar as the CFA635 with the exception of fan usage specifications. The XES635BK-TMF-KU also uses its universal serial bus (USB) interface to draw power from the power source.
- 118 -
Brand
Model #
Voltage Supply Minimum
Voltage Supply Nominal
Voltage Supply Maximum
Items In Use
LCD and Keypad
Backlights
All LEDS’s
(4 Red + 4 Green)
OFF
ON
OFF
OF
OFF
ON
ON
ON
GPIO Current Limits
Sink
Crystalfontz
XES635BK-TMF-KU
+4.75v
+5.0v
+5.25v
V dd
Current Consumption
= 4.75v
35 mA
129 mA
147 mA
239 mA
Specification
25 mA
V dd
= 5.25v
42 mA
161 mA
175 mA
290 mA
Source 10 mA
Table 21.4.3 Shows the Crystalf ontz XES635BK-TMF-KU electrical specs.
22.0 Display Module Testing
There will be many tedious tests that have to take place with the display module.
One type being the physical, in other words testing the menu display and making sure the physical buttons actually responds appropriately. The other type of tests will be of the virtual kind, as in making sure the microcontroller is accurately reading in the inputs from the display module. Both are important and crucial to the experiment and will have to be tested one by one.
The first test is making sure the physical buttons and display do what they are meant to do. The display will have to show the menu and a scrolling marquee when prompted of the current settings. The scrolling marquee will include some core configurations of the experiment in its current state, such as: length of
- 119 -
experiment in time and delay after entering micro-gravity to begin the experiment.
Since this part of the testing is only the physical and not the virtual the display module will only be tested to make sure it has the capability of displaying a scrolling marquee. This requires a simple print out to the display of sample text to make sure this feature is working properly.
For the physical keypad there must be a menu with several submenus programmed into the display module that is being displayed and have the ability to navigate to. There will also be useless variables within some of these submenus that can be altered by the physical keypad. To test the navigation a menu and several submenus will be programmed into the display module, then the arrow keys as well as the enter key (this is the key with the green check on it) will be used to guide the user throughout the menu and its submenus; additionally the cancel button (this is the button with a red ‘x’ marked on it) should give the ability to return to the previous menu. Once each menu and its submenus has been reached using a combination of the left and right arrow buttons as well as the “enter” and cancel buttons this part of the test will have been completed.
The last part to test is the combination of the up and down arrow buttons and the
“enter” buttons to change values of variables capable of being modified within the menu. There will be a few variables available for modification throughout the submenus and using the up and down arrow buttons will change the value of the variable while the “enter” button will save the new value to the variable or the cancel button will exit the submenu without saving any changes and leaving the original value intact. The last physical test of the display module will be the use of the light emitting diodes on the left hand side of the display. There will be certain tests made to use each one of them under certain conditions. A solid purpose for these light emitting diodes has yet to be established but more than likely they will be of some service to the experiment.
The next series of tests will make sure that the lines of data communication between the display module and the microcontroller are working properly. In order to make sure this is working as its supposed to the light emitting diode attachment to the microcontroller will be taken advantage of. One test will include a simple push of the up or down buttons on the keypad. With each input the light emitting diode should go off and then back on. This will indicate that there is data transmitting from the user input to the microcontroller in the most basic form. The next test will involve the “enter” button and the cancel button.
Once the “enter” button is pressed the light emitting diode should continue to stay illuminated until the cancel button is pressed. This helps determine that the function of these buttons are working as they should be.
Another test to be placed concerns the value of a variable within one of the submenus. The light emitting diode should not turn on unless the value of this variable increases past a certain amount. The success of this test gives the
- 120 -
indication that both communication and memory storage is functioning properly, in other words if a scientist or researcher decides to change the values or configurations of the experiment this is the test that confirms that ability. A variable will be stored within a submenu and once the user has navigated to the varia ble the user will then press the “enter” button to change the value of the variable. The user will only increase the variable by one using the up arrow button. The “enter” button will be pressed again to save the new value and the liquid crystal display should have a scrolling marquee identifying the new state of configurations for the experiment. The light should not be turned on yet. This process should occur enough times until the value of the variable has reached the limit set to turn on the light emitting diode, which should turn on until the
“enter” button has been pressed by the user. A final test will conclude that once the configurations of the experiment have changed it can be changed back. This will be similar to the previous test except it will be extended a few steps. After increasing the value of the variable enough to turn on the light emitting diode the user should now decrease the value of the variable one by one by using the down arrow key and the “enter” button until the value of the variable is lower than the limit to keep the light emitting diode and it turns off once the user presses the
“enter” button.
After carefully researching and working hard on our project. We decided not to use the keypad to change the variables. Instead, we will be using a bluetooth doogle that will be connected to a laptop and the P820. This way, the user can change the variable wirelessly without having to touch the display. Also, we could control multiple experiments at once without having to change each experiment individually. The keypad will not be used to navigate through the menu, make selections, and change the current state of the experiment anymore with this new feature being infused.
23.0 Schedule/Milestones
Most people would under estimate the milestones, but as a whole it actually is a very useful part of our senior design project. Our schedule and milestones gives us a quick preview of where we should be and let us know if we are behind or have some slack. As a group of four, we all have different schedule and time limitations, but we have developed our milestones together. It helps us estimate where we must reach at which date. Without a schedule or milestones that we must meet, we would probably get off track and everything would be very stressful at the end.
Our initial steps were to decide on the project, which was very quickly decided as soon as our group was formed. We actually had our group picked out already the semester before so we knew what we were getting our self into. We know that each member of our group would pull their own weight and meet their milestones. Everything kicked off great because one of our group members, Josh
- 121 -
Steele already had the project for us sponsored by his job in the Physical
Science building. Dr. Josh Colwell is his boss and our sponsor for this project. It is a big project and will be a challenge.
One of the first things we should do is set up a meeting with Dr. Josh Colwell, but unfortunately we have not met with him yet. On the other hand, Josh works for him so he talks to him on a regular basis. We rely on him for information of the project and sponsorship legitimacy. We planned to meet with him as soon as possible. The first real milestone that actually initiated work is the research. We decided to meet up at least once a month to see how we all were coming along.
We also met after senior design class to talk about quick ideas and have discussing. The hardest milestone to meet is the start of the documentation. After the rough draft review, we plan on finishing up our final documentation and order parts for next semester to build. Our goals and milestones for Senior Design 2 is reasonable and doable. We must follow and abide by these dated milestones to finish our project.
23.1 Senior Design 1
Our goals and milestones for Senior Design 1 on our Collide 3 AVM project were half real and half idea of what we would like to happen. Meeting our milestones, we were successful for the most part as far as meetings and keeping track of what we need to do. On the other hand, researching what we need to know about our senior design project and starting to write about our senior design project was not as easy as we thought it would be. In most of our meetings which we had to discuss our project progress, we were only able to complete a portion of our milestone. We were never able to finish one hundred percent of what we wanted to be done.
There were some milestones that were pushed back such as our meeting with
Dr. Josh Colwell, which pushed our research back a little further because we did not get the info we needed to continue our research. With that aside, we manage to still continue and pushed on to the next topic so we do not get too far behind.
We eventually did meet with Dr. Josh Colwell in his lab and he was able to show us a sample of what he wants the Collide AVM to look like from previous models.
It gave us a better understanding of what he wanted and how the project should look like, but it was quite different. The older Collide AVM used a whole motherboard with hard drives and all like a computer. Of course we are not allowed to use a motherboard or anything that is premade. Thus, we have a lot on our plate as to using a microcontroller or a FPGA board, but that is what we expected to happen.
We expected our project to be hard and challenging. We have 6 meetings. These meetings are for us to insure that we are on time. We had to check our research
- 122 -
and writing progress from time to time. These meetings are also for us to discuss what we need to accomplish in the time frame that it needs to be done. Without meetings, we would probably not know our position and where we stand. Thus, meetings are also important for the milestones.
Task Name Initial Date
Planned
Date
Process
%
Successf ul
Project decision 08/30/11 08/30/11 100%
11/01/11 11/26/11 100% Meeting with Dr. Josh Colwell to discuss the project
Project discussion and splits of categories for each person
Start researching
Finished researching
Start paper
09/04/11
09/11/11
11/20/11
09/15/11
09/04/11
09/15/11
01/12/12
09/18/11
100%
100%
100%
100%
Finished paper to turn in
Set date to review/ rough paper
Ordering Hardware
Meet 1 Decision
Meet 2 Discussion
Meet 3 Research/Paper
Meet 4 Research/Paper
12/05/11
11/17/11
12/05/11
08/30/11
09/04/11
10/02/11
10/23/11
12/05/11
11/17/11
02/28/12
08/30/11
09/04/11
10/02/11
10/23/11
100%
100%
100%
100%
100%
100%
100%
100%
100%
Meet 5 Research/Paper
Meet 6 Research/Paper and to wrap up anything we need to
11/13/11
12/04/11
Table 23.1.1 Shows our senior design 1 schedules and deadlines .
11/13/11
12/04/11
- 123 -
23.2 Senior Design 2
Our goals and milestones for Senior Design 2 on our Collide 3 AVM project are all accomplish at a good paste. The first thing on our milestones is the coding portion for our project. We put into account that our hardware that we order would not be in yet. Thus, we started the software side which does not need the hardware to work on. Of course we had to check if our codes work by simulating with screen printouts of what happens, when it happens.
Some of our hardware purchases arrived early for us to start integrating the hardware to our designs. That is the second thing we have planned for our milestone. This will be all the hands on work. We had to make sure that the measurements of the ports for each component fits ours design. If our measurements are wrong or off, our components will not fit and we had to re-due the design with new measurements. Everything went smoothly and all of our hardware fits together. The earlier we finish integrating all of our hardware and design, the earlier we started testing our finished product to make sure everything works. There were some delay on some of our parts as well, which kept us from finishing early but we still manage to stay on track and improvised until something better comes along.
Testing was probably the most important functionality of our project. This determined if our project is a success or a fail. We had to make sure that all of the functions after the accelerometer detects micro gravity happens and works well. If it fails on anything that we need for it to do, then we would have to check out coding again. If there is nothing wrong with the coding, then our designed integration is the problem. We had to check both to see if there is anything is wrong before we can say we are done.
We have 5 meetings in our Senior Design 2 milestone. These meetings were to discuss our progress and start what we need to start. We technically meet every time we work on our project because Senior Design 2 is all hands on, but these meetings kept us in check. We need these meetings so we would know where we stand. We do not want to work on our and end up being behind because we do not discuss our progress.
- 124 -
Task Name
Begin writing code
Write code for Accelerometer
Write code for Microcontroller
Write code for DM
Establish Circuit Design
Hardware and parts delivered and in our possession
Start soldering of the Microcontroller
Integrate Accelerometer
Integrate USB(User Input)
Initial Date
Planned
01/15/12
02/13/12
02/26/12
03/04/12
02/22/12
03/13/12
Testing DM
Accelerometer
LED’s
Muscle wire gets activated
Door opens
Camera Activities
Retest all condition with user input
03/14/12
03/18/12
03/20/12
03/20/12
03/21/12
03/25/12
03/27/12
03/28/12
03/30/12
04/07/12
04/01/12
02/03/12
03/20/12
02/20/12
02/15/12
03/25/12
03/25/12
03/25/12
04/01/12
04/02/12
Finish Project
Meet 1 Split for hands on works
Meet 2 Coding progress
Meet 3 Hardware progress
Meet 4 Testing Discussion
04/10/12
01/08/12
01/22/12
02/20/12
03/20/12
04/09/12
01/08/12
01/30/12
03/01/12
03/15/12
Meet 5 Final Meeting 04/10/12
Table 23.2.1 Shows our senior design 2 schedules and deadlines .
- 125 -
04/10/12
Date
Process
01/30/12
02/02/12
02/02/12
02/05/12
02/30/12
03/01/12
%
Successful
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
24.0 Budget and Financing
For our senior design project, we were lucky to have a sponsor. Many other senior design groups probably had to spend hundreds of dollars out of pocket.
Fortunately for us, some of our components are provided for us such as the LED lights, Cameras, and Case (housing). We did have to buy most of the components such as the microcontroller, power sources, the solid state hard drives, ethernet and USB cables, and the accelerometer. We had to buy these components, that is why we had to do deep research and get a really good understand of what we need. We did not want to spend too much and we also do not want to buy things we did not need. Before our research, we did set an estimated price range just so we can have a better understanding of the price for each item. But anything can change as we went further down our senior design project and make progress.
24.1 Budget
Our budget for our project is rounded off to $500. The actual cost of each item is only estimation of what we had found and researched. We estimate that our sponsor provid us with $400 worth of components and equipments, thus the remainder had to add up to $1000 or less. Dr. Colwell did mention that he could also provide us with an additional $600 cash to work with as well.. Thus, our final budget in total is $1,500 if that follows through shown in figure 23.1.1.
40%
26.66%
33.33%
Budget
Our Budget $500
Given Componets $400
Sponsored Cash $600
Figure 24.1.1 The pie chart above shows how our budget is split up in percentage. In Blue is how much we have to actually pull out of pocket from the whole project.
- 126 -
Part
P820
ATmega328
Cost
$310
$3.83
Serial to USB converter $15
Part
SSD
Accelerometer (H48C)
DM
Cost
$79
$31.88
$88
Voltage regulator
Button
Misc. Components
Bluetooth
$2
$1
$5
$40
Relays
Breadboard
LEDs
Micro-step Driver
$10
$12
Included
Included
Muscle Wire Included Cameras Included
Case Included Total $597.71
Table 24.1.1 Shows of our components so far that we have to research and need for our project.
The total price is $597.71 so far.
24.2 Financing
After taking a good look at what we needed to buy and how much we had to spend out of our pocket, we decided on how much each of us will be putting in and if we should cut cost or not. The total amount on our senior design project came out to be about $600. The LED, Camera, and Housing are covered by our sponsor so we do not have to worry about that. Dr. Colwel l’s statements are true, we received $600 in cash from him, leaving our experiment paid for in full without us having to spend a dime. Thus, our percentage spending is only 0% which is awesome compare to other groups. It’s paid for 100% by our sponsor. Since our out of pocket cost is $0, we decided to also invest in spare parts just in case. We did end up spending more money buying more spare parts but it wasn’t enough to really add to the budget. We split the out of pocket cost equally between the four of us for every expense.
- 127 -
25.0 Conclusion
The Collide-3 AVM experiment provided Dr. Josh Colwell another opportunity to study how planets were formed. The AVM part of the Collide-3 is designed to act as a “brain” or manager of the experiment. It includes a display module for quick access to editing the configurations of the experiment. Overall, once the AVM is built and successfully integrated with the rest of the Collide-3 it will give the researchers and scientists at UCF another opportunity to study how planets were formed.
As the economy declines and financial resources become thinner for everybody it is important that money is not wasted on more than what is needed. The AVM will be as financially responsible as it can be. All components considered are of absolute necessity to conduct the experiment and nothing more. Cheaper substitutions have been modified and or are being discussed to continuously reduce the cost of the final experiment while maintaining productivity and experimental standards. The camera has the potential of being replaced by a consumer product that will save the scientists thousands in grant money. The data management of the AVM has been minimized from a Data Acquisition module, which cost a couple of thousand dollars, to a microcontroller that should not be more than a few hundred dollars at most.
Although the cost of the AVM is reduced by thousands of dollars all components are of industry standard and quality was not compromised. The object was creating an efficient AVM on both a financial and technological level; however with lowering costs the by-product of sacrificing state-of-the-art technology for more industry standard parts is a more stubborn process of getting parts to integrate together in a fluid manner.
Some difficulties of the project were more on the virtual side making sure all data is being transferred correctly. The microcontroller must be able to communicate with the display module by adapting to any changes inputted by the user.
Another issue was writing custom drivers for a microcontroller as opposed to being able to load Microsoft Windows and having the drivers widely available. A major issue was programming a working environment for the camera, which has the ability to output data at a very high rate, to store its images on the solid state drive. The lines of communication between these two parts must be very reliable and efficient, otherwise the entire experiment will be a failure.
The research behind planetary formation is vast across the globe and it is a privilege to work towards any possible future discoveries in this field. This project is beneficial on several levels including academically and personally. The AVM will require skill in both electrical engineering and computer science. The project itself will require a high degree of teamwork from all individuals, including Dr.
Josh Calwell.
- 128 -
26.0 Citations
[1] Xilinx TDS for Virtex-5QV Device Overview. DS192, Rev. 1.2.
2011. Xilinx, Inc. 10 NOV. 2011 < http://www.xilinx.com/support/documentation/data_sheets/ds192.pdf
>
[2] Xilinx TDS for 7 Series FPGAs Overview. DS180, Rev. 1.8.
2011. Xilinx, Inc. 10 NOV. 2011 < http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf
>
[3] Xilinx TDS for Space-Grade Virtex-4QV Family Overview. DS653, Rev. 2.0.
2010. Xilinx, Inc. 10
NOV. 2011 < http://www.xilinx.com/support/documentation/data_sheets/ds653.pdf
>
[4] Salem, Mohamed A. "Serial ATA and the Evolution in Data Storage Technology." EE Times.
Mentor Graphics Corp., 28 Apr. 2008. Web. 10 Nov. 2011.
<http://www.eetimes.com/design/eda-design/4018543/Serial-ATA-and-the-evolution-in-datastorage-technology>.
[5] Navabi, Zainalabedin. Embedded Core Design with FPGAs. New York: McGraw-Hill, 2007.
Print.
[6] "Single Event Upsets." FPGA CPLD and ASIC from Altera. Altera. Web. 11 Nov. 2011.
<http://www.altera.com/support/devices/reliability/seu/seu-index.html>.
[7] Grimsrud, Knut, and Hubbert Smith. Serial ATA Storage Architecture and Applications:
Designing High-performance, Cost-effective I/O Solutions. Hillsboro, OR: Intel, 2003. Print.
[8] ARC Electronics, “RS232 Data Interface, a Tutorial on Data Interface and cables," 2010, http://www.arcelect.com/rs232.htm
[9] Brittanica.com, “Liquid Crystal Display”, 2010, http://www.britannica.com/EBchecked/topic/343093/liquid-crystal-display
[10] EHow.com, “LED vs. LCD Displays”, 1999-2010 http://www.ehow.com/facts_5839894_led-vs_-lcd-displays.html
[11] Globalspec.com, “Liquid Crystal Display (LCD) Modules Specifications”,
1999-2010 http://www.globalspec.com/Specifications/Video_Imaging_Equipment/Meters
_Readouts_Indicators/Liquid_Crystal_Display_LCD_Modules
[12] IDC Technologies, “Industrial Data Communications –RS-232/RS-485," 2010, http://www.idconline.com/technical_references/tutorials/data_communications
/tutorial_2.pdf
[13] Crystalfontz, LCD with keypad 1999-2011 http://www.crystalfontz.com
- 129 -
