I'm posting a guest blog from Matt Benes of The specified item was not found. on an important if not vital topic; power consumption of wireless systems. During Kickstarter Week we saw that the vast majority of new designs used wireless connectivity and therefore power consumption and battery life were key factors for users. Enjoy.
With the continuing growth of the Internet of Things, being connected is more important than ever. Smart, connected electronics are now everywhere: from large scale smart grids to Wi-Fi enabled toasters. With this comes a push to become “unplugged” and eliminate the need for power cords. For many devices, a power cord is simply not practical for a number of reasons. This means designers must come up with alternative methods of powering their devices, adding new challenges and complexity. Without the seemingly unlimited source of power from being plugged in, designers must pay close attention to how much power their devices are consuming at any given time to maximize efficiency, whether using batteries, solar cells, or any other limited power source.
The most common method used to power wireless devices, of course, is with batteries. Batteries are a proven and reliable source of power that can be recharged and are available in a wide array of sizes and capabilities. Batteries can only supply a finite amount of power before they need recharging so designers must weigh a host of tradeoffs such as battery size, system performance and how long the battery needs to last between charges. ARM has developed the Cortex-M series family of processors that has become a favorite among designers working on embedded IoT applications. It is not surprising that it has become a favorite because ARM has designed the Cortex-M specifically to be a low-cost, low-power, and high performance processor and those features directly align with the goals of IoT designers.
The Cortex-M series has some neat features built into the design that help reduce its power consumption while operating. It uses a power efficient 32-bit processor that allows the unit to consume less power by performing tasks faster at a lower clock frequency than 8-bit and 16-bit designs. It also supports multiple sleep modes that allow designers to put the processor in a lower power state when high performance is not necessary allowing for longer battery life in devices.
The simplest way to determine battery life is to use this basic formula: T=Q/I where (T) is the amount of time the battery will last (in hours), (Q) is the capacity of the battery (in amp hours), and (I) is the current drawn from the battery. Using this formula, for example, a 2Ah battery that is powering a device that is drawing 0.25A will last for 8 hours.
This is a great method for estimating battery life on devices that are drawing a constant current, but it gets more complicated when the device has multiple states of operation that each draw different amounts of power over time. These different states of operation can include putting the device in a power saving mode, enabling different connections such as Wi-Fi or Bluetooth, motors running, lights turning on, or any other task that the device may be designed to do. For those types of measurements you will need an oscilloscope with current probes capable of measuring the spikes in power consumption as well as a long enough record length to characterize the battery drain.
One great example of how to use modern test equipment to help design cutting edge electronic designs is Istituto Italiano Di Tecnologia’s iCub robot. The iCub is the humanoid robot developed at IIT as part of the EU project RobotCub and subsequently adopted by more than 20 laboratories worldwide. It has 53 motors that move the head, arms and hands, waist, and legs. It can see and hear, it has the sense of proprioception (body configuration) and movement (using accelerometers and gyroscopes).
The method challenge that IIT faced was troubleshooting a new battery pack system that allowed iCub to operate without along extension cord and validating the CAN and I2C buses using the battery pack’s design. In order to make this possible, IIT turned to a Tektronix MSO4104B oscilloscope with a TDP1000 differential probe, TCP0030 current probe and four TPP1000 probes along with decoder modules to measure analog signals, power characteristics and bus communications.
The MSO4102B oscilloscope features 1 GHz bandwidth with a sample rate of 5 GS/s. It supports up to 4 analog channels and 16 digital channels. Since the digital channels are fully integrated into the oscilloscope, users can trigger across all input channels, automatically time correlating all analog, digital, and serial signals.
With the addition of the appropriate power probes – from the wide cross-selection offered by the Tektronix – the MSO4000 series oscilloscopes are well-suited to power test applications such as the iCub battery backpack. For instance, the TCP0030 used by IIT is a high-performance, easy-to-use AC/DC current probe that provides greater than 120 MHz bandwidth with selectable 5 A and 30 A measurement ranges. It also provides low-current measurement capability and accuracy to levels as low as 1 mA.
The first application for this set up was to analyze the start-up transient as shown below to ensure that sensitive electronics were not damaged during the start-up of the robot.
Start-up transients were measured and reigned in with the help of Tektronix test instrumentation.
The oscilloscope also proved useful in evaluating battery life under a variety of conditions. Interestingly, it proved difficult to exercise the robot to its fullest where all 53 motors were running simultaneously, and in fact the team was not able to produce a truly worst case scenario. Like humans, rarely are all the possible combinations that go into creating movement used at the same time. After getting the robot as close to full movement as possible, the MSO4104B’s long 20M point record length was used to characterize battery discharge as shown below. Under near worst-case scenarios, battery life came out to about 1.5 hours but would typically be much longer under more normal operation.
The MSO4104B deep memory was used to characterize battery discharge.
With three boards and two bus technologies, another important challenge confronting the team was to validate and debug data communications – a tedious task if performed manually. That’s where the DPO 4AUTO and DPO4EMBD data decoder modules made it easy to read and validate the data communications between a master board, a hot swap manager board and third board used for monitoring. The hot swap board communicates with the master through a 1 Mb/s CAN bus while the monitor connects through I2C to the master. The master includes a Bluetooth interface so it can communicate battery status to a mobile device or the robot head. An example of the CAN and I2C communication signals and the respective bytes decoded is shown below.
CAN and I2C decoding helped to speed up debug
For additional information about this iCub robot project visit for the Tektronix website a free case study pdf: http://www.tek.com/document/case-study/icub-robot
Yes, indeed the battery pack has two STM32 F1. Moreover for the motor control cards (53 motors controlled by twenty cards) we are using the powerful STM32 F4.
iCUB an amazing achievement in the humanoid robotic world ... powered by numbers of STM32 F1 and F4 and STMicroelectronics sensors, recognition and motor coordination related
I agree debugging comms protocols manually is tedious and very time consuming. I still remember the first time I had an oscilloscope displaying the hex value instead of having to slide markers bit by bit... It was a The specified item was not found. one, and saved me a lot of time.