Showing posts with label wireless communication. Show all posts
Showing posts with label wireless communication. Show all posts

Wednesday, March 21, 2012

Using Current Drain Measurements to Optimize Battery Run-time of Mobile Devices

One power-related application area I do a great deal of work on is current drain measurements and analysis for optimizing the battery run-time of mobile devices. In the past the most of the focus has been primarily mobile phones. Currently 3G, 4G and many other wireless technologies like ZigBee continue to make major inroads, spurring a plethora of new smart phones, wireless appliances, and all kinds of ubiquitous wireless sensors and devices. Regardless of whether the device is overly power-hungry due to running data-intensive applications or power-constrained due to its ubiquitous nature, there is a need to optimize its thirst for power in order to get the most run-time from its battery. The right kind of measurements and analysis on the device’s current drain can yield a lot of insight on the device’s operation and efficiency of its activities that are useful for the designer in optimizing its battery run-time. I recently completed an article that appeared in Test & Measurement World, on-line back in November and then in print in their Dec 2011- Jan 2012 issue. Here is a link to the article:

A key factor in getting current drain measurements to yield the deeper insights that really help optimize battery run-time is the dynamic range of measurement, both in amplitude and in time, and then having the ability to analyze the details of these measurements. The need for a great dynamic range of measurement stems from the power-savings nature of today’s wireless battery powered devices. For power-savings it is much more efficient for the device to operate in short bursts of activities, getting as much done as possible in the shortest period of time, and then go into a low power idle or sleep state for an extended period of time between these bursts of activities. Of course the challenge for the designer to get his device to quickly wake up, stabilize, do its thing, and then just as quickly go back to sleep again is no small feat! As one example the current drain of a wireless temperature transmitter for its power-savings type of operation is shown in Figure 1.

Figure 1: Wireless temperature transmitter power-savings current drain

The resulting current drain is pulsed. The amplitude scale has been increased to 20 µA/div to show details of the signal’s base. This particular device’s current drain has the following characteristics:
• Period of ~4 seconds
• Duty cycle of 0.17%
• Currents of 21.8 mA peak and 53.7 µA average for a crest factor of ~400
• Sleep current of 7 µA
This extremely wide dynamic range of amplitude is challenging to measure as it spans about 3 ½ decades. Both DC offset error and noise floors of the measurement equipment must be extremely low as to not limit needed accuracy and obscure details.

Likewise being able to examine details of the current drain during the bursts of activities provides insights about the duration and current drain level of specific operations within the burst. From this you can make determinations about efficiencies of the operations and if there is opportunity to further optimize them. As an example, in standby operation a mobile phone receives in short bursts about every 0.25 to 1 seconds to check for incoming pages and drops back into a sleep state in between the receive (RX) bursts. An expanded view of one of the RX current drain bursts is shown in figure 2.

Figure 2: GPRS mobile phone RX burst details

There are a number of activities taking place during the RX burst. Having sufficient measurement bandwidth and sampling time resolution down to 10’s of µsec provides the deeper insight needed for optimizing these activities. The basic time period for the mobile phone standby operation is on the order of a second but it is usually important to look at the current drain signal over an extended period of time due to variance of activities that can occur during each of the RX bursts. Having either a very deep memory, or even better, high speed data logging, provides the dynamic range in time to get 10’s of µsec of resolution over an extended period of time, so that you can determine overall average current drain while also being able to “count the coulombs” it takes for individual, minute operations, and optimize their efficiencies.

Anticipate seeing more here in future posts about mobile wireless battery-powered devices, as it relates to the “DC” end of the spectrum. In the meantime, while you are using your smart phone or tablet and battery life isn’t quite meeting your expectation (or maybe it is!), you should also marvel at how capable and compact your device is and how far it has come along in contrast to what was the state-of-the-art 5 and 10 years ago!

Friday, November 4, 2011

Wirelessly communicate with your power product

I recently had to do an evaluation of the interaction of one of our solar array simulator (SAS) power products with a customer’s device under test (DUT – in this case, a DC/DC optimizer). This required me to set up a variety of pieces of electronic test equipment in our lab area, located about 100 feet from my office cube. As part of the evaluation, I needed to change the internal firmware revision of the SAS to see if the output behavior was different with different firmware revisions. The SAS is LAN accessible and has downloadable firmware, so I planned to simply connect the SAS to LAN in our lab area and change the firmware using our firmware update utility located on my PC in my cube. However, I assembled the equipment in a location in our lab area that did not have a LAN port located nearby. So, I was ready to disconnect my laptop from its docking station in my cube and carry it over to the equipment in the lab area when I realized there was an easier way to do this: wirelessly!

A few months ago, I wrote an application note describing how to use a mobile router to wirelessly access one of our data acquisition/switch units. While the app note focused on controlling a data acquisition instrument, the process to connect wirelessly is identical for any well-behaved LAN-enabled product. So I grabbed one of the mobile routers I used to prove out the method described in the app note and connected it to the SAS. Within just a few minutes, I was able to change the firmware in the SAS from my cube located 100 feet away, without connecting the SAS to a wired LAN – I simply used my laptop’s built-in wireless.

In this case, I used the Sapido RB-1632 mobile router, shown in the photo below.

If you want to read the details about how to wirelessly connect to an instrument, refer to one of the following application notes. Once again, these were written to control the 34972A, but the same process can be applied to any well-behaved LAN-enabled instrument (LXI compliance is recommended).

“Access Your 34972A Wirelessly with a Sapido Mobile Router”:

“Access Your 34972A Wirelessly with a TRENDnet Travel Router”: