ECE 476 Final Project

Ultrasonic ParKontroller



James Juwon Lee (jjl49)

Maurico Rodriguez Saenz (mar97)


Spring 2007

Cornell University






Are you afraid that your brand new Hummer is going to get scratched while parking it in a tight space?  Do you have trouble backing your large Mercedez S-class into your small garage?  Fear no more!  Our ultrasonic ParKontroller can sense how far you are away from the wall or a hidden object behind your car and warn you visually and audibly using LEDs and speaker respectively.


Courtesy of



High Level Design



Rationale of our project


A significant portion of the people around the world owns car or are daily drivers.  In fact, United States alone has the largest passenger vehicle market in the world and there were over 243 million registered vehicles in the U.S. in 2004.  Among these drivers, it’s not entirely untrue to assume that parallel parking or rearward parking is one of the most cumbersome parts of their driving experience.  It takes years of driving experience and rigorous practices to avoid a fender bender or an ugly scratch across the bumper.  Some old school auto-enthusiasts may like to do everything manually, but most of us like to take advantage of the advanced car electronics and technologies to make our life a little bit easier and also to avoid common accidents during parking.  Hence, we decided to design and build an ultrasonic parking assistant system that will help the driver get a sense of how far his or her car is away from a wall or an object behind the car.



Logical Structure


The basic theory behind the ParKontroller is the Sound Navigation and Ranging (SONAR) technique that is used for finding the distance and direction of a remote object underwater by transmitting sound waves and detecting reflections from it.  First, a series of short ultrasonic pulses are transmitted using a transducer that changes voltage into sound waves.  The transmitted pulse is reflected off an object, and the reflected wave is then received by another transducer that converts sound waves into voltage.  The transmitted signal is also known as the ‘ping’ and the received signal is known as the ‘pong’.  By counting the elapsed time between the ping and the pong, the distance between the device and an object can be easily calculated by multiplying the elapsed time with the speed of sound.  Note that the time measured represents the time it takes a pulse to travel to an object plus the time it takes to travel back to the receiver.  Hence, the measured time is halved in calculating the appropriate distance:


Distance = (Time elapsed / 2) * 340.29 m/s


Since a single measurement may misrepresent the actual distance, a multiple received signals were sampled and averaged to give more accurate distance measurement.  The calculated distance is then broken down into five intervals that represent the level of proximity from the object.


Distance Interval (cm)


LED light-up

0 – 15







15 – 20







20 – 25







25 – 30







30 – 35














Table 1.  Distance intervals and corresponding lighted LEDs


Based on the distance interval one or more LEDs will light up; the shortest distance (0 – 15cm) will light up all six LEDs, the next shortest distance (15 – 20cm) will light up 5 out of 6 LEDs, and so on.  In addition to the representation of the distance with the LEDs, a piezo speaker is used to emit warning beeps based on the distance intervals shown above.




Hardware/Software Tradeoffs


Hardware Tradeoffs


All hardware parts used in this project were off-the-shelf components that are widely used in simple analog circuitry, hence using other parts from different manufacturer or vendor would not have given us better results.  For instance, the 40kHz transducer we used as transmitter and receiver was a generic component that has the same electrical characteristics with any other 40kHz transducers.  Nonetheless, there was a major tradeoff when choosing which voltage level to use for the transmitting signal.  During our hardware-testing phase, we found out that the effective range of our ParKontroller is proportional to the power of the transmitted signal.  Larger range was initially preferred, but we also know that higher power achieved by using operational amplifier will also amplify the noise.  The effective range of our device was important, but acquiring a clean square pulses were much more important in terms doing calculation with the received signal.  The voltage level of the transmitted signal can be amplified up to +18V, but that resulted in random spikes and noise in received signal hence producing random distance calculations.  Tuning it down to +12V gave us reasonably clean signal, and in fact it was practical to use 12V since 12V can be tapped from the fuse box of any standard cars.


            Software Tradeoffs


The biggest software tradeoff had to do with the timing.  Our main priority was to produce a set of pulses at the operational frequency of the transducer of 40 kHz. This meant that we were restricted to only one interrupt; having more than one implied an overlap of the interrupt meaning one was going to be missed. Being limited to one timer also means that our freedom to code is limited.  In order to generate the pulses we limited our capacity to expand our features:


Timing: in order to have the 40 kHz pulses we can’t have a very fast interrupt, so our timing of the pong was limited to the fastest interrupt we could have that generated our pulses.


Sound: having only one interrupt limited our capacity to generate precise sound.


In order to get a fast reading on a signal we had to have really fast code.  This meant that the interrupt had to be fairly fast.  We could not further exploit the interrupt without causing some problems in the functionality of the system.



Design Standards & Intellectual Property Consideration


Design standards such as IEEE, ISO, ANSI, etc. are not considered for our project since ParKontroller is a single portable device that does not interact with any secondary or external device.  Various parking sensor system designs already exist and are widely used in commercial products.  Nonetheless, ParKontroller is designed using off-the-shelf parts and basic circuit design principles; hence no patents or copyrights are violated.  




Hardware/Software Design


Hardware Design


The hardware circuit can be broken down into two main sub-circuits – transmitter circuit and receiver circuit.  The basic scheme of the transmitter circuit is shown below.



Figure 1.  Transmitter Circuit



A series of five short pulses blasted by the microcontroller only has 5V amplitude, which will be attenuated down to less than 20 mV when received by the receiver circuit.  Hence, LM311 voltage comparator was used for signal amplification before transmitting the signal.  LM311 was used instead of regular operational amplifier since it has faster switching speed.  Low-to-high and high-to-low level output response times were only 115ns and 165ns respectively, which was more than enough for our application since the width of each pulse is 12.5us.  The voltage comparator compares the 5V input pulse generated by the MCU to 2.5V.  If the voltage level of the input pulse is greater than 2.5V it outputs 12V drawn from the power supply and drives the ultrasonic transducer, otherwise it outputs zero.  Hence the 5V input pulses are amplified to 12V pulses.  The ultrasonic transducer converts its input voltage into sound waves and emits them at 40kHz frequency.



Once the transmitted wave hits an obstacle it’s reflected back and received by another ultrasonic transducer that functions as a receiver.


Figure 2.  Receiver Circuit


First, the ultrasonic transducer converts the received sound wave into voltage.  The received signal was only about 50mV, which means that it has to be amplified by a factor of 100 to get a 5V signal.  Hence, 74HC04N Hex Inverter with 100kW/1kW resistor pair was used to achieve a gain of 100.  The propagation delay of the inverter was only 19ns, so switching speed was not of our concern.  The inverted and amplified signal was then inputted to a 74HC14N Schmitt Trigger to produce a clean square wave.  Any value below the trigger voltage (2.5V) gave logical zero (0V) and any value above 2.5V gave logical high (5V).  Note that the inverted signal from the inverter is inverted back by the Schmitt trigger.  The output of the Schmitt trigger is then fed into port B.1 for microcontroller processing and distance calculation.








Figure 3.  Array of LEDs

Figure 4. Piezo speaker



An array of 6 LEDs and a piezo speaker is connected to portA and portB.3 respectively to warn the user of his or her proximity from the interfering obstacle as we have discussed in High Level Design and Table 1.



Software Design


            The program was divided into four procedures:


1)     interrupt [TIM2_COMP] t2_compare(void)


The interrupt ran at 160 kHz. In order to achieve this we used no prescalar on the clock and set OCR2 to 49.  TCCR0 was set to compare on match. The main functionality of the interrupt is to generate 5 pulses at 40 kHz.  To do so we implemented a counter that sets PORTB.0 toggling it every second pass through the interrupt.  After five consecutive pulses have been emitted we wait for the counter to reach 700 (4.375 ms).  The waiting time is the equivalent of sound traveling a distance of 1.49 m, which means that it gave us a range of approximately 70 cm.  In practice this range could not be obtained.  Furthermore we decided on emitting a series of five short pulses instead of one since it delivers more power.  We tested with a range of 1 to 8 pulses in a set of ping.  The best results came from 5 pulses, meaning that the received signal was stronger when 5 pulses are emitted.


2)     void light_flashing(void)


Main function of this procedure is to flash the LEDs. We determined that our upper and lower boundaries, that came to be approximately 40cm and 15cm respectively.  With this data we fragmented the range into 6 distance intervals.  When we are receiving a pong we use the running average of the distance to determine how far the object is.  The closer the object is to the transducers more LEDs will be lighted up.


3)     void sound_gen(void)


This procedure generates a beeping sound according to the distance of the object.  We used the same ranges as light_flashing( ) to achieve congruency between the LEDs and the sound.  We used a function generator to produce sound with a sine wave and with a square wave. Given the speaker we had available and the quality of sound it was able to produce we decided to go for a square wave.  Again using the function generator we decided to run our wave at 4 kHz.  The way in which the procedure produces the sound is simply by setting and clearing TCCR0. The speed at which we set and reset TCCR0 depends on the proximity of the object, the closer it is the shorter we make the intervals.  TCCR0 is set to run on Compare on match, with a prescalar of 256 and OCR0 set to 7. OC0 is toggled on every match.


4)     void main(void)


The main function begins by initializing all the timers and counters, as well as any variable that needed to be set.  Within the while(1) loop we only have to ‘if’ statements.  The first one reads PINB.1 to detect any pong. It also checks that all five pulses have been emitted by checking that ‘count’ is beyond 40 cycles.  We had to perform this check because every time we emit pulses the receiver picks up some noise that could be read as a pong by the MCU.  If a real pulse is detected then we immediately read the number of cycles that elapsed from the first pulse until the pong was detected.  Once we have this we perform the appropriate operations to calculate the distance in cm.  Since we are running the interrupt at 160 kHz this means that every cycle represents .2125 cm ((1/160000) Sec * 340 m/Sec).  Multiplying the number of cycles by this factor and dividing by 2 (to account for the distance to the object and back) we calculate the actual distance. With this data we run a running average of 7. We decided on obtaining an average because that way we reduce any errors in our readings. We chose 7 by experimentation. We tried a range of 5 – 20 running average calculations, but we observed that after 7 the improvements in the calculations began to be insignificant.  From within this ‘if’ statement we also call sound_gen( ) and light_flashing( ), but we do this once the average for that cycle has been calculated.  The other ‘if’ statement checks to see if more than 20 consecutive set of pulses have been emitted without any response. If so it turns off any LEDs and sets TCCR0 to zero (turns sound off). This amount of sets was determined by experimentation as well. We tried different quantities starting at 6, but they would be too fast. We scaled them by 2s until we got to 20 and got appropriate results from the system.



Software Hurdles


Timers:  the hardest part to set was the timing scheme. The original idea was to use Timer1 in fast PWM to create a 40 kHz signal that could drive the transducers.  We were also planning on using Timer0 to run a clock from it. When we ran both interrupts nothing would come from OC0, so we switched from Timer0 to Timer2 (which we eventually kept using).  This change did give us results in OC2, but the interrupt from Timer1 would skip sometimes. We were using Timer1 to keep the timers used to calculate the distance, but the skipping made the data useless.  To solve this problem we decided to only use one interrupt, from Timer2, and used it generate the 40 kHz pulses and keep our timer.  As mentioned before we paid a price since our timers could not be as fast as we would have liked.


Number of pulses in a set:  there is somewhat random behavior in the system that regards the number of pulses emitted in a set.  Sometimes it is better to use 4 or 6, but most of the times 5 give the best results.  This particular problem is hard to explain and can only be solved by altering the code and setting the pulses to the optimum value (the one giving best results for that particular instance)



Flashing of LEDs and sound frequency:  We could not generate sound or flash the LEDs within the interrupt.  When we tried, the whole system would simply stop working.  We solved this by creating two procedures, sound_gen( ) and light_flashing( ), that we called from main( ) and that were completely independent of the interrupt.  The consequences of these actions came in instability in the flashing and the sound frequency.  Our system sometimes flickers because our soung and light functions are not called on regular intervals.


Missing pongs: sometimes we miss pongs because the code does not go through the ‘if’ statement fast enough.  This has two consequences:


a.       Limits our range.  Our minimum distance is limited by the speed of our code. We tried keeping the code as short as possible to lower our boundary.


b.      Errors in distance calculations: when we miss the wave from the first pulse we still read a subsequent one.  Since the timers continue to run it created errors in our distance calculations, objects seem to be farther away than they really are.  We fixed this problem by having the running average.






The resulting signal is shown below.  Channel 2 (bottom) shows the transmitted pulse that has amplitude of 12V.  A single pulse in the picture is actually a set of five short pulses.  Channel 1 (top) shows the received signal that has amplitude of 5V.



Figure 5.  Transmitted signal (bottom) and received signal on 1ms scale



A ghost signal caused by the receiver directly picking up the transmitted signal is also present on Channel 1.  Since the ghost signal is gated out when calculating the effective distance, it’s of no significance in terms of our result.  The picture below shows the same signal on a smaller time scale.



Figure 6.  Transmitted signal (bottom) and received signal on 500us scale



The receive signal will be closer to the transmitted signal if the object is closer to the device and vice versa.


Throughout our circuit-testing phase we encountered countless noise issues and random behaviors that compromised our result.  For instance, running a wire near the MCU caused spikes and flickers in both the transmitted and received signal.  Orienting the whiteboard in certain direction sometimes caused random noise and even gently squeezing a wire would throw off the signal.  Since we are dealing with ultrasound, it was imperative to reduce noise as much as possible to get a clean signal out from the circuit and the MCU.  On the contrary to our prediction that the fan in the lab or other group’s radio-frequency device would interfere with our circuit, they had no effect on our circuit as far as the noise was concerned.  We tried turning on and off the fan and even asked couple neighboring group to turn off their motors or transmitters, but that didn’t affect the quality of our output.  The source of some of the random circuit behaviors we encountered is still in question.  Nonetheless, we managed to get a clean signal from the receiver.


The range of our device was approximately 40cm.  As mentioned before, the effective range is proportional to the power of the transmitted pulses.  With 9V transmitting pulses we got a range of about 34cm; 12V pulses gave us 40cm range and increasing the voltage gave us slightly greater range.  We had to keep in mind that further amplification would result in more noise and that we put more emphasis on accuracy than the range for our application.


To test the accuracy of the device we measured the actual distance between the sensors and the object with a ruler and compared that to the distance reading we got from the LCD.



Figure 7.  Measuring distance between the box and the sensors with ruler and ParKontroller



Figure 8.  Actual distance of 20cm VS. ParKontroller reading of 20cm



As you can see from Figure 8, ParKontroller’s distance reading is very close to the actual distance measured by the ruler.  Further testing showed that ParKontroller has an accuracy of Ī1cm with one exception.  Readings done in the first distance interval (0 – 15cm) gave some misreading.  For instance, an actual distance of 5cm was read as 10cm and actual distance of 10cm was read as 14cm.  We believe that placing an object too close to the ultrasonic transducers causes the receiver to be unable to pick up the transmitted wave properly like in subsequent distance intervals.  


ParKontroller emits ultrasounds at 40kHz, which is beyond what human ears can hear, so it causes no harm to the public.  Furthermore, it can be used by anyone who can power on the device, watch the LED indicators, or hear the warning beeps from the piezo speaker.






ParKontroller can detect an object within a range of 40cm with accuracy of Ī1cm in the distance interval of 15 to 40cm.  If we were to do this project again, we would try to increase the effective range and enhance the accuracy by implementing some kind of noise reduction circuit. Furthermore, we would like to implement an array of ultrasonic receiver so that we can determine the location of the object with respect to the ultrasonic transmitter.  Finally, usability of the ParKontroller can be improved by making it completely portable and attachable to the bumper of any commercial vehicles.



Intellectual Property Considerations


As discussed in the High Level Design section, ParKontroller is a standalone device that is designed using off-the-shelf parts and basic circuit design principles; hence none of the copyright, patents, or intellectual property is violated.



Ethical Considerations


1.      To accept responsibility in making decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment


Our initial goal of this project was to create a parking sensor system with a range of up to 1m with accuracy of Ī1cm.  However, our resulting range was shorter with less accuracy.  Had this been used by a daily driver it may cause safety issues, but since our ParKontroller will not be commercialized and distributed to public for use, it will not endanger the public or the environment.


3.      To be honest and realistic in stating claims or estimates based on available data


All results and data listed are shown and verified through multiple sets of tests done in lab.  It will also be thoroughly demonstrated in lab during check out session.


5.      To improve the understanding of technology, its appropriate application, and potential consequences


We took a simple concept of SONAR technology and used our hardware and software skills and intuition to create a useful application.  Throughout the process of delivering the final product, we gained much more than just understanding the technology and its application.  This hands-on experience made us realize how other variables such as random noise, wire capacitance, and temperature can affect the circuit and compromise the result.  These factors are often ignored in theory-based classes where mostly ideal situation is considered.  We believe that it’s important to learn and experience them to appreciate real-life engineering.


7.      To seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others


We tried to seek advice and help from Professor Land and all TAs available in the lab whenever no definite solution was readily seen by both members of the group.  They even took their own time to help us go through the problem during busy times and we are very appreciated by their support.


8.      To treat fairly all persons regardless of such factors as race, religion, gender, disability, age, or national origin


The ParKontroller can be used by persons of all race, religion, gender, age, and origin.  We also tried to accommodate people with disabilities.  For instance, we designed an array of LEDs to indicate the proximity of the object for people with hearing problems.  We also implemented a speaker to emit warning beeps for people with poor sights.  Regardless of these implementations, a small portion of the people around the world would not necessarily be using this device if they are unable to drive for various reasons.


10. To assist colleagues and co-workers in their professional development and to support them in following this code of ethics


Ethics is taken seriously at this institution and is repeatedly mentioned and encouraged at the beginning of each semester by many professors.  As students, we follow this code of ethics and try to remind it to friends and classmates whenever we see fit.




Appendix A:  Program Listing



Source code in C:  ParKontroller.c



Appendix B:  Schematics

Figure 9. Complete schmatic of ParKontroller circuit


ParKontroller_schematic (enlarged version)


Figure 10.  Final Circuit



Appendix C:  Parts List






Atmel Mega32












Power Supply




Ultrasonic Transducer set



Jameco 40TR16F

Hex Inverter



Texas Instrument 74HC04N

Hex Inverter Schmitt Trigger



Texas Instrument 74HC14N




From lab

Piezo Speaker



From lab

Total Budget





Appendix D:  Team Contribution


James was responsible for hardware design, construction, testing, and debugging.  Mauricio was responsible for software design, testing, and debugging.  All other tasks such as parts search and ordering, documentations, and webpage were shared equally by both members of the group.





Ultrasonic Parking Assistant

Handheld Ultrasonic Rangefinder

Atmel Mega32 Microcontroller

Texas Instrument LM311: Differential Comparator

Texas Instrument 74HC04N: Hex Inverter

Texas Instrument 74HC14N: Hex Schmitt-Trigger Inverter





We would like to thank Professor Land and all teaching assistants for helping out not only our group but also the rest of the class days and nights in the lab.  Big thumbs up for Cornell Electrical and Computer Engineering department for offering a great real-world hands-on engineering course.  We really enjoyed it!





“Mauricio Tackling CodeVision”


“James Testing ParKontroller”