EEWeb Pulse - Volume 3

PULSE EEWeb.comIssue 3

July 19, 2011

Ben Coughlan Unmanned Aircraft

Electrical Engineering Community

EEWeb

Contact Us For Advertising Opportunities

[email protected]

www.eeweb.com/advertising

Electrical Engineering CommunityEEWeb

Digi-Key is an authorized distributor for all supplier partners. New products added daily. © 2011 Digi-Key Corporation, 701 Brooks Ave. South, Thief River Falls, MN 56701, USADigi-Key is an authorized distributor for all supplier partners. New products added daily.

www.digikey.com/techxchange

It’s all about connections.

The user-to-user forum is for everyone, from design engineers to hobbyists, to discuss technology, products, designs and more. Join the discussions that match your interest or offer your expertise to others.

Join the discussion now at:

discussions

hobbyists

engineers

industry experts

resourceslinks

technical documentswhite papers

reference designs

application notes

community

power

microcontroller

lighting

wireless

sensor

students

http://bit.ly/kDYHm7

EEWeb | Electrical Engineering Community Visit www.eeweb.com 3

TABLE O

F CO

NTEN

TSTABLE OF CONTENTS

Ben Coughlan 4PHD SCHOLAR, AUSTRALIAN NATIONAL UNIVERSITYInterview with Ben Coughlan, consultant/engineer, working on unmanned aircraft.

Unmanned Aerial Vehicles 7 BY BEN COUGHLAN A look into the study of aircraft behavior.

Accuracy of the Computational 9Experiements called Time Domain Simulation BY MICHAEL STEINBERGER WITH SISOFT

Advantages of Packaging a Proximity Sensor with an Ambient Light Sensor BY TAMARA SCHMITZ WITH INTERSIL

RTZ - Return to Zero Comic 17

Consumer devices like cell phones are using more and more sensors to save power and enhance our interaction with them. It is a natural question for cell phone manufacturers to ask if any of these sensors can be co-packaged to save power, space, and cost.

Time domain simulations of high speed serial channels are really computational experiments rather than mathematical evaluations. They have confidence limits just like any physical experiment, and users should determine what those confidence limits are.

14


INTERVIEWFEA

TURED IN

TERVIEW

Ben Coughlan Unmanned Aerial VehiclesHow did you originally get into electrical engineering and electronics?

My interest in electronics can go back as far as playing with “Funway into Electronics” kits from Dick Smith. My background since then has been mostly software. I completed my Bachelor’s degree in Software Engineering at the Australian National University in 2009 while working at Codarra Advanced Systems.

After getting a taste for embedded software development on a few projects, I jumped at the chance to return to university to complete a PhD focused on Unmanned Aerial Vehicles. So far this has taken me well outside of my software comfort zone involving a lot of electronic and mechanical design.

My interest in electronics can go

back as far as playing with ‘Funway into Electronics’ kits from Dick Smith.

How do you find working in other disciplines given your software background?

I touched on a number of other disciplines during my degree including basic electronics and mechanics. The things I find most useful are the abstract concepts required for systems

engineering. These concepts are very familiar after learning about software architecture and design.

The thing I find the most useful is the abstract concepts

required for systems engineering.

Ben Coughlan - PhD Student, The Australian National University


INTERVIEWFEA

TURED IN

TERVIEW

When I approach a new discipline, it’s easy to map the required system knowledge. It’s then just a matter of learning the specifics of design and implementation for what I’m trying to build.

What are your favorite hardware tools that you use?

The tool I use most often would easily be my callipers. Simple yes, but whenever I need to build a model, which is pretty often, my callipers are invaluable.

I should probably also mention my cast-iron frying pan. It’s the easiest way for me to reflow a board with surface mount components and it makes pretty great pancakes.

What are your favorite software tools that you use?

I think my two favorite pieces of software would be Altium Designer and Solid Works. Between these two products I can design and model just about everything I want to build. Being able to create virtual prototypes is invaluable when money for physical prototypes is hard to come by.

What is on your bookshelf?

There are a lot of textbooks. The two most relevant/recent additions are Feedback Control of Dynamic Systems by Franklin Powell and Probabilistic Robotics by Thrun, Burgard, and Fox.

On the fiction side I’ve been enjoying the Book of the New Sun series on audio book. At the moment I’m listening to Catch-22.

Do you have any tricks up your sleeve?

Nothing specific. My usual approach always involves doing things the hard way, or from scratch myself. Often I learn why I shouldn’t be doing it myself from scratch but it does leave me with a better understanding of how something works. As the quote goes: “Aim for the moon; even if you miss you’ll land among the stars.”

It always helps to surround yourself with people that know things. I’m lucky to have experienced colleagues that can easily answer all my silly questions. Otherwise I can always turn to online forums. It’s important to involve yourself and your work with the world.

Do you have any note-worthy engineering experiences?

My most noteworthy accomplishment would be an award for innovation my team and I won in 2009 at the Australian National iAwards for a software framework supporting the development of robotic applications on Linux platforms.

The Linux Robotics Framework was my final year project for my Bachelor’s degree. I managed a team of five other students to produce the framework for our sponsor Nias Digital. The framework was intended to provide a collection of software components and accompanying design concepts to simplify the development of robots running Linux. This included a hardware abstraction layer with drivers for a few interface devices like the

Pololu TReX motor controllers and serial servo controllers, as well as some higher level functions like steering, throttle, and a controller for a 3 DOF arm.

We built a robotic vehicle named ‘Buzz’ as a demonstration for our project. Starting with a 4WD RC truck, we constructed a chassis to mount the extra hardware we wanted. This included a pan/tilt CMOS camera, a 3DOF arm with a gripper, various controller boards and transceivers for 2.4GHz Wi-Fi and video. The main processor was a 32bit AVR on an Atmtel NGW-100. This was a conveniently sized, low-powered board that our sponsor was using at the time.

More recently, the first prototype of Asity, the avionics board I’ve developed, came off of the frying pan and actually worked on the first try. It being my first significant electronic design, I was pretty happy with this.

What are you currently working on?

My PhD is investigating energy usage in unmanned aerial vehicles. The goal is to monitor energy levels and consumption onboard the aircraft in real time and try to develop behaviors that optimize these.

Including solar and wind energy, I hope this will lead to extreme-endurance aircraft that maintain the capabilities required in the growing UAV industry.

Can you tell us more about your UAV research ?

My research is investigating the


INTERVIEWFEA

TURED IN

TERVIEW

energy usage of onboard UAVs. This includes monitoring the total energy stored in the system, including the aircraft’s velocity and altitude, in addition to the battery. The goal is to develop flight behaviors that optimize energy usage in reaction to air conditions and energy inputs (e.g., solar). In suitable aircraft or use cases, this will hopefully increase the endurance of the system. Simply put, I would like to show that the most efficient behavior for an aircraft is not necessarily straight and level.

This is a highly experimental project so I have had the opportunity to develop many custom hardware components. The main avionics is a custom board I’ve named Asity. This is a processor, inertial sensor pack, and radio in a small package to fit in the slim fuselage of the gliders I work with.

The main processor is actually an FPGA to allow for high integrity, interrupt-free, and flexible design of the avionics firmware. FPGAs are notoriously power hungry, so I have used the Actel ProAsic3 series of chip. Being flashed based, in contrast to their SRAM based competitors, they have a much lower current draw and don’t require any configuration memory. The current Asity prototype has 1M system gates; time will tell if this is sufficient. I am avoiding soft-core processors for as long as I can, and I believe I can build a complete avionics system in HDL.

While I’m developing an experimentation platform, I’ve decided to include capabilities

for the Outback Rescue Challenge. I hope to compete in 2012 with my 4 meter glider.

What has been your favorite project?

My current one, hands down. I was into model aircraft as a kid and now I get to play with them for a living. Given this is a research project, I enjoy a lot of freedom with what I work on.

What direction do you see your business heading in the next few years?

I still have a few years in the comfort of academia. Between now and then I hope to develop something that can support further research. My main goal is just to keep working on the same or similar projects.

What challenges do you foresee in our industry?

The biggest challenge in the UAV industry specifically is mostly legislative, although this is driven by quite reasonable, technical short-comings.

Aircraft are not currently permitted to fly truly unmanned without constant supervision from someone who can take control. This does limit the range and utility of such aircraft.

The challenge for engineers in this field is to develop systems that are safe, reliable, and capable of sensing and reacting to abnormal situations.


PROJECTFEA

TURED PRO

JECTThere are two aircraft involved

with my research. Both are gliders, but have drastically different characteristics. As my research is focused mainly on the behaviour of the aircraft at this point, the design of the airframe is out of scope. For this reason, my supervisor and I selected commercial off-the-shelf airframes and their power trains to provide the most flexibility.

The quicker of the two is the Alex F5B. This is a popular competition ‘hotliner’ and one of the most exciting aircraft in our hangar. The fuselage is moulded with Kevlar and fibre glass with carbon reinforcement. The wing is 1.8 meters of moulded carbon fibre with a carbon spar. It has a 1.5 kilowatt Neu motor and a 16x10 inch folding prop which can deliver up to 4.9 kilograms of static thrust. It weighs just over 1.7 kilograms and can reach speeds well over 300 kilometres per hour.

At the other end of the scale is the Pulsar 4E. This is a much larger, much slower, and much lighter aircraft than the Alex F5B. This was selected for its potential carrying capacity and endurance. The Pulsar has balsa ribbed, carbon reinforced wings spanning 4 metres and a fuselage of fibre glass and carbon sheet.

The Pulsar 4E is still under construction. We intend to fit it with

a modest 550 watt Neu brushless motor, 3 cell LiPo battery, and a prop between 14x6 and 15x8 inches depending on results and load. All of it is expected to weigh up to 2.5 kilograms without a payload, and cruise at around 50-60 kilometres per hour.

The reason the Pulsar 4E was chosen for its carrying capacity is the Outback Rescue Challenge coming up in October 2012. This competition requires an aircraft to deliver 500 millilitres of water to a dummy stranded in the Australian Outback. The extra weight is a significant increase to the wing loading on most gliders. The Pulsar 4E is hopefully big enough and built to a high enough quality to accommodate it.

The aircraft pictured is my own plane, the Paprika. It has a wingspan of 2 metres and weighs about 1.5 kilograms. It is a similar but less extreme set up to the Alex F5B featuring an 850 watt Hyperion motor and a 12x6 inch folding prop with an estimated static thrust of 2.8 kilograms.

You may be wondering why these ‘gliders’ have such massively powerful motors onboard. A DC motor is most efficient when it’s off, and only slightly less efficient when it’s running at its maximum RPM. Anything between these two

Unmanned Aerial Vehicles extremes is wasteful. The aircraft themselves are most efficient when they are cruising straight and level at an optimal cruise speed. The idea behind overpowering these gliders is to maintain cruise speed while climbing as quickly as possible (i.e., vertical), and run the motor for as short a time as possible at maximum throttle. This leads to long periods of gliding with short, aggressive climbs when needed.

One of the biggest challenges when working with these kinds of aircraft is space in the fuselage. Even the 4 metre wide Pulsar only has a 60 mm wide fuselage. This impacts the size of the avionics onboard as well as the selection and placement of antennas.

For the Outback Challenge, the Pulsar will have three separate radios on board with at least five antennas between them. For manual control I’m using standard 2.4GHz RC equipment. Telemetry, command and control, and data are sent over a 900MHz, 250kbit/s link. Finally, I have a 151MHz, 10kbit/s uplink for failsafe termination. Given the amount of carbon in the airframe and the lengths of the longer wavelength antennas, their placement takes a lot of planning.

Studying Aircraft Behavior By Ben Coughlan

Avago Technologies new AEAT-6600 Hall E� ect Magnetic Encoder delivers optimal solutions for Robotic, Industrial and Medical systems designers.

• World’s highest resolution

• 16-bit absolute positiion through SSI

• Programmable Magnetic Rotary Encoder IC

• 16-pin TSSOP package

• Power down mode

New Encoder for the Worst Case Environments

Avago Technologies Motion Control Products

For more information and to requesta free sample go to: www.avagotech.com/motioncontrol

http://bit.ly/jpn9V5


Mike SteinbergerLead Architect

Serial Channel ProductsAccuracy of theComputationalExperiments Called

Time DomainSimulationsEvaluation vs. Experimentation

We’re used to thinking of results that come from computers as being completely accurate and much more precise than we need. Many times, this leads to a false sense of security due to any of three possible problems:

1. Wrong Computation: The computation performed wasn’t the correct one to begin with. For example, the boundary conditions imposed were unrealistic (3D field solver users beware) or the equations chosen did not apply to the problem at hand.

2. Numerical Inaccuracy: The algorithms used to solve the equations were not perfect (See [1] for the definitive practical treatment of this subject).

3. Incomplete Coverage: Not all relevant cases were considered.

If none of these problems occurred, then we could call that computation an evaluation. Otherwise, we should consider the computation to be a computational experiment subject to the same uncertainties as a physical experiment. That is, the computational experiment can have sources of both random and systematic error, and there are confidence limits which apply to the results. One should be able to draw the error bars around the results and account for these error bars when making engineering decisions.

This article considers time domain simulations of high speed serial channels as computational experiments, and explores the confidence limits that should be applied to such experiments. For the

experiments considered here, the most critical problem is incomplete coverage. Serial channel performance is strongly affected by intersymbol interference and, as demonstrated in [2], all messages of length 64 or longer should be included in the experiment in order to obtain consistently accurate results. Suffice it to say that no time domain simulation will ever come close to the more than 10^19 bits required.

While the results shown in this article may be of some direct value, the goal is to demonstrate some techniques that can be used to determine confidence limits for time domain simulations in general.

While the results shown in this article may be of some direct value, the goal is to demonstrate some techniques that can be used


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

to determine confidence limits for time domain simulations in general.

Experimental Approach

The channel simulated was 5 Gb/s data transmitted over 1.5m of PC board trace in a low loss dielectric. There was no equalization at the transmitter and linear equalization at the receiver.

The experimental approach taken was to vary the data pattern used in the time domain simulation as well as the length of the time domain simulation. To make sure that the data patterns were independent, they were drawn from different starting positions in the same 263-1 linear feedback shift register (LFSR) pattern. This LFSR pattern has the advantage that it is much longer than any of the time domain simulations in the experiment. If a data pattern were to be repeated over the course of a simulation, then the data patterns would no longer be independent.

Rather than choosing different seeds for the same LFSR pattern, we could have chosen different LFSR patterns. If the different data patterns were long enough to produce a representative sample of the intersymbol interference, that would have been a valid choice. An alternating 1/0 pattern or a 27-1 LFSR would not have provided an adequate sample of the intersymbol interference, however.

This approach was applied to simulations of three different lengths: one million bits, ten million bits, and one hundred million bits. These results can be used to estimate how much the confidence limits can be improved by running longer time domain simulations.

Statistical analysis was also applied to the same channel. Statistical analysis is entirely different from time domain simulation in that it computes the statistics of the eye diagram directly rather than compiling them from samples of a time domain waveform. This computation has the advantage that it directly accounts for a statistically significant sample of the intersymbol interference, and the disadvantage that it is only rigorously applicable to linear, time invariant channels. Since the channel used in this study was truly linear and time invariant, this statistical analysis can be considered to be an evaluation rather than a computational experiment, and its results are what the average of the time domain simulation results should be. For the purposes of this study, the statistical analysis results are the “right” answer.

Results

A performance analysis of a high speed serial link produces a lot of results offering many different ways to look at the behavior of the channel. It is not the goal of this article to explore the many ways in which channel performance can be presented. Rather, the goal is to show how the results of time domain simulations vary. We will therefore use three different outputs as examples:

1. Inner eye contours: The shape of the inside of the eye diagram at a particular probability. The probabilities shown are 10-3, 10-6, 10-9, and 10-12.

2. Bathtub curves: Plots of the probability of error as a function of sampling time. These curves are called “bathtub” curves because they often resemble the cross section of a bathtub.

3. Eye width: The width of the open portion of the eye diagram. This value loosely correlates with timing margin.

Figure 1 is an example eye diagram for the channel. All the eye diagrams in this study look very similar to each other.

The following figures show the inner eye contours for the three different lengths of time domain simulation. Note that as the length of the time domain simulation progresses from one million bits to one hundred million bits, the 10-12 contour becomes clearly distinct from the 10^-6 contour, and it’s almost possible to discern the 10^-9 contour. Notice also that the lower probability contours have

Table 1: The data patterns used.

Data Pattern DefinitionsPattern Number Pattern Seed

1 2^63-1 LFSR 8191

2 2^63-1 LFSR 8291

3 2^63-1 LFSR 8391

4 2^63-1 LFSR 8491

5 2^63-1 LFSR 8591

6 2^63-1 LFSR 8691

7 2^63-1 LFSR 8791

8 2^63-1 LFSR 8891

9 2^63-1 LFSR 8991

10 2^63-1 LFSR 8091


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

Volts

(v)

Prob

abili

ty

100.0

Persistent Eye Diagram1.5m low loss PCB trace

Time ( s)

-50.0 0.0 50.0 100.0

0.60

0.40

0.20

0.0

-0.20

-0.40

-0.60

_ 2.4E-2

_ 7.1E-3

_ 6E-4

_ 3.7E-7

_ 4.8E-12

Volts

(mV)

Prob

abili

ty

100.0

Eye Diagram ContoursOne million bit simulations with ten different data patterns

Time ( s)

-50.0 0.0 50.0 100.0

150.0

100.0

50.0

0.0

-50.0

-100.00

-150.00

_ 1E-3

_ 1E-4

_ 1E-6

_ 1.1E-12

_ 1E-12

Figure 1: Example eye diagram.

Figure 2: Inner eye contours for one million bit simulations.

Volts

(mV)

Prob

abili

ty100.0

Eye Diagram ContoursTen million bit simulations with ten different data patterns

Time ( s)

-50.0 0.0 50.0 100.0

150.0

100.0

50.0

0.0

-50.0

-100.00

-150.00

_ 1E-3

_ 1E-4

_ 1E-6

_ 1.1E-12

_ 1E-12

Volts

(v)

Prob

abili

ty

100.0

Inner Eye Diagram ContoursOne hundred million bit simulations with ten different data patterns

Time ( s)

-50.0 0.0 50.0

+Sensitivity 25 0mV

–Sensitivity –25 0mV

100.0

150.0

100.0

50.0

0.0

-50.0

-100.00

-150.00

_ 1E-3

_ 1E-4

_ 1E-6

_ 1.1E-12

_ 1E-12

considerably more variance than the higher probability contours. The following figures show the bathtub curves for the same sets of simulations, along with the bathtub curve for the statistical analysis (shown in red) and the clock PDFs for the time domain simulations. Note that this way of viewing the data makes it much easier to see the variation due to the different data patterns.

Figure 8 is an expanded view of Figure 5, “Bathtub curves for one million bit simulations and statistical analysis,” on page 5, showing how the bathtub curves diverge for the ten different data patterns. Note that the bathtub curves are nearly the same for the higher error probabilities, but then diverge for the lower probabilities.

Finally, Table 2 summarizes the mean and standard deviation of the eye width for the time domain simulations and statistical analysis. Note that as the time domain simulation gets longer, the eye width approaches the statistical analysis result. Note also that increasing

Figure 3: Inner eye contours for ten million bit simulations.

Figure 4: Inner eye contours for one hundred million bit simulations.


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

Prob

abili

ty

100.0

Bathtub Curve SetBLACK: Ten million bit time domain simulations using ten different data parameters RED: Statistical Analysis

Time ( s)

-50.0 0.0 50.0 100.0

1E0

1E-2

1E-4

1E-6

1E-8

1E-10

1E-12

1E-14

1E-16

1E-18

1E-20

Eye Width

x1: (-62.150ps)x2: (65.040ps)dx: 127.20ps

Prob

abili

ty

100.0

Bathtub Curve SetBLACK: Ten million bit time domain simulations using ten different data parameters RED: Statistical Analysis

Time ( s)

-50.0 0.0 50.0 100.0

1E0

1E-2

1E-4

1E-6

1E-8

1E-10

1E-12

1E-14

1E-16

1E-18

1E-20

Prob

abili

ty

100.0

1E0

1E-2

1E-4

1E-6

1E-8

1E-10

1E-12

1E-14

1E-16

1E-18

1E-20

Bathtub Curve SetBLACK: One hundred million bit time domain simulations uisng ten different data patterns RED: Statistical Analysis

Time ( s)

-50.0 0.0 50.0 100.0

Prob

abili

ty

131.0 132.0 133.0 134.0 135.0 136.0 137.0 138.0 139.0

1E-4

1E-6

1E-8

Expanded Bathtub Curve SetBLACK: One million bit simulations with ten different data patterns RED: Statistical Analysis

Time ( s)

the length of the simulation doesn’t reduce the standard deviation very much.

Discussion and Conclusions

The accumulation of a persistent eye from a time domain simulation is an event counting experiment very much like counting radioactive particles with a Gieger counter. That is, for any particular bin in the eye diagram, the expected number of events is equal to the probability density for that particular bin times the number of bits simulated. Also, as in the Gieger counter experiment, the variance of the even count is equal to the square root of the number of events counted [3]. Therefore, as the number of expected events goes down, the variance of the count becomes a larger percentage of the count. In the limit that only one event is expected (for example, along the inner contour of the eye diagram), the variance is also one, meaning that maybe there will be an event counted and maybe there won’t.

One simple conclusion from the above reasoning is that the number of bits in a time domain simulation should be greater than the reciprocal of the probability of error. That is, if the target bit error rate is 10-12, the time domain simulations should be at least 10-12 bits long. That’s not an experiment I’m anxious to try.

The more important conclusion, however, is that there is a statistical variation associated with the results of any time domain simulation of a high speed serial channel. It’s important that the user has a reasonable estimate of that variance so that they can use the

Figure 5: Bathtub curves for one million bit simulations and statistical analysis.

Figure 6: Bathtub curves for ten million bit simulations and statistical analysis.

Figure 7: Bathtub curves for one hundred million bit simulations and analysis.

Figure 8: Expanded view of one million bit bathtub curves.


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

simulation results to make reliable engineering decisions. This article has demonstrated one approach for obtaining such an estimate.

References

[1] Press, Teukolsky, Vetterling and Flannery, Numerical Recipes in C++, second edition, Cambridge University Press, 2002.

[2] Steinberger, “Exploration of Deterministic Jitter Distributions”, DesignCon2008.

[3] Bevington, Data Reduction and Error Analysis for the Physical Sciences, McGraw-Hill, 1969.

About the Author

Michael Steinberger, PhD, has over 30 years experience in the design and analysis of very high-speed electronic circuits. Dr. Steinberger began his career at Hughes Aircraft, designing microwave circuits. He then moved to Bell Labs, where he designed microwave systems that helped AT&T move from analog to digital long-distance transmission. He was instrumental in the development of high-speed digital backplanes used throughout Lucent’s transmission product line. Prior to joining SiSoft, Dr. Steinberger led a group of over 20 design engineers at Cray, Inc. responsible for SerDes design, high-speed channel analysis, PCB design, and custom RAM design.

Table 2: The mean and standard deviation of the eye width for the time domain simulations and statistical analysis.

Eye Width ResultsSimulation Duration Mean Eye Width (pS) Eye Width Standard

Deviation (pS)One million bits 142.5 0.99

Ten million bits 138.92 0.86

One hundred million bits 137.81 0.75

Statistical analysis 137.5 0

http://bit.ly/pjX3rr


Ambient LightSensor Tamara Schmitz

Senior Principal Applications Engineerand Global Training Coordinator

Advantages of Packaging aProximitySensorwith an

C onsumer devices like cell phones are using more and more sensors to save power

and enhance our interaction with them. Some of the latest devices have more than ten sensors. It is a natural question for cell phone manufacturers to ask if any of these sensors can be co-packaged to save power, space, and cost. There are many good reasons for co-packaging a Proximity Sensor with an Ambient Light Sensor. After clarifying their roles, their operations and some simple differences, these reasons will be discussed.

An ambient light sensor acts like an eye for a system that measures the surrounding light. If the device is indoors, it is the light in a room. If the device is outside, it could be bright from sunlight or less in the

shade. The measurement of this amount of light is made by a light emitting diode (LED) and quantified to enable a system to adjust its own display. If the surrounding light is bright, the backlight of the display is run at full power. If the area is darker, the backlight is reduced, saving power. Incidentally, this is also pleasing to the user. Have you ever tried looking directly into a bright light in a dark room? Eyes can tire quite quickly from this overstimulation, so the dimming function provided by the ambient light sensor is a welcome addition. The challenge is that silicon diodes naturally react to a wide spectrum of wavelengths. An ambient light sensor must be designed to mimic the human eye. This filtering is one of the quality measurements of the sensor, especially since the majority

of light sources have energy in the infrared wavelengths (think about which light sources also give off heat). To demonstrate this filtering, see the plot in Figure 1. The ISL29028A from Intersil provides the best match of filtering in its ambient light sensor compared to the response of the human eye.

A proximity sensor measures an infrared signal. Instead of the signal coming from the surrounding area, the proximity sensor drives an external infrared LED. The signal from this LED is directed out above the proximity sensor. If something enters the

path of the infrared emission, some will be reflected back toward the sensor. There is another LED within the proximity sensor ready to pick


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

The next reason is slightly more subtle: location. Both the proximity sensor and ambient light sensor need access to the outside world for proper function, so their placement within a system is strongly related to their sensitivity and their correct operation. In some cases where an ambient light sensor is packaged alone, it has been placed deeper within a system—behind a speaker screen or further down a printed circuit board from a nearby external access point. This practice has pushed ambient light sensors to be more and more sensitive to this indirect light. Light intensityis measured in lux. While sunlight exceeds 100,000 lux, these

ambient light sensors can detect 0.001 lux! That’s a tiny fraction of a candle’s light. For a practical array of the lux levels of various light sources, see Figure 2.

A final and compelling reason to house the proximity sensor and ambient light sensor in the same package is that it enables quick and undisturbed communication between the two. Remember in the beginning during the explanation of the operation of the ambient light sensor that we explained how its sensor must mimic the human eye. The human eye does not see infrared light, so the ambient light sensor is specifically designed to remove as much energy in the

Direct Sunlight 100,000 to 130,000 LuxFull Daylight 10,000 to 20,000 LuxCloudy Day 1,000 LuxOffice Lights 300-500 LuxCandle Light/Dark 10-15 Lux

“Lux” - Measure of light density within the visible spectrum.

Wavelength (nm)

Norm

alize

d Res

pons

e

300

1.2

1.0

0.8

0.6

0.4

0.2

0

-0.2400

IR AndProximitySensing

HumanEyeResponse

AmbientLightSensing

500 600 700 800 900 1000 1100

Figure 1: Human eye response, ambient light sensor spectrum and proximity sensing spectrum of the ISL9028A

Figure 2: Table of lux values

up this reflected light. This allows a system to react to someone or something coming close. A great example of this is on many cell phones. The user doesn’t want their cheek to be “pressing buttons” or hanging up on a call while they have the phone up to their ear. It would be convenient if the phone could turn off the touch screen whenever the phone is brought up to a user’s ear. This is exactly what the proximity sensor allows the phone to do.

These two separate systems are now being offered in one package. Are semiconductor companies overexcited by their drive to integrate more features and systems, or are there real advantages in co-packaging the proximity sensor with the ambient light sensor?

While it is true that they are two separate systems, they are both optical systems utilizing a sensing LED. They collect information from the outside world, quantify it, and provide it to the system. Currently,

the system predominantly uses the information to adjust the backlight of the display. The information could just as easily be used to control more system features in the future.

Of course, it is convenient to save space, to share supplies, and to combine power supply bypassing. The size of the solution is a critical parameter in many systems, especially portable ones. The co-packaging of the proximity sensor and ambient light sensor is an enabling step in the development of more compact, yet feature enhanced, cell phones.


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

both the ambient light sensor and the proximity sensor.

Locating the ambient light sensor and proximity sensor in the same package provides a number of advantages. They both enable power savings through the dimming or shutdown of the backlight and interface with the same system blocks. Co-packaging saves space and reduces complexity. Both sensors need access to the outside of the system and would likely be located in similar places. And since interference from the proximity sensor system can disturb the ambient light sensor, coordination between these two features is paramount. It is for all of these reasons that there is a huge advantage in co-packaging the proximity sensor and ambient light sensor.

About the Author

Tamara Schmitz is a Senior Principal Applications Engineer and Global Technical Training Coordinator at Intersil Corporation, where she has been employed since 2007. Tamara holds a BSEE and MSEE in electrical engineering and a PhD in RF CMOS Circuit Design from Stanford University. From 1997 until 2002 she was a lecturer in electrical engineering at Stanford; from 2002 until 2007, she served as assistant professor of electrical engineering at San Jose State University.

infrared wavelengths as possible. Remember also that the proximity sensor operates precisely within the infrared spectrum. Whenever the proximity sensor is attempting the make a measurement, it is simultaneously sending out infrared light in the hope of bouncing off of a nearby object. This infrared energy could easily swamp the ambient light sensor’s input and cause false positive measurements, an instance in which the ambient light sensor measures more light energy than is actually in the surrounding area. It is for this reason that it is vital to coordinate the operation of the ambient light sensor with the proximity sensor. While this can be accomplished with a microcontroller, it is easier and a much smaller footprint to have this coordination within a single package. That one package houses

http://bit.ly/jebqhL


RETURN TO

ZERORETURN TO ZERO


RETURN TO

ZERORETURN TO ZERO

Contact Us For Advertising Opportunities

[email protected]

www.eeweb.com/advertising

Electrical Engineering CommunityEEWeb

http://bit.ly/l6u6Cx

EEWeb Pulse - Volume 3

Documents

Transcript of EEWeb Pulse - Volume 3