Skip to main content

more options


Cooper and Anish

Introduction

The Handy Lab Buddy is a tool every ECE should have. The four features of this tool include a talking voltmeter, logic probe, voltage averager, and frequency measurer. As a cheap and accurate device that outputs whatever being measured through speakers, it's one of its kind and an essential tool for lab work.

Summary

Have you ever tried to debug a circuit and just wished your voltmeter would talk to you? Or have you ever been too lazy to turn on and calibrate the oscilloscope to measure the frequency? Well, this is the device for you. There are four operating modes of the Handy Lab Buddy. The first mode is a voltmeter that measures voltages up to 5V and says the voltage measured through speakers. The second mode is a logic probe that beeps once in a low tone if the output voltage is low and beeps twice in a higher tone if the output voltage is high. The third mode, a feature unique to this device, is a voltage averager that takes multiple samples in succession (perhaps a noisy voltage signal) and calculates the max, min, and mean voltage and speaks the values over a speaker. The fourth and final mode measures frequency with great accuracy from about 10 Hz to 100 kHz and speaks the value over a speaker. A device capable of all these functions and a "talking" ability at a very cheap cost is not available in the market today and is very useful to the ordinary engineer not wanting to invest in an oscilloscope. As very enthusiastic electrical engineers, we decided to build this device - simply for our own benefit, as it helps tremendously when debugging circuits.

We used quite a few features of the Atmel Mega644 MCU to implement this system, such as speech generation and output, multiple ADC conversions, the output of the pulse width modulator (PWM), and some others.

 

High Level Design

Rationale and Sources:

In all honesty, this was a secondary project idea for us, originally suggested by Bruce Land. Our original project idea, the Electronic Dartboard (discussed later), had tremendous problems with the hardware in the later weeks of the design cycle that forced us to abandon it. As our working efficiency and debugging experience increased dramatically in those frustrating few weeks, we managed to start and finish this new project within the final days of the semester.

Background Math:

The first big challenge for us was to get sound bites from AT&T and convert them for appropriate use for the MCU. Using the speech generation document by Bruce Land, we utilized his MATLAB programs to downsample from 16 kHz to 8 kHz and create header C files. The compression used in the MATLAB program was a differential pulse-code modulation (DPCM) with a 4:1 compression which sends 2:1 derivative samples.

To calculate the voltage generated, we had to use the built-in analog to digital converter in the MCU. Simple bit conversions were done, and we had to divide the 10-bit digital voltage output by 1024 over VREF (5V) to get a floating point value for the voltage. For the logic probe, the same thing was done, except an additional comparison was made to a threshold. The third feature, calculating the min, max, and average of samples of voltages, used pretty much the same principle as above except used additional variables to store the previous mean, min, max and sample number of samples. Frequency is measured using an elegant combination of software and hardware. Our frequency hardware first filters out the DC component of any input, then reapplies a DC bias, resulting in an AC waveform around the biasing point of our high frequency inverter. The output of this inverter is then stabilized. The final wave is thus a clean square wave, which is then used to trigger the external interrupt on the microcontroller. The software then responds to the interrupt, first synching the timers to the waveform, then measuring the the period of the waveform. Finally, the period is converted into frequency. Using this method, we can reliably measure frequencies from 10Hz to 100,000kHz.

There were two ISRs, one of them controlled the part of the speech played using a table, based on a timer, and the other, an external interrupt, controls triggers when to measure the time elapsed from the previous trigger, to measure frequency.

Logical Structure:

Cooper and Anish

The user-interface of the Handy Lab Buddy is as demonstrated above. In the first two modes, after the analog voltage measurement is done, the signal needs to only go through an ADC before output to the LCD and to the speakers. For mode three, the voltage averager, the user presses the button on the probe when he/she is ready to take samples, then releases it to stop taking samples. The display shows the final output and it is automatically spoken. The fourth mode, frequency measurment, the user first has to change the banana plug connection to the frequency measurement pin (because of circuit isolation, described later in detail), then the signal passes through an inverter circuit to digitize the analog signal, which then triggers the external frequency ISR on the microcontroller (described later). After measurement in software, it is outputted onto the LCD and speakers. The four buttons that determine the modes are operated by a basic debounce state machine.

Hardware/Software Tradeoffs:

The biggest tradeoff during this design project was our decision to completely scrap our original idea and use this one. Our original idea was to create an Electronic Dartboard, where a player would draw concentric circles on a whiteboard, a infrared camera (removed form a WiiMote) would then be calibrated to the circles and display them on an LCD. Then, the user would "shoot" an IR dart (laser) at the whiteboard, which the WiiMote camera would have picked up and drawn the location on the LCD. However, the WiiMote IR camera was not reliable enough outside of it's original controller. On top of that, we concluded the large LCD we were planning to use was fried after much testing. We worked on these getting these two hardware components to work by going to lab a lot of extra times overthree weeks to no avail. Thus, due to faulty hardware and being incredibly pressed for time, we decided to switch to this project, which our professor had initially suggested in class. In retrospect, we're glad we made that decision, as we were able to come out with a complete, working product in a short span of time. The detailed schematics and code for the old project are described later.

One tradeoff we faced was during the design of our frequency measurer. We wondered how to calculate the frequency. One way of doing it was to use an Fast Fourier Transform algorithm as linked on the course website. However, we realized that the DFT/FFT would take up too much processing power and memory because of the look up tables. Besides, our frequency measurement only needs to measure the most prominent frequency, and the DFT/FFT would be doing unnecessary computation. Thus, we decided to take more of a hardware based approach, by digitizing the signal by passing it through an inverter, then using an interrupt to calculate the frequency.

Relationship to Standards:

There were no relevant IEEE, ISO, ANSI, or DIN standards related to this project.

Existing Patents, Copyrights, Trademarks:

There were no existing patents or trademarks associated with our project. We did utilize Bruce Land's code for the implementation of the LCD and drivers, and his MATLAB code for converting .wav files from TextToSpeech to .h files.

 

Project Design

Hardware Design:

The hardware design for the Handy Lab Buddy was rather simple. To program the Atmel ATMega644 Microcontroller, the STK500 development board was used. The Mega644 MCU was then put on the Custom PC Board, provided by the lab. Soldering components onto the PC Board had to be done with careful precision, as the pins were small and very compactly laid out.

Our other significant pieces of hardware in this project were the 2-line LCD display in lab, the 4 buttons, a speaker, an inverter, and probes (with another button). The overall interfacing of the MCU with the rest of the hardware is shown below in the schematic.

Custom PCB

Buttons

Buttons 1-4 were connected to port B7 to B4 (respectively) of the MCU. The top pin was grounded, while each of the other pins had a 10kΩ connected to Vcc. The resistor was needed there because when a button is pressed, the wire is shorted - to prevent this a resistor was placed there. These buttons operated on a debounce state machine, described later in the Software Design section.

Another button was used as an interface for the voice output . This was also connected to a 10kΩ resistor to Vcc, and to port B0. When this button was pressed, depending on what mode the system was in, the system would speak whatever was on the LCD screen.

Frequency, Inverter, and Protector Circuit:

If a signal was to be measured for it's frequency, it needed to go through a circuit first to be processed. First of all, the diode/resistor connected to Vcc in the schematic was just to protect the MCU port A0 from being fried in case a voltage greater than 5V is fed into port A0. The signal picked up by the probe goes through a 0.4uF total capcitance array to filter out DC values, then gets DC shifted by the voltage divider, before going through the inverter to shift the center voltage of the signal. The purpose of the inverter is to output a square wave from any periodic signal given. There were a few ways of accomplishing this, one using an inverter or another using a Schmitt Trigger op amp circuit. We chose the inverter because there was no analog circuitry to worry about. Thus, the "analog" wave gets converted to a digital wave, as it converts every point on the wave below the 2.5V threshold to a logic 0 and above the threshold to a logic 1. The output of this input is then stabilized by two 22 pF capacitors. The final wave going into port D3 is a clean square wave used to trigger the external interrupt of the microcontroller.

Speakers:

The speakers are not shown in the schematic. They were simply connected via a headphone jack from port B3 (output of the PWM) to ground.

Liquid Crystal Display:

The LCD used in this project was simply the 16-pin LCD used in ECE 4760 Spring 2010 Lab 1. The pin assignments are as in the schematic.

Microcontroller Operation:

The Atmel ATMega644 microcontroller was the control module of the device. Port A0 was the ADC used to implement the first three modes. Port D3 was used to implement the frequency mode. Port B0 was the button on the probe, that made the speaker output a voice signal, which was coming from port B3. Ports C0-C2 and C4-C7 were used for the LCD. The diagram shows how the microcontroller was laid out on the custom PCB board. The photograph after the probes section shows the completed target board connected to the rest of the circuit. Two 1 uF capacitors were also used to connect Vcc and Gnd to remove any external noise in the circuit as a whole.

Custom PCB

Probes:

There were three probe inputs used: one to measure voltages, one for frequency, and the black was always connected to ground as a reference. The input probe, depending on whether the device was measuring frequency or voltage, would go on either the green connect or red connect (respectively). This can be seen from the completed hardware circuit below.

Custom PCB

 

Software and Program Design:

Speech Generation:

Speech generation was done exactly as outlined in Bruce Land's document. Once the voice files were obtained and compressed using MATLAB, the header files generated were used to output the sound later. The voices are all stored through the header file voice.h (attached at the end), which controls what is being outputted to the PWM with different inputs.

Internal ISR:

This interrupt service routine was mainly for using timer2 to read voices from the table and output them to the speakers using the PWM on B3.

Buttons Anti-Bounce:

In mode 1, if the probe button is pressed, the voltage displayed on the LCD is outputted to the speakers. In mode 2, if the probe button is pressed, the a single beep is outputted if the voltage is below a threshold of 2V or a double beep is outputted if the votlage is above the 2V threshold. In mode 3, if the probe button is pressed once, then the state machine sends a signal to start collecting data and update the min, max, and average values, then nothing happens when it's released, but stops the data collecting when the button is pressed again, and outputs the data to the speaker. In mode 4, only when the button is released is the data collected outputted to the speaker. The anti-bounce for the four buttons determining is rather simple. If a button was pressed and not down before, then the button counter variable incremented, so when it's released it triggers the functions in that mode.

External Interrupt ISR:

This external interrupt is simply for the fourth function of the device, the frequency measurer. If the fourth button is pressed, then it triggers this ISR, which times the next period of the square wave, and calculates the frequency. We also needed an overflow ISR because at the beginning we were having problems with read the correct value for less than 250 Hz.

main() Function:

This function basically deals with the overall structure of the program. First of all, INT1 is turned on for frequency detection. The PWM is turned on with a period of 256 cycles. Timer2 is set to overflow at 7812 Hz (overflow ISR is turned on). Timer1 is also turned on for the frequency count (and overflow ISR). For the voltage measurements, the ADC converters are initialized and a conversion is enabled. The final part of the main() function has the outputs to the LCD at each stage. The button state machine is also run multiple times with a delay of 20 ms (for the modes 3 and 4 primarily).

LCD:

The LCD used the same header file from the previous labs, and the same functions to write on the LCD.

 

Results

Speed of Execution:

Each mode of the Handy Lab Buddy was executed quickly. The LCD was able to recognize a change in voltage very fast, and if the probe button was pressed, the speaker outputted the reading instantly. For mode 3, our voltmeter took samples every 20ms and updated almost instantly on the screen the max, min, and mean values for the number of samples at that moment. For the frequency mode, the optimum range of operation was from 10Hz to 100kHz. If you were measuring out of that range, the LCD would take about 1 or 2 seconds to update the value being fed in. However, the speaker outputted whatever was on the screen instantly.

Accuracy:

Our voltmeter was very accurate to the hundredth value. A table of voltages measured by our voltmeter in mode 1 versus the same voltages measured by the oscilloscope are shown below:

Our Voltmeter

Oscilloscope (hundredth)

% Error

0.27V

0.25V

8%

1.04V

1V

4%

1.99V

2V

0.5%

2.5V

2.5V

0%

2.97V

3V

1%

4.05V

4V

1.25%

4.73V

4.75V

0.42%

The error is slightly bigger for earlier values because they're more vulnerable to noise. The logic probe (mode 2) was very accurate, and gave us 100% accuracy for every digital circuit we tested. The variable voltage averager (mode 3) was more difficult to test, as there was no existing product to compare it to, but the mean value responded as expected intuitively. Thus, our tests for mode 3 were more qualitative, and deemed very successful. Finally, mode 4 was tested using the function generator. Our frequency measure was very accurate from 10 Hz to 100 kHz (the operating range), and then dropped off significantly after 100 kHz. The table below shows the error is actual and measured values with our frequency measurer.

Our Frequency Measurer

Function Generator

% Error

No Signal (Too Low)

5 Hz

N/A

10 Hz

10 Hz

0%

98 Hz

100 Hz

2%

996 Hz

1000 Hz

0.4%

20514 Hz

20000 Hz

2.5%

69323 Hz

70000 Hz

0.97%

105638 Hz

100000 Hz

5.6%

~135000 Hz

120000 Hz

12.5%

As you can see, the frequency measurer was very accurate for the operating range but dropped significantly when the frequency was greater than 100 kHz.

Safety:

We took great care to see that our practices and final project met the highest standards for safety. Every time we had to solder something onto the board, we would both wear safety goggles, make sure the iron is heated appropriately and turned off when not needed. We would also always ground ourselves when handling any circuitry, especially DIPs such as the Mega644s. As can be seen from the final product, our soldering and wiring was very neat and properly laid out. This project doesn't pose a significant harm to anyone else while in operation due to the low voltage input.

Interference:

We did not experience much interference when the Handy Lab Buddy was under voltage measurement operation. However, when we were using the frequency mode, we could pick up the 60Hz noise from the lab environment.

Universal Usability:

This device is usable by any person who actively works in the lab. Since it measures only low voltages, it does not pose much harm. Persons with special needs who can operate simple lab voltmeters can use this device - and in fact get voice output and frequency measurement. So it is even advantageous for some person to utilize this device instead of standard lab equipment.

 

Conclusions

Our talking voltmeter surpassed all expectations in accuracy and features implemented. However, one thing we learned from this entire design project cycle is that there are always going to be serious problems during the course of the design and you're going to have to make quick, appropriate decisions regarding the future. Deciding to change our project completely was a wise decision on our part, since we had no part of our original design completely working slightly more than a week before our project was due. Although we felt frustrated that we had spent more than 3 weeks and 50 hours worth of work trying to get a simple IR camera and an LCD to work (simply the hardware), we were satisfied with the final outcome of the design project. Another lesson also learned was the fact that it is very difficult to reverse engineer a commercial product, such as the WiiMote. To pack that many IC's and functionality into a small WiiMote package, the manufacturer use little tricks that are impossible for us to capture. Although the schematics of how to use the IR camera and the I2C bus were given online, we were unable to have a permanently working circuit within the alotted time (it worked a few times and was unstable).

Standards:

As mentioned previously, we did not have to use any IEEE, ANSI, DIN, ISO standards as they were not relevant to our project. However, we did follow the all of the IEEE code of Ethics.

Intellectual Property Considerations:

Old Project Design: WiiMote IR Camera/LCD Interface:

In our old design, we were reverse-engineering the IR camera on the WiiMote, and couldn't get it to work. We were using the IR camera hack seen here, as well as the code for the I2C bus. For the LCD, we were using the schematics and drivers written by a previous ECE 4760 Project, the Hard Drive Clock, only to find very late in the game that the LCD was most likely fried, because it was not processing code or even turning on.

LCD Drivers and Code:

Since the LCD we were using was the same one we used for labs in Spring 2010, we used the code that was given to us (by Bruce Land). This included lcd.h and lcd.c (attached at the end).

Sound Bites:

The sound used for this project was obtained from the AT&T TextToSpeech website.

Idea:

The idea for this project was initially suggested by Bruce Land in lecture. However, we have tweaked it from simply being a talking voltmeter to much more.

Future:

This project can easily be commercialzed for use in labs. It is useful for any electrical engineer, as the talking capability comes in handy when debugging a complicated circuit and not being able to look at the display. The averager and frequency meter are also one of it's kind features for this device, and are definitely useful in lab. Thus, if properly bound and manufactured, this device has great potential.

Ethical Considerations:

We believe our project fully follows the guidelines discussed in the IEEE Code of Ethics. While working in lab, we made sure to ensure that our project did not adversely affect the safety, health, and welfare of the public. We used the most accurate of instruments to compare our data with, and made every effort to have accurate data, as our data is the average of 3 or more trials.

Our project also improved the understanding of technology as some of our features were one of a kind not implemented in any device before. We also improved our technical competence by developing a fuller understanding of the Mega644 microcontroller, ISRs, speech generation, etc. Both of the group members were trained engineers who had experience working with circuitry and code before, and thus were technically competent to work on this project.

We know that our project is not perfect and can still be improved. We are willing to take any and all constructive criticism that would improve this project. We have also acknowledged everyone responsible for helping with our project in various parts of this website. Our project treats every person using it equally.

Lastly, we have also ensured that our project is safe and does not cause any harm. We have made sure that our metal pins on the bottom of the soldering board are not exposed. We will also to the best of our ability help other groups with their project and criticisms.

Legal Considerations:

Other than using the soundbites from AT&T TextToSpeech, there were no legal considerations applicable to this project.

Appendix

Code:

lcd_lib.h

lcd_lib.c

voice.h

main.c

project zip

Cost and Part List:

Part Quantity From Total Cost
Total Cost     $28.15
Mega644 1 Lab $8.00
Custom PCB 1 Lab $4.00
DIP Socket 2 Lab $1.00
Solder Board 1 Lab $1.00
Power Supply 1 Lab $5.00
LCD 1 Lab $8.00
Buttons 2 Lab $0.00
Probes 2 Personal $0.00
Pins 23 Lab $1.15
Resistors/Capacitors/Inverter Lots Lab $0.00
Speakers 1 Pair Lab/Personal $0.00

 

Division of Labor:

The software for the project was designed and developed by Cooper Bills. The hardware design was worked on both by Cooper Bills and Anish Borkar. The soldering of the PCB was done by Cooper Bills. The soldering of the rest of the hardware and circuitry for the project was done by Anish Borkar. The debugging of the project was done jointly by Cooper Bills and Anish Borkar, but Cooper Bills was responsible for a large part of the debugging of the software. The website and report was designed and written by Anish Borkar.

Acknowledgements:

First of all, a sincere thanks to Bruce Land for instructing this wonderful class and being of invaluable help to us. Thank you for also providing us with advice with respect to our project change. We would also like to thank the TAs who went out of their ways to keep the lab open and to answer a lot of our questions. A special thanks also to Friday Lab TA Yuchen for an awesome semester. We also want to thank AT&T for their TextToSpeech program that we were able to utilize to obtain sound bites for numbers and words. We also thank Cornell University's Website Template service for providing us with this template.

References/Links:

Mega644 Datasheet
ECE 4760 Website
Speech Generation on Mega644


Contact Information

Anish Borkar, ab673@cornell.edu

Cooper Bills, csb88@cornell.edu