Voler Systems and V2Solutions recently partnered to develop the hardware, embedded software, mobile app and website for a home health product. It required a small battery-powered device to transmit data to a mobile phone and website. The biggest challenge in this project was the battery life: how to maximize the length of time between charges given the anticipated level of use. Voler Systems provided the hardware expertise, including sensors, power management, and wireless transmission. V2Solutions implemented the Android phone software and website, and then optimized them for long battery life. Usable Range and Battery Life One big factor is the power needed to transmit the required data volume over the desired distance. To maximize the battery life given a target form factor, we conserved the usage of power by limiting the transmission power, shortened the transmission and receive time, used low power sensors, and shutdown all unneeded electronics. This took a combination of system design, circuit design, and software to achieve the optimum solution. This project required a direct communication link between the user’s mobile phone and small devices located a reasonable distance away from the phone (from 5 m to 100 m). A modern mobile phone has many options in order to implement this communication link: Wi-Fi transceiver (2.4 GHz and 5-6 GHz) Bluetooth (standard and Low Energy) transceiver (2.4 GHz) 802.15.4 (Zigbee) transceiver (900 MHz band in the US) GPS receiver (1.228 and 1.575 GHz) FM radio receiver (88-108 MHz) Near Field Communication (NFC) transceiver (13.56 MHz) Which is the Best Standard to Use? Voler helped the team narrow the focus to the radio standards that were best suited for the small remote devices: Bluetooth Low Energy (BLE) and Wi-Fi Direct. Between those two choices, the Bluetooth solution required a smaller battery that would extend battery life to as much as 50 days. Voler brings 30+ years experience, understands the impact on size and battery life, and offers recommendations for making improved hardware choices. They help customers choose the right wireless solution for a given application and offer a great guide to Wireless Technology Standards. Optimized Software for Long Battery Life Battery life poses one of the most important considerations in everyone’s mobile usage, so much so that people often remove battery-hogging apps. Therefore, it is essential that the app is written for minimal power consumption. V2Solutions has been a leader in software development services for more than a decade. With its experienced team of experts, V2Solutions built the software to enhance usable range and battery life. Network activities cause the device to drain the battery very quickly. Hence, it is necessary to analyze how frequently the app uses the device network and the specific reasons for the network access. There are three different types of network uses: user-initiated, app-initiated, and server-initiated in the application code. Running a network traffic analyzer helps tag each network access request to their type. Analyzing the history helps see where the software should be optimized. V2Solutions was able to optimize the Android device battery life by using the following techniques: When a user performs any action, anticipate the data needed for the next action and then fetch it in bulk with a single connection. Use server APIs that allow data to be downloaded in sets. Use http caching wherever feasible (to avoid too many calls going to the server). Make use of Google Cloud Messaging for server side updates instead of polling. Instead of random calls, process batch requests by using different batch-and-scheduling APIs provided by Android. Check if the device is connected to a charger. If it is, then proceed with network calls. However, if the device is not connected to the charger and the charge is below 10%, do not initiate any calls (this would cause the battery to rapidly drain and eventually shut down the device). The Android and iOS teams at V2Solutions take a holistic approach to power optimization that begins with an in-depth understanding of the client’s business objectives and intended user experience. This understanding allows us to make the right decisions about how to balance between opposing goals within the app. Some of these decision trade-offs are: Use lazy-loading to reduce power and memory requirements, instead of immediate display of data. Use re-sizable images and opaque/pre-blended color schemes to reduce view calculation instead of direct drawing and on-the-fly opacity blending methods. Pre-loading large, static data-sets to reduce real-time Wi-Fi and cellular radio power-ups instead of a slimmer disk-space footprint. Caching images, data and calculation-results to reduce traffic and processor requirements versus an on-demand approach to reduce memory-pressure. In addition to these architecture-time decisions, it is necessary to employ development best practices such as reusing heavy objects such as formatters, pro-actively addressing both observed and potential memory warnings using Automatic Reference Counting (ARC) for optimal memory management, and using appropriate persistence technologies like Core Data and SQLite that allow us to do disk IO only when absolutely necessary. When these architecture decisions and design techniques are not enough, the team analyzes the app in a live environment (or as close as possible) to find the bottle-necks and battery-hogs. Once the pain-points are identified, the team works to counter them by tweaking the trade-offs, or by rewriting the offending processes directly in C. Hardware and Software Working Together Power usage and battery life can only be solved by a hardware and software team working together to deliver smart home health devices. Together they must take a holistic approach and an in-depth understanding of the client’s business objectives and intended user experience.