Team:Cornell/testing/project/drylab/3

Functional Requirements

In the development of our device, we first had to establish a set of requirements and constraints.

What sets these constraints? Our ambitions and our "customer," the Wetlab Team.

We sat down with them and came up with the following:

1. The device must operate independently for at least 6 months.
2. The device must be based around an established Shewanella onidensis bioreactor setup for Arsenic and Napthelene biosensing..
    a. Reactor size must be 100mL in volume
    b. Reactors must have 3 electrodes; 1 reference, 1 working, 1 counter.
    c. The potential difference between electrodes must be measured by potentiostat, or an equivalently performing device.
    d. The electrodes should have maximum surface area inside the reactor.
    e. The electrodes should be in closest proximity without touching.
3. The bioreactor must remain free from foreign microbes; incoming analyte must be cleaned from foreign microbes.
4. Waste water must be microbe-free upon ejection.
5. The device must be field-deployable.
6. The device must store and transmit measured data remotely.
7. System components should be modular, for ease of servicing, and interchangeability.

From these requirements we listed out parameters, split into research groups, and began trying to develop some solid constraints. What did "field-deployable" mean to us? How were we going to transmit data? Or what did 6 month independent operation entail?

We needed to establish our base constraints, and base components. To answer these questions, we began to perform research and engage in brainstorming. The team was divided into "Component Teams" - Each component team would be responsible for researching some aspect of the design (power, inputs, pumps) and become the expert on their piece.

The mind map below illustrates the parameters we associated which each base issue.

Concept Generation

After defining the functional requirements for the biosensor device, Dry Lab members held a general brainstorming session to pool ideas for various aspects of a system that could sustain bacterial culture and immerse the microorganisms in a water source without contaminating that reservoir.

First, we were assigned broad topics relevant to the system, such as pump, food delivery and power source. Working individually or in pairs, members listed and sketched ideas with open minds. We then silently exchanged our notes and made comments on Post-Its; this method allowed everyone to have a voice in each topic. After all comments and questions were written down, notes and sketches with accompanying commentary were returned to respective members so that they could briefly build off of the critique. We then took turns explaining, clarifying and even questioning our ideas to the rest of the group. At the end of the general session, we had a good sense of direction for each topic.

Outside of the team, we individually researched products and designs corresponding to our assigned topics. We prepared presentations of three designs that emphasized different desirable qualities, such as high efficiency, light weight or low cost. At following brainstorming sessions, we exhibited these designs, and followed up with questions and comments. We repeated this process for a series of meetings in order to refine and find concepts that best satisfied the functional requirements.

Primary Components and Constraints

Once we'd established our core requirements, we needed to develop some base constraints and systems. Namely, we had to approximate at our heaviest power draw - pumping systems, and set a suitable powerplant system

Pumps:
The pumps were one of the toughest engineering challenges for us. The flow rate had to be small enough so that the water did not damage the bacteria and that the bacteria would have enough time to consume the heavy metals in the stream. Another constraint essential for our device to work was that the pumps had to last for 6 months without maintenance. This meant that the pumps’ voltage draw had to be small enough for it to last with the battery installed in the pelican case and the solar panel.

Overall the flow rate was determined to be as low as 0.033 mL/min. This meant that we had to use micropumps to get the job done because no heavy duty pump would have a flow rate small enough to meet this requirement.

One micropump that we used was from a manufacturer from Germany. However, these micropumps did not have high enough pressure head to make the water pass through the filters in the device. This meant that we had to find micropumps with higher pressure that would also meet the flow rate of 0.033 mL/min. We then found a special manufacturer in Britain that created micropumps and purchased their MG 1000 pumps which were strong enough and slow enough to satisfy our requirements.

Power
Calculations with our pumps led to the choice of a 100ah battery.

We decided to use lead acid battery for our system from a set of battery types. Initially, we were against using lead acid because it has rapid discharge, low specific energy density, low cycle life, long charging time, and toxicity. However, lead Acid battery works well and can be charged in wide temperature ranges (-4 to 113 degrees F) while other types of batteries cannot do the same. Sealed lead acid battery is reliable under water. By implementing solar cells, we figured we could resolve the issue of rapid discharge and long charging time.

Secondary Systems

WIth our primary systems in place, we were able to develop our secondary systems.

Potentiostat
The potentiostat is a three-electrode circuit that helps us assign numerical values to the current production in our bioreactor. It is an electrical component that is adaptable to the different conditions in which our bioreactor chambers could be placed, which is useful for obtaining consistent data. As water conditions change the rate of cell growth and current production, the potentiostat will read the electrical current across one of the three electrodes, the counting electrode. The current that is read by this electrode will reflect cell reactions in the chamber since the voltage across the cell will be constant. With respect to the other two electrodes, the Reference (Ref) and Working Electrodes (WE), the reference electrode will output a constant voltage with respect to the working electrode.

Since the electrical current data from the potentiostat is useful for determining the current production in the bioreactor, digitally reading the data, and potentially storing it for post-processing, would be a useful functionality. Thus, the potentiostat component is implemented using an ATMega2560 microcontroller mounted on an Arduino Mega ADK for Android board. The microcontroller outputs a constant voltage to the electrode circuit in the bioreactor, and also uses an analog-to-digital (ADC) converter to change the current reading of the reactor to a digital representation with a precision between 8 and 12 bits, depending on the ADC used and the ADC sampling rate.

ATMega2560 Microcontroller
The ATMega2560 is the microcontroller we used to implement the real-time analog current sampling, digital data conversion and storage, and constant voltage output functionalities of the potentiostat. It is a microcontroller from Atmel Corporation, and our Mega ADK board is from Arduino. [Take picture?] The microcontroller has a built-in ADC, and is also capable of using serial communication-- called Universal Synchronous/Asynchronous Receiver/Transmitter (USART)-- to output data to a serial console (such as PuTTY) on the computer. The first steps we took to building the full-fledged potentiostat was to use the microcontroller to sample analog signals from the real world and save it digitally on the microcontroller, then output the data through USART to view it on a computer screen. This would verify that the samples are taken correctly.

Serial Communication (USART)
Serial communication, the process of sending data in bits one at a time, was accomplished through an FTDI cable from the microcontroller to the computer. The FTDI cable is a USB to TTL Serial Cable (3.3V), where the USB plugs straight into the computer and the TTL end includes a transmission and receiving, as well as ground, wire that interfaces with the ports on the ATMega2560. We used this FTDI cable in order to output the data stored in the microcontroller to the computer. This output is useful because it gives us a way of probing the microcontroller's memory. In order to test our ADC conversion, we needed to have a way of viewing the values that the microcontroller's internal ADC were producing. Thus, we sent the converted data over through the cable to a serial console on the computer. The serial communication protocol is called USART, also known as Universal Synchronous/Asynchronous Receiver/Transmitter protocol to transmit bits of data. We tested the serial output on several serial consoles, such as PuTTY, TeraTerm, and RealTerm; all three were able to receive and output data consistently, as expected. In addition, all three consoles can be downloaded for free online.

Analog-To-Digital Conversion
Analog-to-digital conversion, also known as ADC, is used in the potentiostat to take in the current reading from the bioreactor and store the data in 8 to 12 bits in the microcontroller. The ATMega2560 microcontroller built in the Mega ADK board has a built-in ADC that is 10-bit. The ADC is by default disabled, but it can be enabled by setting the bits in an ADC register. Other ADC-specific registers were also set to specify the time of start of the ADC conversion, the number of bits we would read from the conversion, the speed of the conversion, the number of channels used, and the internal voltage reference (which also determines the range of voltage that can be sampled). Depending on the speed of the ADC conversion, which is adjustable by a clock prescalar, we can get different accuracies from the ADC. For example, if we prescale the ADC clock to sample at a frequency of 1MHz, then the accuracy, according to the ADC characteristics specified on the ATMega2560 datasheet, of our conversion (out of 10 bits) would be 7 bits on average.

We used a DC voltage supply and function generator to test our ADC. Since we set the voltage reference selection of the ADC to be AVCC, we could sample a voltage ranage from 0V to approximately 5V. We scaled the ADC clock to be about 1MHz, since the slower prescalars would take longer to convert. This is because the ADC works by converting one bit at a time, or successive approximation. However, this left us with about 7 bits of accurate sampling, so we shifted the most significant 8 bits out of the 10-bit conversion to an 8-bit register, called ADCH for adc high. Then we printed the decimal equivalent of the 8 bits out through USART. By varying the voltage input, we saw a range of numerical ADC representations from 0 (0V) to 255 (about 5V). The highest value is 255 because 8 bits can only represent a maximum of 2^8-1 = 255. Because the values output on the serial terminal increased as we increased the voltage level, we were able to verify that the ADC was working correctly.

In addition, we set the function generator to output different waveforms, such as a sinusoidal wave. We used the ADC to sample the waveforms at small intervals, and saved the datapoints on the computer. Utilizing MATLAB to plot the datapoints, we were able to reconstruct a similar waveform to the one we expected. We varied frequency and confirmed that the waveforms seen on MATLAB were also different. We have not been able to reconstruct the waveform exactly, because the frequency depicted in MATLAB is much faster than we expected. The reason for this could be because of aliasing, which we have not yet been able to confirm. Despite the inaccuracy from reconstructing a sinusoidal waveform, we are still sure that the ADC samples individual voltages correctly. Thus, we will be able to apply this ADC in potentiostat circuitry, which is currently a work in progress.

Chassis
The mechanical design process of the chassis changed significantly from the initial designs. The base requirement for the chassis meant that it had to be completely waterproof because it would be on the surface of the water so this meant that the electrical components could not get wet. Another requirement that we looked at was keeping this floating in the water with the load of the equipment inside from pulling it down. The equipment’s weight ranged from 60 to 80 pounds. Therefore the volume had to be large enough to allow for all the weight of the device to remain afloat.

We first looked at several designs where we implemented our own machined outer surface as our mechanical chassis. There were many ideas that would have gotten the job done but the toughest parameter of keeping the device waterproof proved too challenging for us to make our own chassis. This problem led to the most ridiculous ideas such as building our own 3D printer or purchasing a 3D printer to construct the entire chassis which would have worked but the time constraint of building the printer and the cost would have been too great.

Ultimately, we resorted to purchasing a simple box that could satisfy all the parameters that we needed for our mechanical chassis and was flexible enough for us to modify. After many Google searches, we found the Pelican case.

The Pelican case is a heavy duty case that is frequently used by the army to store their materials. The cases are waterproof and are rigid enough to withstand the force of many objects commonly found in rivers like tree branches and rocks. This, however, excluded bear attacks, shark bites, and children under 5. But, our design parameters will only keep the Pelican case in fresh water streams where it is uncommon to find bears, sharks, and children under 5, so these hazardous objects will not obstruct our device.

We modified the chassis to carry a solar panel by attaching L-brackets to the front of the Pelican case and used Velcro pieces to keep the solar panel from moving around and falling off. We created a few holes in the box and inserted steel pipes as a means of allowing the stream water to enter and exit our device. We also created an elbow joint which covered the wires that were being routed to the inside of the Pelican case as a way to keep our electronics from getting wet.

Server
Overview: For convenience, the biosensor was developed to have the ability to send data wirelessly to a database. Thus, the need to physically check up on the biosensor was removed. This was done by sending apparatus data, such as voltage or battery level, to the android phone. There, the phone packaged the information and sent it to a MySQL server via 3G network. The database then stored the information for display on a website.

Design Choices: The android phone was chosen as the best fit for the project for multiple reasons. For one, it was easier to code for android than for the alternatives. There existed a wide and extensive range of support for android development that did not exist on other platforms. These included tools such as the Apache API that allowed the project to run more smoothly. Most importantly, the android device was not bound to distance restrictions as the other alternatives were. As long as a cell tower was nearby, the information could be accessed from anywhere with an internet connection.

The program used to run the server and its code was WAMP Server for ease of use. Other alternatives, such as developing and using a socket server, were also proposed and implemented. However, WAMP Server allowed for a more elegant testing and debugging process.