I am William Meli, a control system engineer living in the north of germany.
I have been working on a car battery monitoring system for low budget applications. The idea arose from a problem that arose in the past. I named the system BatMonMini (BMM). The BMM could also be used for sensing other system with DC voltage between 0 and 30V. Measuring down to 0V is possible due to the integrated auxiliary supply.

There were some major requirements when developping the BMM

• Voltage sensing for 12V / 24V car batteries
• Detection and classification of transients (cranking voltage, ...)
• Good noise rejection capabilties
• Battery health estimation
• Visible and hearable alerts
• Android/IOS APP (WiFI / Bluetooth)
• Detection and classification of non negligible mechanical vibration related to the battery
• Detection of unwanted battery replacement events
• Compliance with some standard automotive protection requirements (Overvoltage, overtemprature, ...)
• IoT-Integration (MQTT, .. .)
• Low cost
• FOtA capable
• Enhanced antenna capabilities (sending/receiving)
• IP-6x compliant
• ...

Hardware design
I processed and refined those requirements and iteratively generated a list of achievable requirements. I divide the whole system into the hardware (PCB, mechanical enclosure, ...) & software.

I designed and developped a four layer PCB accordingly to achievable requirements. i.e. Enforcing a good noise rejection (high frequencies) by enabling the sensing of cranking sequences at the same time, ends up in the design of some hardware filtering stages. The enforced hardware bandwidth (~ 500Hz) could be read from the bode diagramm below. The underlying transfer function has been calculated by using some electrical circuits theorems.

Good antenna requirements have been fulfilled by using a 3D antenna with a matching circuit between the RF unit of the MCU and the antenna itself. For motion detection and sensing, i used a 3DoF inertial measurement sensor with enhanced low power capabilities.

An overview of the PCB schematic could be read from the picture below.

Mechanical enclosure
I chose an integrative design for this project. Before sending the PCB gerber files to the manufacturer, i designed the whole enclosure with some CAD tools. I generated a 3D printable version. I iteratively printed the enclosure with my own 3D printer and then made some changes on the CAD models. At the end i got a version that would be used for the enclosure production (injection molding). I released the PCB fabrication after the final step of the enclosure design.

A picture from a version of the whole system (PCB, enclosure) could be seen below. Please note that the enclosure is realized by two parts.

Hardware testing
The first PCB production batch consists of 10 items. I tested all of them successfully. Hardware testing was straightforward. This is mainly due to some circuits parts i imported from some plattforms (developped before) based on last projects. The inheritance of tested/approved functionalities was focused. New circuits parts have been tested and propagated onto new plattforms or used to extend older plattforms.

Software
This is the most intensive part. The basic software includes

• Gaining car battery voltage data from operational amplifier.
• Estimation of calibration constants / Observer algorithms for automatic calibration
• Observation of time depedent calibration parameter
• Measurement/observation/estimation of stationary (mean battery voltage value, ...) and high frequency (cranking voltage, ...) sequences
• Advanced filtering algorithms (adaptive filtering, kalman filtering, ...)
• Implementation of the motion detection and classification features
• Managing (monitoring/controlling) the auxiliary power supply
• Enabling the access to the monitoring system over Bluetooth Low Energy and WiFi
• Enabling the APP connectivity
• Enabling Firmware updates Over the Air --> would enable a remote software update -->highly mandatory
• Implementing a configuration scheme
• Implementing One Time Programming (OTP) features (serial number, ...)
• Implementing Flash memory secured functionalities
• Secure boot implementation
• Firmware signing
• IoT integration (MQTT, ...)
• ...

System test
I printed some 3D enclosures and installed the PCBs inside. I then tested those systems against a battery guard i bought several months ago. The antenna signal strength of the battery guard was sometimes poor. That's why I wanted to compare the battery guard with the BMM system in addition to meeting the above antenna requirements. For the comparison i also used the APP i received when buying the battery guard. For that i implemented some BLE-Services and -characteristics and used the APP in order to compare the battery guard voltage value with those from the BMMs. Please note that i am developping an own APP for handling the whole data (car battery voltage, cranking voltage, motion sensor signals, ...) arising from the BMM.

Please look at the picture below with a battery guard and two BatMonMinis (3D-printed enclosure) included. There are ongoing works regarding a molded version of the BMMs. IP6x enabling steps are also being performed. This will result in an adaptation of the housing.

System test - Antenna
Sending data over BLE and WiFi with good antenna capability was an very important requirement. Please look at the picture for the receiving capabilities of the battery guard against the BMMs. I placed my BLE4.0 capable cell phone at a distance of about 1.5m from the three Devices under Test (DuT, please look at the last picture). The antenna receiving strength has been measured with the nRF Connect app. Thanks to the Nordic Semiconductor company for this great app.

The antenna measurement results can be seen on the picture below. The devices with the bluetooth mac addresses starting with 50:02:xx:xx:xx:xx belong to the BMM systems.

Some points were much clear when looking at the picture above. The RSSi difference of at least 6dBm reveals some insights about why i sometimes got a poor antenna behavior of the battery guard i bought.

The next point is about the voltage measurement on a real 12V car battery. For that i used a multimeter as reference measurement system. The multimeter has been validated before against another one, such that we could assume that the multimeter is displaying the real car battery voltage.

The picture below includes the values from battery guard, BMM1, BMM2 and multimeter. Please refer to the System test part about the APP used for this test. As already mentionned, a more suitable BLE APP (with motion data, ..., included) is being developped at the moment.

System test - real car - battery voltage measurement

The BMM results show an approximation of the target car battery voltage value (12.71V) with +/-0.00V tolerance. Further statistically representative analysis showed a standard deviation of 0.01V.

Further work has been completed or is in progress.
For the sake of clarity, I omitted further details. More work would be mentioned in another post.

Best regards

William Meli

@NeverDie Thx for appreciating the work done. There will also be an open source part in the future. When and how extensive the open source part will be, remains to be seen. The release of certain information (block diagram, ..., in this post) is related to those open source parts.

There are some OBD solutions, however most of them (in my experience) give back low frequency data put by the car manufacturer on the OBD-bus (CAN, ...). Therefore transients evolving directly from the battery could only be recorded if the manufacturer sends those data accordingly on the bus. Due to the small bandwidth(also because of other car data that have to be sent, ...), such battery data are sent more often once per second or less. Fast battery events (i.e. cranking events, ...) are therefore imperceptible. Unless the manufacturer processes the fast events and then sends them (once per second or less), which is very unlikely if the manufacturer does not market this feature itself. Third parties devices for high frequency sensing costs several hundreds dollars.

In my experience, important battery states (especially the fast ones) are recorded by measuring and processing corresponding data directly on the battery.

I agree with you about the limits related to the communication over Bluetooth. But i think Bluetooth 5.0 will improve a lot. However, WiFi will always remain an important option due to the high data throughput. The combination of both (BLE & WiFi), especially with regard to energy consumption, will gain in importance.

@skywatch Thx for the likes and your suggestion! Of course monitoring/managing solar batteries is another application, especially since 12V / 24V batteries are often used as solar power storage. However, the operating time is more often longer in the solar sector than in cars (battery mostly as a starter). Therefore, the requirements to consider other internal states (current flowing, ...) would increase.

I am William Meli, a control system engineer living in the north of germany.
I have been working on a car battery monitoring system for low budget applications. The idea arose from a problem that arose in the past. I named the system BatMonMini (BMM). The BMM could also be used for sensing other system with DC voltage between 0 and 30V. Measuring down to 0V is possible due to the integrated auxiliary supply.

There were some major requirements when developping the BMM

• Voltage sensing for 12V / 24V car batteries
• Detection and classification of transients (cranking voltage, ...)
• Good noise rejection capabilties
• Battery health estimation
• Visible and hearable alerts
• Android/IOS APP (WiFI / Bluetooth)
• Detection and classification of non negligible mechanical vibration related to the battery
• Detection of unwanted battery replacement events
• Compliance with some standard automotive protection requirements (Overvoltage, overtemprature, ...)
• IoT-Integration (MQTT, .. .)
• Low cost
• FOtA capable
• Enhanced antenna capabilities (sending/receiving)
• IP-6x compliant
• ...

Hardware design
I processed and refined those requirements and iteratively generated a list of achievable requirements. I divide the whole system into the hardware (PCB, mechanical enclosure, ...) & software.

I designed and developped a four layer PCB accordingly to achievable requirements. i.e. Enforcing a good noise rejection (high frequencies) by enabling the sensing of cranking sequences at the same time, ends up in the design of some hardware filtering stages. The enforced hardware bandwidth (~ 500Hz) could be read from the bode diagramm below. The underlying transfer function has been calculated by using some electrical circuits theorems.

Good antenna requirements have been fulfilled by using a 3D antenna with a matching circuit between the RF unit of the MCU and the antenna itself. For motion detection and sensing, i used a 3DoF inertial measurement sensor with enhanced low power capabilities.

An overview of the PCB schematic could be read from the picture below.

Mechanical enclosure
I chose an integrative design for this project. Before sending the PCB gerber files to the manufacturer, i designed the whole enclosure with some CAD tools. I generated a 3D printable version. I iteratively printed the enclosure with my own 3D printer and then made some changes on the CAD models. At the end i got a version that would be used for the enclosure production (injection molding). I released the PCB fabrication after the final step of the enclosure design.

A picture from a version of the whole system (PCB, enclosure) could be seen below. Please note that the enclosure is realized by two parts.

Hardware testing
The first PCB production batch consists of 10 items. I tested all of them successfully. Hardware testing was straightforward. This is mainly due to some circuits parts i imported from some plattforms (developped before) based on last projects. The inheritance of tested/approved functionalities was focused. New circuits parts have been tested and propagated onto new plattforms or used to extend older plattforms.

Software
This is the most intensive part. The basic software includes

• Gaining car battery voltage data from operational amplifier.
• Estimation of calibration constants / Observer algorithms for automatic calibration
• Observation of time depedent calibration parameter
• Measurement/observation/estimation of stationary (mean battery voltage value, ...) and high frequency (cranking voltage, ...) sequences
• Advanced filtering algorithms (adaptive filtering, kalman filtering, ...)
• Implementation of the motion detection and classification features
• Managing (monitoring/controlling) the auxiliary power supply
• Enabling the access to the monitoring system over Bluetooth Low Energy and WiFi
• Enabling the APP connectivity
• Enabling Firmware updates Over the Air --> would enable a remote software update -->highly mandatory
• Implementing a configuration scheme
• Implementing One Time Programming (OTP) features (serial number, ...)
• Implementing Flash memory secured functionalities
• Secure boot implementation
• Firmware signing
• IoT integration (MQTT, ...)
• ...

System test
I printed some 3D enclosures and installed the PCBs inside. I then tested those systems against a battery guard i bought several months ago. The antenna signal strength of the battery guard was sometimes poor. That's why I wanted to compare the battery guard with the BMM system in addition to meeting the above antenna requirements. For the comparison i also used the APP i received when buying the battery guard. For that i implemented some BLE-Services and -characteristics and used the APP in order to compare the battery guard voltage value with those from the BMMs. Please note that i am developping an own APP for handling the whole data (car battery voltage, cranking voltage, motion sensor signals, ...) arising from the BMM.

Please look at the picture below with a battery guard and two BatMonMinis (3D-printed enclosure) included. There are ongoing works regarding a molded version of the BMMs. IP6x enabling steps are also being performed. This will result in an adaptation of the housing.

System test - Antenna
Sending data over BLE and WiFi with good antenna capability was an very important requirement. Please look at the picture for the receiving capabilities of the battery guard against the BMMs. I placed my BLE4.0 capable cell phone at a distance of about 1.5m from the three Devices under Test (DuT, please look at the last picture). The antenna receiving strength has been measured with the nRF Connect app. Thanks to the Nordic Semiconductor company for this great app.

The antenna measurement results can be seen on the picture below. The devices with the bluetooth mac addresses starting with 50:02:xx:xx:xx:xx belong to the BMM systems.

Some points were much clear when looking at the picture above. The RSSi difference of at least 6dBm reveals some insights about why i sometimes got a poor antenna behavior of the battery guard i bought.

The next point is about the voltage measurement on a real 12V car battery. For that i used a multimeter as reference measurement system. The multimeter has been validated before against another one, such that we could assume that the multimeter is displaying the real car battery voltage.

The picture below includes the values from battery guard, BMM1, BMM2 and multimeter. Please refer to the System test part about the APP used for this test. As already mentionned, a more suitable BLE APP (with motion data, ..., included) is being developped at the moment.

System test - real car - battery voltage measurement

The BMM results show an approximation of the target car battery voltage value (12.71V) with +/-0.00V tolerance. Further statistically representative analysis showed a standard deviation of 0.01V.

Further work has been completed or is in progress.
For the sake of clarity, I omitted further details. More work would be mentioned in another post.

Best regards

William Meli