Bluetooth Phone Dashboard for Live Vehicle Data

The problem

Riders and technicians increasingly expect to see vehicle data on a phone. A wireless link must be reliable, recover from disconnections and carry data in a compact, checkable format. Getting the framing, rates and error handling right on the microcontroller side is the core engineering task.

Objectives

• Fit an HC-05 module to the Bluetooth header and configure it
• Design a framed packet format with a checksum for live data and alerts
• Stream speed, cell voltage, temperature, motion and alert data at a fixed rate
• Build a phone or laptop dashboard that parses, displays and logs the data

What you need

This project uses the kit's lithium cell. Respect polarity, never short the terminals, and don't leave the cell charging unattended.

Key concepts

Serial port profile

A Bluetooth Classic profile that makes the link appear as a serial port on both ends, so the STM32 just writes to its UART.

Packet framing

Each packet starts with a sync byte, carries a type and length, then the payload and a checksum, so the receiver can find packet boundaries and reject corrupted data.

UART DMA transmit

Sending a buffer with HAL_UART_Transmit_DMA lets the CPU continue working while bytes go out.

Link supervision

Sending a heartbeat and watching for replies lets both sides detect a lost link and reconnect or warn.

Step-by-step guide

1. 1

   Requirements and data list

   List the signals to stream: emulated speed from the potentiometer, cell voltage, cell temperature, acceleration magnitude, tilt and an alert byte. Decide the rate, for example 10 packets per second. Choose the receiving device: Android phone or laptop for HC-05, or iPhone with an HM-10 BLE module. Calculate the bytes per second and check it is well within the link's capacity at your baud rate.

   Checkpoint: A data table with signal, scaling, size and rate, and a bandwidth calculation.

2. 2

   Module fitting and configuration

   Fit the HC-05 to the Bluetooth header, checking pin order and the module's supply and logic levels against its documentation. Enable the header's DIP switch. Enter the module's AT command mode as its documentation describes, set the device name, pairing PIN and baud rate, then return to data mode. Note the default name and PIN for the report, and change the pairing PIN from the default before demonstrations.

   Checkpoint: The phone or laptop pairs with the module under the chosen name.

3. 3

   UART and loopback test

   In CubeMX set SYSCLK to 72 MHz and configure the UART connected to the Bluetooth header at the module's baud rate, with DMA for transmit and an interrupt for receive. Send a test string every second and echo back anything received. Use a Bluetooth serial terminal app to check both directions. Use a ring buffer for received bytes so no data is lost while the main loop is busy.

   Checkpoint: Text sent from the phone is echoed back and the kit's test string appears on the phone.

4. 4

   Sensor acquisition

   Enable the DIP switches for the potentiometer, battery, MPU6050 and LCD. Read the potentiometer and cell voltage with ADC and DMA, the T-sense input for temperature and the MPU6050 over I2C. Calibrate cell voltage against a multimeter. Show the same values on the LCD for comparison. Cell safety: check polarity and never short the cell. Sample all signals on one timer so they are consistent.

   Checkpoint: All signals update correctly on the LCD.

5. 5

   Packet format

   Define the packet: sync byte 0xAA, type, length, payload of scaled integers in little-endian order, and a CRC-8 or 16-bit checksum. Add a sequence counter so the receiver can count lost packets. Write the packing function in C and the parser in Python, and test them on captured bytes. Document the format in a table with byte offsets and scaling so anyone writing a new dashboard can parse it without reading the firmware.

   Checkpoint: Python parses a captured byte stream with zero checksum errors and correct values.

6. 6

   Streaming and alerts

   Use a timer to send a data packet every 100 ms with DMA. Send an alert packet immediately when a threshold such as high temperature, low voltage or a tilt beyond a set angle is crossed. Receive simple commands from the phone, such as change the stream rate or acknowledge an alert, and reply with a status packet. Never block while sending.

   Checkpoint: Data arrives at the set rate and alerts appear within a fraction of a second.

7. 7

   Dashboard application

   Build the receiving dashboard. On a laptop, a Python script with pyserial and matplotlib can show live gauges and plots. On Android, an App Inventor or similar app can display numbers and alert colours. Log all received data to a CSV file with phone or laptop time. Show a clear indicator when data stops arriving, and colour values that are out of their normal range, so the user notices a problem even without an alert packet.

   Checkpoint: The dashboard shows live values matching the kit's LCD and saves a log.

8. 8

   Link robustness

   Add a heartbeat from the dashboard. If the kit sees no heartbeat for a few seconds, it shows 'link lost' on the LCD and keeps working. Test walking away until the link drops, then return and confirm automatic recovery. Measure packet loss with the sequence counter at several distances. Also check what happens if the phone sends commands during reconnection, and make sure half-received packets after a reconnection are rejected by the checksum.

   Checkpoint: A table of packet loss against distance, and recovery after link loss without a reset.

9. 9

   Report

   Document the module setup, packet format, firmware, dashboard and test results. Include screenshots, a bandwidth calculation and the packet-loss table. Note security limits of a simple pairing PIN. Discuss what a production design would add, such as secure pairing, encryption of commands, a BLE service with defined characteristics and power saving when the vehicle is parked, and how each would change the firmware.

   Checkpoint: A complete report with screenshots and measurements.

Testing & validation

• Values on the dashboard match the LCD and a multimeter
• Zero checksum errors in a 10-minute stream at close range
• Packet loss measured at several distances
• Alert latency from threshold crossing to dashboard
• Recovery after the link is lost and restored

Expected results

A Bluetooth dashboard on a phone or laptop with live vehicle data, alerts and logging, backed by a framed, checked packet protocol on the kit.

Take it further

• Use BLE with an HM-10 add-on and a custom characteristic layout
• Add authenticated commands for remote lock or mode change
• Stream CAN data received from another node
• Store data in SPI flash when the link is down and upload it on reconnection

Viva and review questions