Manoj Lamba (MKL28) and Ian Wang (ILW4)
Monday 4:30pm Lab
Overview
The CUAUV Sniffer serves to aid in debugging the origin of failures in an autonomous submarine by monitoring and logging pertinent voltage, temperature, and light data.
Contents |
Figure 1. The CUAUV Sniffer (v1) |
The Cornell University Autonomous Underwater Vehicle team (CUAUV) is an undergraduate engineering team that designs and builds a fully autonomous, robotic submarine. Over the past year, the team – of which both Manoj Lamba and Ian Wang are members – has had a stringent policy of testing the vehicle weekly at Cornell’s Teagle pool. Each session focuses its three hours on testing a few components within the vehicle (e.g. thruster control). When the vehicle experiences a failure that affects the onboard computer, the current logging system is rendered useless. Thus, post “pool test” debugging involves hours of studying the vehicle, attempting to locate the origin of the vehicle failure. Since all components, including the microprocessors, are not only powered by one source but also interconnected, the motivation for designing an independent device that can monitor various nodes in the vehicle, log the data, and be self-powered during the pool test is clear.
The CUAUV Sniffer aims to accomplish the task of independently monitoring and recording data from three types of sensors: voltage sensors (for three nodes), temperature sensor, and light sensor. The Sniffer features a custom-designed printed circuit board with the Atmel MEGA32 microcontroller, serial interface, programmability via an STK500, and the capability of logging from five sensors onto 16 Mb FLASH. The FLASH can be read using a serial client (e.g. Hyperterm).
Rationale and Source of Ideas
As stated before, the rationale of the CUAUV Sniffer is to aid with debugging submarine component failures that end with microprocessor shutdown. Additionally, the device will feed current sensor data to the vehicle’s microprocessor so that members can monitor conditions within the vehicle during a test.
Ideally, a team member could take the Sniffer out of the vehicle, connect it to a computer via RS232 and look at the latest data stored in FLASH for three voltage nodes, the temperature, and the light. Recording voltages in three locations of the vehicle will help in narrowing down where a failure first occurred by looking for spikes in voltages or sharp drops. Noting the temperature will allow the team to determine if overheating is occurring within the submarine’s hull. Lastly, light is used as a sensor so that one knows whether or not the “rack” (the rack secures and fastens all boards to minimize movement within the vehicle) is sealed shut within the hull.
The idea for this project resulted from our own thoughts on what Atmel microcontroller-based project would most benefit the team as well as the advice of a CUAUV electrical leader, Sam Fladung ’08.
Logical Structure
Figure 2. Block Diagram Structure of CUAUV Sniffer
The CUAUV Sniffer sensor board is based around the AVR Atmega32 RISC microcontroller, as shown in Figure 1. This project puts to use the onboard SPI capability for reading and writing to FLASH, UART (or USART) for serial peripheral communication with the vehicle’s processor, and the ADC for converting the sensor signals to bytes for data logging.
The 16Mb Atmel DataFLASH (AT45DB161B-RC ) requires a voltage supply between 2.7V and 3.6V for operation. Thus, the chip cannot use the same supply voltage as that for the Atmega32 (from the 5V regulator). To fix this problem, the Buffer/Level Shifter performs a 3.3V to 5V shift for the SPI signals to and from DataFLASH.
For communication, the ATMega32 and the vehicle’s processor (represented in Figure 1 as “PC (Serial)” must be connected by an RS-232 driver/receiver chip. The Maxim integrated circuit MAX233A accomplishes this task with only one external capacitor required. Other RS-232 driver/receiver chips would require more external hardware, taking up space on an already crowded sensor board. This communication between the processor at the ATMega32 is for determining the state of the Sniffer (please see Figure 7 for the Sniffer State Machine) – if it should continuously log data, to stop logging, or to dump data out for debugging.
The final major component of the CUAUV Sniffer is the sensor array, consisting of five sensors: three to monitor voltage nodes, one for temperature, and one for light. This data is read on a continuous spectrum and must, therefore, be processed in the onboard ADC into one byte (while the ADC can output up to 10 bits, using only 8 will save memory in DataFLASH and still satisfy our requirements for logging the pertinent information. The digital data is then stored in FLASH (by sending over SPI) until it is overwritten or the memory is cleared.
Information transfer and packet protocol, the state machine, and other specifics necessary for understanding the operation of the CUAUV Sniffer will be discussed in the Program/Hardware Design section.
Relationship of Design to Available Standards
The CUAUV Sniffer uses the Recommended Standard 232 (RS-232) for serial binary communication between the PC and the AVR. The implementation of RS-232 used is with a BAUD rate of 9600 Bps, 8 bits, no parity bit, 1 stop bit, and no flow control.
Though not implemented by the due date of this project, the members will continue to add functionality to the CUAUV Sniffer by implementing I2C (inter-integrated circuit) 2-wire bidirectional communication. This standard will allow for extendibility of the monitoring network by allowing additional sensor boards to be added by communicating with each other over I2C.
Existing Patents, Copyrights, and Trademarks
A number of patents were granted for vehicular data logging systems in the early to late 1990s. These logging systems, however, are car-specific, and monitor such events as vehicle speed and vehicle collisions. Thus, the vehicle and types of sensors are different (Two examples of these patents are U.S. Patent #6141610 and U.S. Patent #6795759). Thus, we are not worried about patent or copyright infringement. The logo used for the CUAUV Sniffer project is a derivative of the current CUAUV logo. Though it is not trademarked, we feel comfortable using this logo for a project that will be eventually meshed with the current CUAUV submarine.
If any issues arise with regards to patents, copyrights, or trademarks, we will quickly fix the situation in our constant adherence to the IEEE ethics guidelines.
CUAUV Sniffer Board Design
The application environment of this project requires a small size with high density of components. The only way to satisfy these two requirements would be to design a custom printed circuit board (PCB) such that, other than the battery, all chips (including the ATMega32, DataFLASH, level shifter, etc.) and sensors would fit on it. In the two-hull SeaMonkey vehicle (the current CUAUV submarine), the CUAUV Sniffer would be placed inside the upper hull, which houses the sensor board, microprocessors, orientation sensors among other parts for operation. To fit in this hull, we set a design requirement for the board to be smaller than 4” by 3”.
For this reason in addition to its low lost, we chose the MiniBoard service through ExpressPCB. These two-layer, double-sided PCBs come in orders of three, each with a dimension of 3.8”x2.5”.
The schematic and layout are both based on Bruce Land’s prototype board for the ATMega32 (see Appendix E). Before designing, we determined that the following components were necessary for building the sensor board:
(Note: SOICs were the chip preference due to size considerations for this board and future versions of the Sniffer.)
Once these parts were set, and picked out (see Appendix C for manufacturer numbers), we created the schematic and layout using the ExpressPCB software package. Once the design was checked over, it was sent to ExpressPCB to be made.
Upon receiving the board and parts, we soldered all components onto the two-layer board. After testing and debugging the board, the following design errors were discovered:
Such problems were expected with the first version of the CUAUV Sniffer and were temporarily fixed by using rework wiring and an extra SOIC footprint. Version 2 (expected completion date of June 2006) of the CUAUV Sniffer will correct all of these issues.
Temperature Sensor
Figure 3. Temperature Sensor on Sniffer Board
For monitoring the temperature inside the upper hull of the vehicle, the LM34DZ-ND Temperature Sensor is used. This sensor is picked not only for its range characteristics, but also because the students had used this sensor in Lab 5 of ECE 476.
Figure 4. Noninverting Amplifier for amplifying voltage output of LM34 Temperature Sensor
The non-inverting amplifier (see Figure above) must be constructed to amplify the voltage output of the LM34 Temperature Sensor by a factor of 2. For the circuit, the chosen resistor values are both 10kOhms and the capacitor value is 2nF. The reason for a voltage gain of two is because the accuracy of the A/D converter is +/- the 2 least significant bits. Each bit corresponds to approximately 10 mV while each degree change corresponds to a change in 20 mV. Thus, by amplifying this output, a change in 1 degree will not be considered error and the converter will more accurately represent changes in temperature.
Light Sensor
Figure 5. Photocell on Sniffer Board
The photocell (PDV-P9007 ) changes its resistance depending upon the amount of light hitting it. We put the photocell in series with another resistor in the same range as its resistance (10kOhm). As light increases, the resistance of the photocell decreases to as low as 2kOhm. As light decreases, the resistance increases to nearly 200kOhm. Thus, its voltage range swings between 1V and 5V for this application.
Voltage Sensors
Figure 6. Twisted wire pairs for Three Voltage Sensors
As previously stated, there are three voltages sensors on the CUAUV Sniffer board, each performing a different data acquisition.
The first sensor is a 10x magnified differential voltage sensor. This sensor would be useful for monitoring a node that should not experience even small swings in voltage (e.g. monitoring Vcc within the vehicle).
The second sensor is a 1x magnified differential voltage sensor. This sensor would be useful for monitoring any node within the vehicle, not just those that cannot experience small changes in voltage.
The final voltage sensor is a single-ended voltage sensor, with ground connected to the sensor board’s ground. The reason for this implementation of the voltage sensor is because the ADC only allows for two differential sensors.
Power Source
The CUAUV Sniffer must be capable of operating in a mobile environment (the submarine) without using the vehicle’s power source. Thus, the Sniffer uses a 9V alkaline battery because of its low cost and ability to run the sensor board for over two hours. This period of time is well over the required specs for such a logging device.
Operation State Diagram for the CUAUV Sniffer
Figure 7. State Machine for CUAUV Sniffer Operation
The state diagram in Figure 2 shows the operation of CUAUV Sniffer depending on the inputs from the microprocessor on the vehicle. The state of the Sniffer begins on “Wait” – it is neither logging data nor sending it. Once the Sniffer is reset by receiving the ASCII byte for `r’ from the microprocessor, it begins continuous logging of the sensor data. It logs one sensor datum each instance TIMER1a overflows. Thus, TIMER1a must overflow five times for data to be obtained from all five sensors. TIMER1a is variable, so that sampling data from the sensors is possible by increasing or decreasing time to overflow.
The microprocessor must send a ping (sending the ASCII byte for `p’) once every five seconds over RS-232 serial to the ATMega32 during the “continuous logging” to remain in the same state. This pinging will hereafter be referred to as the “heartbeat” of the microprocessor on the vehicle, and will be checked after each overflow of TIMER0. After each ping, the ATMega32 returns a real-time message (currently 8-bytes) to the PC (see Packet Structure below).
If the heartbeat is not detected, then the Sniffer will assume a failure has occurred causing the shutdown of the processor. There is no need to continue logging for extended periods of time, as any relevant data that would help with debugging has already been recorded. Thus, the Sniffer moves into the next state, known as the “Timed Logging” state where it records sensor data for an additional five seconds. After this final set of data logging, the Sniffer state switches back to the “Waiting” state. Presumably, the data stored in FLASH has sensor data from before and after the failure, allowing the debuggers to find the problem within the vehicle. Thus, once the Sniffer is removed to the vehicle and connected to another PC over serial, the data from DataFLASH can be dumped out to Hyperterm by sending the ASCII byte `d’ for “Dump.” In its current state, sending `d’ will return a block of data saved in FLASH's main memory in order to prevent crashing the PC by sending too much information. In order to continue data dumping, the PC must continue to send `d.’
Any state can switch immediately to the “Waiting” state by the PC sending `s’ for “Stop.”
ADC Setup for Multiple Inputs
The analog to digital converter on the CUAUV Sniffer uses five sensor inputs. Since it can only run one conversion at a time, ADMUX chooses which sensor the ADC reads and converts. Thus, the software is written such that ADMUX rotates through each sensor for each TIMER1a overflow.
The most significant 8 bits of data is stored in the ADCH register after conversion by left-aligning the two registers of data. Our requirements allow us to only desire the most significant byte, thus we ignore the lower bits by simply grabbing the ADCH data.
Packet Structure
The structure of the packet is as follows:
Byte1 |
Byte2 |
Byte3 |
Byte4 |
Byte5 |
Byte6 |
Byte7 |
Byte8 |
Datasize |
Time_01 |
Time_02 |
DATA1 |
DATA2 |
DATA3 |
DATA4 |
DATA5 |
Real-time Data Viewing
As mentioned before, each time the ATMega32 receives a `p’, a current packet with the sensor data is sent back to the PC. Real-time monitoring of the sensors is an attractive feature of the CUAUV Sniffer, as it will be eventually integrated into the current CUAUV custom data viewer, GHelm (software that is used during each pool test for viewing the status of the vehicle).
Using DataFLASH
There are two main operations that need to be discussed regarding the DataFLASH: writing and reading from main memory.
To write to main memory, we wait until 8 bytes are ready to be written, and then use the function “ProgramMainMemoryThroughBuffer1” to write to main memory through Buffer1.
Figure 8. Screenshot of Scope showing Clock and MOSI Communication to FLASH (Slave) from MCU (Master)
To read from main memory, we use a custom read function that makes two function calls. The first function maps one block of main memory to Buffer2. The second function call then reads from Buffer2.
Speed of Execution
The ATMega32 communicates over RS-232 serial with the microprocessor at a BAUD rate of 47,600 and with DataFLASH over SPI at 4 MHz.
The limiting factor in the speed of the device is the variable sampling rate. Currently, the Sniffer obtains data at a rate of 200 Hz from the five sensors.
A delay occurs in execution when the user requests a data dump. A consequence of the amount of data stored, the delay is unavoidable.
Overall, the speed of execution of the device is more than acceptable for the application designated in the introduction.
Accuracy
The accuracy of the gathering of sensor data is interrupt-driven, and thus of the same high accuracy as the crystal.
Though the sensors are not very accurate (mostly a result of sampling with the ADC as well as dropping the lower bits from memory constraints), the users of the devices are only concerned with sharp changes or swings in sensor readout values. Thus, such inaccuracies are acceptable so long as changes in values are properly obtained and observed.
The timestamp used for packets is neither strong nor accurate. The timestamp drifts between 20% and 33% of the theoretical timestamp. For version two of the Sniffer, we are considering other viable options for timestamping. One method would be basing the timestamp on how many pings received had been received up to that packet. In this case, the accuracy of the timestamp is based on the accuracy of the host microprocessor “heartbeat.”
Safety
The CUAUV Sniffer should be a very safe device to use. By using a custom PCB and soldering, parts on the board could not be moved around to make it a dangerous project. In a worst-case scenario, noise could be sent via the sensors (e.g. the voltage sensors) to the nodes that the Sniffer is meant to only monitor. This issue could affect the third-party device and actually cause a failure, rather than help debug. We, however, do not feel this to be a concern from testing the CUAUV Sniffer.
Interference
Our project does not use any RF signals or other possible stray noise that would interfere with other team projects or any component of the CUAUV SeaMonkey vehicle.
Usability
This project is meant to be of great aid to the electrical and software subgroup of CUAUV in helping debug issues. It is designed so that it can be further integrated in the near future with their data monitoring software (GHelm), in which case this device will be very simple to use. Additionally, the documentation and commented code for the CUAUV Sniffer should be clear for anyone to understand the general operation of the project.
The CUAUV Sniffer v1 demonstrated successfully its capabilities of monitoring five sensors, providing real-time data, and logging and fetching stored data in FLASH.
Future Improvements to the Sniffer
Though CUAUV Sniffer v1 was successful, a number of improvements need to be made for version 2 so that it can be integrated into the current CUAUV submarine. To help with the quality of board design as well as decreasing the size, we will switch to the Mega32L microcontroller for the smaller form factor advantage. In order to do this, a 4-layer PCB with solder mask and silkscreen would also be required in order to place parts on. We are currently using 1206 resistors and capacitors but will switch to 0402 for the smaller form factors. The current serial connecter (DB9) will be replaced with a custom CUAUV standard serial connector to expedite the integration process without using additional converters. Similarly, the octal buffer/level shifter would be replaced with a smaller form factor chip for communication with DataFLASH.
We would also be interested in figuring out a way to program the Mega32L onboard rather than via the STK500 in the future.
A switch from the 9V alkaline battery to a lithium ion battery is also being considered for version 2. Though the upfront cost would be high, long-term costs would be reduced as a result of higher energy density, chargeability, and longer run time.
Other improvements on the horizon are:
Conforming to Standards
The only standards used in the CUAUV Sniffer are SPI and RS-232, both of which we adhered to completely. For SPI, the ATMega32 talks to the DataFLASH using 8 bits, no parity bit, no stop bits, and no flow control. For RS-232, the ATMega32 communicates with the PC over serial using 8 bits, no parity bits, 1 stop bit, and no flow control at 9600 BAUD.
Intellectual Property Considerations
The idea for this project is to specifically aid CUAUV in debugging catastrophic failures of its vehicle – the idea is by no means novel, but it is still a new addition to the submarine. We derived the base SPI library from previous work by another Cornell engineering student, Karl Antle, in ECE 402 – Biomedical Systems. As a result of his code not being copyrighted in addition to his approval of our use of it, we see no reason to be concerned about misuse of intellectual property.
Ethical Considerations
Referring to the IEEE code of ethics, we have followed the guidelines below.
1. to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment;
All engineering decisions made in designing, building and testing the CUAUV Sniffer adhered to the policy of maintaining a safe environment for users of the device. We are not currently aware of any endangering factors but would certainly handle any issues promptly by removing the device from use and alerting fellow members working with it.
2. to avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist;
We do not believe any conflicts of interest exist. This project was made towards integrating it with the requirements set by Cornell University Autonomous Underwater Vehicle Team’s (CUAUV) robotic submarine. There is no plan for selling this as a product in any consumer market.
3. to be honest and realistic in stating claims or estimates based on available data;
This report details the standards and methods of operating the CUAUV Sniffer. There are no misleading statements or claims.
4. to reject bribery in all its forms;
There were no bribery offers before, during, or after the completion of the project. Thus, there were no issues in this regard.
5. to improve the understanding of technology, its appropriate application, and potential consequences;
The basis of the CUAUV Sniffer is to enhance the debugging capabilities of an autonomous submarine built by undergraduates at Cornell University. To this end, this project serves as a support for understanding and developing autonomous technologies by expediting the debugging process of electrical, mechanical, and software failures.
6. to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations;
Both project members are also members of CUAUV, an undergraduate, cross-discipline, engineering design team at Cornell that designs and builds an autonomous submarine. The knowledge learned through this project team, as well as through the coursework in ECE 476 – Microcontrollers, enables them to undertake the CUAUV Sniffer project.
7. to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others;
To aid in integrating the CUAUV Sniffer with the CUAUV SeaMonkey vehicle, the aid and criticism of a number of CUAUV members was considered, each of who have been acknowledged. Additionally, the advice provided by the ECE 476 lab TAs and professor were also greatly appreciated and credited.
8. to treat fairly all persons regardless of such factors as race, religion, gender, disability, age, or national origin;
The CUAUV Sniffer does not have internationalization support, accessibility support, or accessibility options. Otherwise, all other ethical considerations in this respect were upheld.
9. to avoid injuring others, their property, reputation, or employment by false or malicious action;
The well-being of others, their property, reputation, and employment received the utmost of respect from the members of this project.
10. to assist colleagues and co-workers in their professional development and to support them in following this code of ethics.
Assisting colleagues and academic partners is important to the members of this project. We have and will provide as much support to our peers as possible in their development as scholars as well as people of society.
There are three C-code files used for the CUAUV Sniffer.
The main file, "sniffer.c", contains the logic for the operation state machine and timing, as well as calling the other two support files.
The file, "interruptserial.c", uses a custom ring buffer to transmit and receive over serial by defining a write functions for each type of data being transmitted (i.e. int, long, string, hex, or the custom 8 byte packet).
The last file, "dataflash.c", contains SPI functions for reading and writing to the two DataFLASH buffers as well as main memory. The structure of this file is based on code supplied by Karl Antle.
The CUAUV Sniffer board schematic and layout were both designed with the ExpressPCB software package. ExpressPCB, using the schematic and layout shown below, built the current Sniffer board. Please note that these are both flawed designs and have been corrected by using much rework wiring for CUAUV Sniffer v1 (version 1). Below are screenshots taken from the original schematic and layout.
Figure 9. Schematic of CUAUV Sniffer Board (v1)
Figure 10. Layout of CUAUV Sniffer Board (v1)
Since this ECE 476 project was in conjunction with an engineering project team, we are not bound by the cost limit of $50. However, we were still successful in staying within the de facto budget.
Part |
Cost |
Atmel Mega32 Microcontroller |
$8.00 (rental from ECE 476 lab) |
STK500 (used only to program the MCU) |
Free (borrowed from CUAUV lab) |
Custom-designed ExpressPCB MiniBoard |
$20.00 |
RS-232 Connector |
$1.00 (rental from ECE 476 lab) |
MAX233A, SOIC |
Free (Sampled from Maxim-IC) |
LM34DZ-ND Temperature Sensor |
$2.51 |
Photocell, PDV-P9007-ND |
$1.77 |
16Mb DataFLASH, AT45DB161B-RC |
$6.02 |
MP160 16 MHz Crystal |
$0.94 |
Octal Bus Level Shifter, SN74LVC4245A |
$0.90 |
LM340T5 5V Regulator |
$1.72 |
Op-amp, LMC7111 |
$1.69 |
9V Battery |
$2.00 |
Miscellaneous (wiring, sockets, etc.) |
$3.00 |
Total Cost: |
$49.55 |
All tasks completions were accomplished in the CUAUV Lab (Phillips 217) during and outside official lab hours.
Task |
Member(s) Involved (Outside Assistance) |
Idea Formulation |
Lamba, Wang (Sam Fladung) |
Determining Required Part Numbers |
Lamba, Wang |
Sensor Board Schematic Design |
Lamba, Wang (Bruce Land) |
Sensor Board Layout |
Lamba, Wang (Bruce Land) |
Soldering |
Lamba, Wang |
Debugging Hardware |
Lamba, Wang (Tom Craig, Sam Fladung) |
Programming MCU via STK500 |
Lamba, Wang (Jason Chiang) |
RS-232 Communication |
Lamba, Wang |
SPI Communication |
Lamba, Wang (Karl Antle) |
Reading/Writing from/to DataFLASH |
Wang |
Hardware Design for Sensors |
Lamba, Wang |
ADC Code for Sensors |
Lamba, Wang |
Code for Logging Data to DataFLASH |
Wang |
Debugging Code |
Lamba, Wang (Tom Craig, Sam Fladung) |
Logo Design |
Lamba, Wang |
Final Report |
Lamba, Wang |
Datasheets and Standards
Vendors
Code and Schematic References
The base SPI library, as stated before, is derived from Karl Antle’s previous work. While little of the code is left in tact, the structure remains in addition to two basic functions. His Secure Digital SPI Library zip file can be found here: SD_Library.zip.
Below is the prototype board layout provided in ECE 476 by Bruce Land. Though we did not use the actual board, we examined the layout when drawing our own in ExpressPCB. For instance, the capacitors and resistors used on our board correspond well with Land’s. The ExpressPCB layout can be found here.
Figure 11. Bruce Land's Prototype Board for ATMega32
Background Information
Credits
Manoj Lamba and Ian Wang would like to thank the following people for all of their help in the completion of the CUAUV Sniffer Project: Bruce Land, Jason Chiang, Sam Fladung, Tom Craig, and Karl Antle.
