BLE-V-Monitor: How car batteries join the Internet of Things

The Internet of Things (IoT) envisions a world where virtually everything is connected and able to communicate. Today, I want to present one such IoT application, namely, the BLE-V-Monitor: a battery voltage monitor for vehicels (cars, motorbikes).

BLE-V-Monitor consists of an Arduino-based monitoring device and an Android app. The BLE-V-Monitor device is connected to the car battery to monitor the battery voltage and record voltage histories. The app queries the current voltage and voltage history via Bluetooth Low Energy (BLE) and displays them to the user. Below you can see an image of the circuit board of the BLE-V-Monitor device and two sceenshots of the app showing the current voltage, charge status, and voltage history.

BLE-V-Monitor Board

BLE-V-Monitor board.


BLE-V-Monitor app: voltage and charge status

BLE-V-Monitor app: voltage and charge status

BLE-V-Monitor app: minutely history

BLE-V-Monitor app: minutely voltage history

The main features of BLE-V-Monitor are:

  • Voltage and battery charge status monitoring
  • Recording of minutely, hourly, and daily voltage histories
  • Bluetooth Low Energy (BLE) to transmit voltage samples to smartphones, tablets, Internet gateways, etc.
  • Very low energy consumption
  • Android app for displaying current voltage and voltage histories
  • Open source hardware (CERN Open Hardware Licence v1.2) and software (Apache License 2.0)


According to a recent study of ADAC (the largest automobile club in Europe), 46 % of car breakdowns are due to electrical problems, mostly empty or broken batteries. Personally, I know several incidents, where a broken or empty battery was the reason for breakdowns of cars or motorbikes. So no question: there is a real problem to be solved.

The major problem with an empty battery is that you might not realize it until you turn the key, or for those of you with a more modern car, push the engine start button. And then it is already too late! So wouldn’t it be nice if the battery could tell you in advance, when it needs to be recharged and let you know its status (weakly charge, fully charged, discharged, etc.)?

That’s where the Internet of Things comes into play: the “thing” is your car battery, which is able to communicate its voltage and charge status using wireless communication technologies.

Let me present you some technical details of BLE-V-Monitor, to show you how to implement this specific IoT use case. More details including Android and Arduino source code and hardware design (PCB layout) can be found on Github:


The technical design of BLE-V-Monitor was driven by two key requirements:

  1. Keep it as simple as possible: Simple and commonly available hardware; through-hole PCB design to allow for simple etching and soldering.
  2. Very low energy consumption. What is the use of a battery monitor consuming substantial energy? Just to give you an idea that this is not trivial even considering the fact that a car battery stores a lot of energy (usually more than 40 Ah even for smaller cars): Consider the current of one standard LED, which is about 15 mA connected through a resistor to your 12 V car battery. After two hours, this LED and the resistor consumed 2 h * 15 mA * 12 V = 30 mAh * 12 V energy. Now, assume starting your motor with a starter motor drawing 50 A on average over a 2 s starting period. In this scenario, starting your motor once consumes 2 s * 50 A * 12 V = 28 mAh * 12 V. Thus, in less than two hours, the LED and its resistor consumed about the same energy as starting your car once. I know, this scenario is highly simplified, but it might serve to show that even a small consumer (in our case the BLE-Monitor device) is significant if it is running for a long time. Consequently, as a goal we want to bring down the average energy consumption of the monitoring device far below 1 mA.


Technically, BLE-V-Monitor consists of the BLE-V-Monitor device already shown above and a smartphone app for Android.

The BLE-V-Monitor device periodically samples the voltage of the battery, and the app uses Bluetooth Low Energy (BLE) to query the battery voltage when the smartphone is close to the car. Instead of using a smartphone, you could also install some dedicated (fixed) hardware (e.g., a Raspberry Pi with a Bluetooth USB stick in your garage), but since I walk by my car every day and the range of BLE was sufficient to receive the signal even one floor above the garage, I did not consider this option so far.

In order not to lose data while the smartphone is not within BLE range, the BLE-V-Monitor device records minutely, daily, and hourly histories in RAM, which can then be queried by the smartphone.

This approach based on BLE has several advantages: It is cheap. It is energy efficient. Clients can be implemented with many existing devices since BLE is commonly available in most consumer devices, in particular, mobile devices and cheap single-board computers like the Raspberry Pi (using a Bluetooth USB stick).

BLE-V-Monitor Device

The BLE-V-Monitor device is based on the Arduino platform. It uses an ATmega 328P microcontroller and the BLE module MOD-nRF8001 from Olimex with the Nordic Semiconductors BLE chip nRF8001. The ATmega is programmed via an in-system programmer (ISP) and interfaces with the BLE module through SPI. Overall, if you build this device yourself, the hardware might cost you less than 20$.  And since we rely on a simple and energy efficient microcontroller and BLE together with small duty cycles, the current consumption can be below 100 microampere (including everything like the 3.3 V voltage regulator to power the microcontroller and BLE module from the car battery).

To measure voltage, we use the 10 bit analog/digital converter (ADC) of the ATmega (no extra ADC component required). The voltage range that can be measured ranges from 0 to 18 V, thus, the resolution is 18 V / 1024 = 17.6 mV, which is fine-grained enough to derive the charge status of the battery (see voltage thresholds below). Note that while the car is running, the car’s alternator provides more than 12 V to charge the battery (about 15 V for my car as can be seen from the voltage history screenshot). A voltage divider with large resistor values (to save energy) is used to divide the battery voltage. Since we use a 2.5 V reference voltage, 18 V is mapped to 2.5 V by the voltage divider. The 2.5 V reference voltage is provided by the very precise micropower voltage reference diode LM285-2.5, which is only powered on demand through a GPIO pin of the ATmega during sampling to minimize energy consumption as much as possible. Since the resistors of the voltage divider have large values to save energy, a 100 nF capacitor in parallel to the second resistor of the voltage divider provides a low impedance source to the ADC (this 100 nF capacitor is much larger than the 14 pF sampling capacitor of the ATmega).

A 18 V varistor (not shown on the image; it’s an SMD on the backside of the PCB since I only had an SMD version available) protects from transient voltage spikes above 18 V. Since varistors typically age whenever they shunt excessive voltage, a fuse limits the current to protect against a short circuit of the varistor.

A micropower voltage regulator (LP295x) provides 3.3 V to the ATmega and BLE module. The 100 mA that can be provided by this regulator are more than sufficient to power the ATmega and BLE module while being active, and a very low quiescent current of only 75 microampere ensures efficient operation with small duty cycles.

BLE-V-Monitor App

The BLE-V-Monitor App is implemented for Android (version 4.3 or higher since we need the BLE features of Android). It consists of a tab view with a fragment to display the current voltage, and three more fragments to display minutely, hourly, and daily voltage histories, respectively.

The charge status of a lead–acid car battery can be quite easily derived from its voltage. We use the following voltage levels to estimate the charge status on the client side:

  • 100 % charged (fully charged): about 12.66 V
  • 75 % charged (charged): about 12.35 V
  • 50 % charged (weakly charged): about 12.10 V
  • 25 % charged (discharged): about 11.95 V
  • 0 % charged (over discharged): about 11.7 V

The screenshots above show some examples of the current voltage, charge status, and voltage histories. In the history screenshot you can also identify two periods when the car was running where the charging voltage reached about 15 V.

Final Prototype

The following photos show how the BLE-V-monitor PCB is mounted inside a case and the placement of the monitoring device right in front of the battery of my car (in this photo, the device is already connected to the battery but not yet fixed). Fortunately, older cars have plenty of space and not a lot of useless plastic hiding every part of the motor.

BLE-V-Monitor device

BLE-V-Monitor device with case


BLE-V-Monitor device in car

BLE-V-Monitor device mounted in car and connected to car battery

The pull relief (knot) might not look very elegant but it is highly effective.

Obviously, plastic is the better choice for the case since the Bluetooth module is inside. Still, I had some concerns that all the metal of the car would shield Bluetooth signals too much, but it works suprisingly well. Even one floor above the garage with the metal engine hood and a concrete ceiling between device and client I can still receive a weak signal and I can still query the battery status.

Where to go from here?

Obviously, there is some potential to further improve the functionality. Beyond just monitoring the raw voltage and mapping it to a charge status, we could analyse the voltage data to find out whether the battery is still in a healthy condition. For instance, we could look at voltage peaks and analyse the voltage histories to find out how quickly the battery discharges, and how these values change over the lifetime of the battery. To this end, you could send the data to the cloud. Although I think, you could implement such simple “small data” analytics also on the smartphone or even on the microcontroller of the monitoring device.

However, the battery or car vendor might want to collect the status of all of their batteries in the cloud for other reasons, for instance, to improve maintenance and product quality, or to offer advanced services. With the cloud, everything becomes a service, so why not offering “battery as a service”? Instead of buying the battery, you buy the service of always having enough energy to operate your car. When the performance of your battery is degrading over time, the vendor already knows and sends you a new battery well before the old one is completely broken or invites you to visit a garage where they exchange the battery for you (this service would be include in the “battery as a service” fees).

I hope you found this little journey to the IoT interesting. Have a good trip, wherever you go!