Smartphone Application Development Guide for BatteryMole Bluetooth Battery Monitoring System for Automobiles (BMBT) 4 Peaks Technology LLC. Revision 1.1 05/01/2016 Page 1 of 26
Revision History Revision Date Author(s) Description 1.0 12/11/15 L. Goff First Draft 1.1 05/01/16 L Goff Added Advertise Enable error code Page 2 of 26
Table of Contents Revision History...2 1) Overview...4 2) System Architecture...5 3) Bluetooth Interface...5 4) Self-Test...7 5) Device Address...7 6) Advertising Data (AD) Structures...9 7) Packets...19 8) POR Initialization and Sleep Mode...24 9) BMBT Blink Codes...25 Appendix A: Design Notes...26 Page 3 of 26
1) Overview BatteryMole Bluetooth (BMBT) is an automobile after-market system used to monitor the operational state of the starter battery and to alert motorists when battery service is required. Data made available to the driver includes the charge state of the battery, the battery temperature, the engine start time, the starting voltage surge and the real-time battery/alternator voltage. System alerts made available to the driver include battery low charge state, alternator undercharge and alternator overcharge malfunctions. The system also makes use of U.S. Patent 8,386,199 in order to alert the driver that the battery s end-of-life is near and service is required. Although this system will work as a real-time monitor, it should not be used as such. Using a smartphone for any reason is against the law in many states. It is a dangerous activity in all states. A warning message is unconditionally displayed when the smartphone application is started warning against such activity. Instead, the driver should run the smartphone application after safely arriving at their destination. The system is designed so that any alarm that occurs while driving will not be lost while driving. Running this application once a week is sufficient. Page 4 of 26
2) System Architecture It is designed to attach directly to the car s battery. It transmits battery data using the latest Bluetooth Low Energy (BLE) technology. The system features the EM9301 Bluetooth Radio/HCI controller embedded in a CMM-9301-V3.1SX-1 shielded part, with pin connectors 18.5 x 14 mm 2.3 ~ 3.6V. 3) Bluetooth Interface BatteryMole Bluetooth (BMBT) is a Single-Mode Bluetooth Low Energy (BLE) device which supports only the LE profile. It communicates with Android devices running Android Version 4.3 (or later) and ios 5 (or later) devices. It does not support BR/EDR/LE and therefore cannot communicate with the older Classic Bluetooth devices. BMBT operates in an advertise-only "connectionless" mode whereby all data is transmitted in advertising packets. The following data will be made available. Smartphone Msg Data Type 12.25v BATTERY <or> 13.89v BAT/ALT Real-time Voltage. This can be either the battery's voltage or, if the engine is running, the charging system's voltage. 110 0 F (43 0 C) TEMPERATURE 35% CHARGE 9.61v START 1.78s START TIME Battery Temperature (Fahrenheit /Centigrade) This is the temperature as measured Charge state of the battery (SoC). The charge state is only calculated after the engine has been off for an extended period of time. Initial voltage surge when the engine is started. Engine start time. The following alarms (i.e. notifications) are supported. Smartphone Alarm Messages Alternator over-charging (15.10v) Page 5 of 26
Smartphone Alarm Messages Alternator under-charging (13.19v) Weak/erratic starting voltage (7.32v) Excessive/erratic start time (4.12s) Low battery voltage (11.89v) Low State of Charge (35%) This is based on the charge state of the battery as calculated when the engine is off for extended periods. The temperature compensated voltage of the battery is used to determine the charge state of the battery based upon published Temperature Compensated Battery State-of-Charge (SoC) tables. The device name, as displayed above, is created by appending the last byte of the Device Address to the BatteryMole string. The Self Test info, as displayed above, all comes from the Self Test packet as specified in section 7) Packets. Page 6 of 26
4) Self-Test The built-in Self Test occurs whenever there is a Power on Reset (POR), a Watchdog Timer event (WDT), the execution of a Reset Instruction (RI) or a debugger related Master Clear (MCLR/). A POR restores the BMBT to its factory defaults. The completion status of the Self Test is periodically broadcast. The type of event that caused the reset is included in the Self-Test AD Results Structure (as specified in section 6). 5) Device Address A Public Address will not be used (IEEE issues these things). The advertising parameters (7.8.5 LE Set Advertising Parameters Command) will specify that a Random Address will instead be used. Since the EM9301 supports an embedded security engine it supports 7.8.23 LE Rand Command (Core p.1090). This commands causes the EM9301 to generate and return a 48-bit random number. This number will only be requested by the PIC when no random address has been stored in the PIC s EEPROM. EM9301 includes a Host/Controller Interface as defined in the Bluetooth Core Specifications [1], volume 2, part E. Table 7.1 summarizes the command formats and Table 7.2 the event formats. This section is added only for completeness as there are no differences with respect to the definitions given by the Bluetooth SIG (EM 9301 p. 23) The 7.8.4 LE Set Random Address Command p.1057 will be used to load this address into the EM9301 from the PIC s EEPROM whenever power is cycled. There are two sub-types of random addresses: Static address Private address. Bluetooth LE supports a feature that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. The privacy feature is not, however, used in the GAP discovery mode. It is used during connection mode and connection procedures (p. 197 Core). The private address therefore does not apply to the BMBT since it never connects to a client. Page 7 of 26
A static address is a 48-bit randomly generated address and shall meet the following requirements: The two most significant bits of the static address shall be equal to 1 All bits of the random part of the static address shall not be equal to 1 All bits of the random part of the static address shall not be equal to 0 The BMBT random address, as stored in the EEPROM, can never be reset unless the PIC is reprogrammed. SPECIAL NOTE: The most significant byte of the random address is always set to 0xC4. This convention is used in order to make it easier to distinguish between a BMBT broadcast and other types of BLE devices. Page 8 of 26
6) Advertising Data (AD) Structures The only supported is the Manufacturer Specific Data type ). The two data octets following this data type contains a company identifier documented by the Bluetooth Assigned Numbers Company Identifiers document. The interpretation of any other octets within the data shall be defined by the manufacturer specified by the company identifier (Core p.1692). (Note, the used by BMBT is ). 1) Voltage/Start Voltage AD Structure: The is fixed at 9 (highest order digit of the voltage reading is 0 padded when necessary). The character immediately following the is the voltage delimiter ( B for battery/alternator, S for start voltage). 0x09 B Battery/Alternator Voltage 1 (12.45 Volts) 2. 4 5 2) Start Time AD Structure: The is fixed at 9 (highest order digit of the start time is 0 padded when necessary). The character immediately following the is the start time delimiter T. Page 9 of 26
0x09 T Start Time 0 (2.89 seconds) 2. 8 9 3) State of Charge (SoC) AD Structure: The is 6 (highest order digit of the SoC data field is 0 padded when necessary). The character immediately following the is the SoC delimiter C. 0x06 C State of Charge (SoC) 4 (45%) 5 Page 10 of 26
4) Temperature AD Structure: The is 7. The character immediately following the is the temperature delimiter + or -. Highest order two digits of the three digit temperature reading are 0 padded when necessary. 0x07 + Fahrenheit Temperature (either + or - ) 0 +34 degrees F 3 4 5) BMBT Firmware Version Number AD Structure: The is fixed at 7. The character immediately following the Company ID is the firmware version number delimiter. 0x07 F Firmware Version Number 1 # 134 3 4 Page 11 of 26
6) EEPROM Index AD Structure: The is fixed at 6. The character immediately following the Company ID is the EEPROM number index delimiter. 0x07 E EEPROM Index 0 Index is 0 to 255 ASCII decimal 6 4 7) Self-Test Results AD Structure: The is fixed at 6. The character immediately following the Company ID is the Self-Test delimiter. 0x06 P Reset Type P = POR I = RESET INSTRUCTION Page 12 of 26
W = Watchdog Timeout M = Master Clear (reset button) 0x00 Check ID 0x00 = no errors 0x41 = Program Rom Checksum error 0x00 Trace ID 0x00 = no errors 0x42 = EM9301 dead (no event response) 0x43 = Set Random Address failed 0x44 = Set Advertising Parameters failed 0x45 = Set Random Address failed 0x91 = Voltage, Temp, SoC packet failed 0x92 = Self-Test packet failed 0x93 = Start-Voltage, Start-Time packet failed 0x94 = Start-Voltage Alarm packet failed 0x95 = Start-Time Alarm packet failed 0x96 = Low-Voltage Alarm packet failed 0x97 = SoC Alarm packet failed 0x98 = Alternator Over-Charge packet failed 0x99 = Alternator Under-Charge packet failed 0x9A = Check-Battery ICON packet failed 0x9B = Check-Alternator ICON packet failed 0x9C = Alarm Count packet failed E1 = Advertise Enable failed 8) Start Voltage Alarm AD Structure: The is 11 (highest order digit of the voltage field is 0 padded when necessary). The character immediately following the is the Alarm Flag A. The next character is the start voltage alarm cyclic counter. It is updated for each new instance of this alarm (it rolls over from 9 to 0 ). The next character is the start voltage delimiter S. 0x0B Page 13 of 26
A Alarm Flag 2 Alarm cyclic counter ( 0-9 ) S Start Voltage 0 (8.27 Volts) 8. 2 7 9) Start Time Alarm AD Structure: The is always 11 (the highest order digit of this field is 0 padded when necessary). The character immediately following the is the Alarm Flag A. The next character is the start time alarm cyclic counter. It is updated for each new instance of this alarm (it rolls over from 9 to 0 ). The next character is the start time delimiter T. 0x0B A Alarm Flag 9 Alarm cyclic counter ( 0-9 ) T Start Time 0 (8.89 seconds) 8. Page 14 of 26
8 9 10) State of Charge (SoC) Alarm AD Structure: The is 8 (the highest order digit of the SoC data field is 0 padded when necessary. The character immediately following the is the Alarm Flag A. The next character is the SoC alarm cyclic counter. It is updated for each new instance of this alarm (it rolls over from 9 to 0 ). The next character is the SoC delimiter C. 0x08 A Alarm Flag 8 Alarm cyclic counter ( 0-9 ) C State of Charge (SoC) 3 (35%) 5 11) Undercharge Alarm AD Structure: The is fixed at 11 for this structure. The character immediately following the is the Alarm Flag A. The next character is the undercharge alarm cyclic counter. It is updated for each new instance of this alarm (it rolls over from 9 to 0 ). The next character is the Undercharge delimiter U. 0x0B Page 15 of 26
A Alarm Flag 1 Alarm cyclic counter ( 0-9 ) U Alternator Undercharge Voltage 1 (13.19 Volts) 3. 1 9 12) Overcharge Alarm AD Structure: The is fixed at 11 for this structure. The character immediately following the is the Alarm Flag A. The next character is the overcharge alarm cyclic counter. It is updated for each new instance of this alarm (it rolls over from 9 to 0 ). The next character is the Overcharge delimiter O. 0x0B A Alarm Flag 0 Alarm cyclic counter ( 0-9 ) O Alternator Overcharge Voltage 1 (15.56 Volts) Page 16 of 26
5. 5 6 13) Low Battery Voltage Alarm AD Structure: The is 11 (the highest order digit of the voltage field are 0 padded when necessary). The character immediately following the is the Alarm Flag A. The next character is the low voltage alarm cyclic counter. It is updated for each new instance of this alarm (it rolls over from 9 to 0 ). The next character is the battery voltage delimiter B. 0x0B A Alarm Flag 4 Alarm cyclic counter ( 0-9 ) B Battery Voltage 0 (9,71 Volts) 9. 7 1 14) PIC Revision ID AD Structure: The is fixed at 6. The character immediately following the Company ID is the Rev ID number. Page 17 of 26
0x06 Q PIC Revision Number 2 # 28 (latest Rev currently available) 8 15) Alarm Count AD Structure: The is fixed at 10. The character immediately following the Company ID is the Alarm Counters delimiter. These counts are reset to zero when power is cycled. If a count should overflow it will overflow to 1. 0x0A X Alarm Counters ID 0,,,255 Start Voltage Alarm Count (binary) 0,,,255 Start Time Alarm Count (binary) 0,,,255 SoC Alarm Count (binary) 0,,,255 Overcharge Alarm Count (binary) 0,,,255 Undercharge Alarm Count (binary) 0,,,255 Low Battery Voltage Alarm Count (binary) Page 18 of 26
7) Packets There are 10 packets constructed from the 15 manufacturer specific AD structures defined in the previous section. They are transmitted using a time-slot scheme (see next section). The following shows how each packet appears on the HCI interface (this differs from how the packet appears on the airwaves). 1) Voltage/Temperature/SoC packet: This packet is always active and is sent round robin with the other active messages. If data is not available for any of the AD structures their data field is filled with dashes. This should never occur for a properly working BMBT. (Note, an SoC value always gets calculated when the BMBT is first installed unless the engine is running.) None of the data in this packet is ever reset, it is only updated with newer data. 0x01 Packet ID (HCI Command Packet = 0x01) 0x2008 Command (OGF = 0x08, OCF = 0x08) = 0x2008 (Note: OGF is the high order 6 bits, OCF remaining 10 bits) 0x1A The number of significant octets in the Advertising_Data. (p. 1062 Core) 0x19 Total number of AD bytes. (----) Voltage AD Structure (10 bytes) (----) Temperature AD Structure (8 bytes) (----) SoC AD Structure (7 bytes) 2) Self-Test Results packet: This packet is always active but it is not sent in-turn with the other active messages. It is throttled by a scheme whereby it is transmitted approximately once every 10 seconds. This information does not get deleted. It only gets updated when a new Self-Test is executed (i.e. POR, WDT or MCLR) 0x01 Packet ID (HCI Command Packet = 0x01) 0x2008 Command (OGF = 0x08, OCF = 0x08) = 0x2008 (Note: OGF is the high order 6 bits, OCF remaining 10 bits) 0x1F The number of significant octets in the Advertising_Data. (p. 1062 Core) 0x1E Total number of AD bytes. Page 19 of 26
(----) Self-Test Results AD Structure (7 bytes) (----) EEPROM Index AD Structure (8 bytes) (----) BMBT Firmware Version Number AD Structure (8) (----) PIC Rev ID AD Structure (7) 3) Start Voltage/Start Time packet: This packet is typically active and is sent in-turn with the other active messages. If data is not available this can only occur after a BMBT is power cycled and before the engine is started for the first time after the reset. Except for a power cycle, none of the data in this packet is ever reset, it is only updated with newer data. 0x01 Packet ID (HCI Command Packet = 0x01) 0x2008 Command (OGF = 0x08, OCF = 0x08) = 0x2008 (Note: OGF is the high order 6 bits, OCF remaining 10 bits) 0x15 The number of significant octets in the Advertising_Data. (p. 1062 Core) 0x14 Total number of AD bytes. (----) Start Voltage AD Structure (10 bytes) (----) Start Time AD Structure (10 bytes) 4) Start Voltage Alarm packet: This packet is sent approximately once every 5 seconds along with the other active messages. As with any alarm, it will only be captured and displayed if the BMBT smartphone application is running. In those instances where an alarm is no longer active and is no longer being broadcast, the Alarm Count packet is used to make the Application aware that it has missed one or more alarms. Whenever there is a mismatch between the broadcast count stored in the Alarm Count packet verses the internal count maintained by the Application, an Alert Dialog window will popup that specifies the alarm type and what actions should be taken to fix the underlying cause of the alarm. The Alert Dialog requires operator intervention before it will disappear. 0x01 Packet ID (HCI Command Packet = 0x01) 0x2008 Command (OGF = 0x08, OCF = 0x08) = 0x2008 (Note: OGF is the high order 6 bits, OCF remaining 10 bits) 0x0D The number of significant octets in the Advertising_Data. (p. 1062 Core) 0x0C Total number of AD bytes. (----) Start Voltage Alarm AD Structure (12 bytes) Page 20 of 26
5) Start Time Alarm packet: This packet, when active, is sent in-turn approximately once every 5 seconds with the other active messages. As with any alarm, it will only be captured and displayed if the BMBT smartphone application is running. In those instances where an alarm is no longer active and is no longer being broadcast, the Alarm Count packet is used to make the Application aware that it has missed one or more alarms. Whenever there is a mismatch between the broadcast count stored in the Alarm Count packet verses the internal count maintained by the Application, an Alert Dialog window will popup that specifies the alarm type and what actions should be taken to fix the underlying cause of the alarm. The Alert Dialog requires operator intervention before it will disappear. 0x01 Packet ID (HCI Command Packet = 0x01) 0x2008 Command (OGF = 0x08, OCF = 0x08) = 0x2008 (Note: OGF is the high order 6 bits, OCF remaining 10 bits) 0x0D The number of significant octets in the Advertising_Data. (p. 1062 Core) 0x0C Total number of AD bytes. (----) Start Time Alarm AD Structure (12 bytes) 6) Low Voltage Alarm packet: This packet, when active, is sent in-turn approximately once every 5 seconds with the other active messages. As with any alarm, it will only be captured and displayed if the BMBT smartphone application is running. In those instances where an alarm is no longer active and is no longer being broadcast, the Alarm Count packet is used to make the Application aware that it has missed one or more alarms. Whenever there is a mismatch between the broadcast count stored in the Alarm Count packet verses the internal count maintained by the Application, an Alert Dialog window will popup that specifies the alarm type and what actions should be taken to fix the underlying cause of the alarm. The Alert Dialog requires operator intervention before it will disappear. 0x01 Packet ID (HCI Command Packet = 0x01) 0x2008 Command (OGF = 0x08, OCF = 0x08) = 0x2008 (Note: OGF is the high order 6 bits, OCF remaining 10 bits) 0x0D The number of significant octets in the Advertising_Data. (p. 1062 Core) 0x0C Total number of AD bytes. (----) Low Voltage Alarm AD Structure (12 bytes) Page 21 of 26
7) SoC Alarm packet: This packet, when active, is sent in-turn approximately once every 10 seconds with the other active messages. As with any alarm, it will only be captured and displayed if the BMBT smartphone application is running. In those instances where an alarm is no longer active and is no longer being broadcast, the Alarm Count packet is used to make the Application aware that it has missed one or more alarms. Whenever there is a mismatch between the broadcast count stored in the Alarm Count packet verses the internal count maintained by the Application, an Alert Dialog window will popup that specifies the alarm type and what actions should be taken to fix the underlying cause of the alarm. The Alert Dialog requires operator intervention before it will disappear. 0x01 Packet ID (HCI Command Packet = 0x01) 0x2008 Command (OGF = 0x08, OCF = 0x08) = 0x2008 (Note: OGF is the high order 6 bits, OCF remaining 10 bits) 0x0A The number of significant octets in the Advertising_Data. (p. 1062 Core) 0x09 Total number of AD bytes. (----) SoC AD Structure (9 bytes) 8) Overcharge Alarm packet: This packet, when active, is sent in-turn approximately once every 10 seconds with the other active messages. It takes approximately 5 minutes of normal output from the alternator before this message will deactivate. As with any alarm, it will only be captured and displayed if the BMBT smartphone application is running. In those instances where an alarm is no longer active and is no longer being broadcast, the Alarm Count packet is used to make the Application aware that it has missed one or more alarms. Whenever there is a mismatch between the broadcast count stored in the Alarm Count packet verses the internal count maintained by the Application, an Alert Dialog window will popup that specifies the alarm type and what actions should be taken to fix the underlying cause of the alarm. The Alert Dialog requires operator intervention before it will disappear. 0x01 Packet ID (HCI Command Packet = 0x01) 0x2008 Command (OGF = 0x08, OCF = 0x08) = 0x2008 (Note: OGF is the high order 6 bits, OCF remaining 10 bits) 0x0D The number of significant octets in the Advertising_Data. (p. 1062 Core) 0x0C Total number of AD bytes. (----) Overcharge Alarm AD Structure (12 bytes) Page 22 of 26
9) Undercharge Alarm packet: This packet, when active, is sent in-turn with the other active messages. It takes approximately 15 minutes of a consistent and excessively low alternator voltage before this message will activate. It takes approximately 5 minutes of normal output from the alternator before this message will deactivate. As with any alarm, it will only be captured and displayed if the BMBT smartphone application is running. In those instances where an alarm is no longer active and is no longer being broadcast, the Alarm Count packet is used to make the Application aware that it has missed one or more alarms. Whenever there is a mismatch between the broadcast count stored in the Alarm Count packet verses the internal count maintained by the Application, an Alert Dialog window will popup that specifies the alarm type and what actions should be taken to fix the underlying cause of the alarm. The Alert Dialog requires operator intervention before it will disappear. 0x01 Packet ID (HCI Command Packet = 0x01) 0x2008 Command (OGF = 0x08, OCF = 0x08) = 0x2008 (Note: OGF is the high order 6 bits, OCF remaining 10 bits) 0x0D The number of significant octets in the Advertising_Data. (p. 1062 Core) 0x0C Total number of AD bytes. (----) Undercharge Alarm AD Structure (12 bytes) 10) Alarm Count packet: This packet is always active and is sent in-turn with the other active messages. Except for a power cycle, none of the data in this packet is ever reset, it is only updated with newer data and the counters roll over to 1, not 0. When the smartphone detects that a new alarm has appeared it will popup an Alert Message window that describes both the alarm type and what should be done to address the problem (e.g. charge the battery and perform a static load test). 0x01 Packet ID (HCI Command Packet = 0x01) 0x2008 Command (OGF = 0x08, OCF = 0x08) = 0x2008 (Note: OGF is the high order 6 bits, OCF remaining 10 bits) 0x0C The number of significant octets in the Advertising_Data. (p. 1062 Core) 0x0B Total number of AD bytes. (----) Alarm Count AD Structure (11 bytes) Page 23 of 26
8) POR Initialization and Sleep Mode Advertising continues until the engine has been off for 30 minutes. At that time the EM9301 will be put into Deep Sleep Mode via the EM_SET_POWER_MODE vendor HCI command. The PIC will then enter Sleep Mode. Both processors will remain in their respective low power modes until the engine is re-started. The PIC will then issue a EM_SET_POWER_MODE command which returns the EM9301 back to Idle Mode. After the EM9301 returns the EM_POWER_MODE_IDLE event, the PIC will once again configure the EM9301 to start advertising battery data. Page 24 of 26
9) BMBT Blink Codes When the unit is working properly the LED will blink at the steady rate of approximately 2 blinks per second. Erratic blinking specifies an error condition. When the BMBT detects an internal problem it will repeat a series of long flashes (1 second ON, 1 second OFF) followed by a series of short flashes (½ second ON, ½ second OFF). These series of blink codes are defined as follows: 1) 1 long, 2 short (repeated 3 times) = No response from the CMM9301 2) 1 long, 3 short (repeated 3 times) = Failed to load the Random Address 3) 1 long, 4 short (repeated 3 times) = Failed to set the Advertising Parameters 4) 2 long, 2 short (repeated 3 times) = Failure occurred while attempting to transfer a Data Packet to the CMM9301 5) 2 long, 3 short (repeated 3 times) = No response from the CMM9301 after a Set Advertising Enable command was executed. Page 25 of 26
Appendix A: Design Notes 1) If more than one smartphone is used or a phone gets replaced with a new phone, the alarm count maintained by BMBT will likely be out of sync with the smartphone's count. The phone will re-sync its internal counts after it displays an Alert Dialogue for any and all mismatches 2) ibeacons: Apple puts all the required information into the advertising packets in a "Manufacturer Specific Data" field of connectable undirected advertising events. BMBT will use non-connectable undirected advertising. ibeacons are not supported in the BMBT s firmware. 3) Any alarm generated by BMBT will be continuously advertised until either a new alarm of the same type is detected or the underlying cause of the alarm is gone. Alarm information displayed on the smartphone will only get erased when the application is restarted. Any alarm that is still being broadcast when the app restarts will again get displayed. 4) A POR will reset everything in the BMBT except its Random Device Address. Start times & start voltages will be sampled during the next start operation as always. Page 26 of 26