Github Repo: https://github.com/ismaileldahshan1/Smart_Vehicle_Tracker

Final Presentation Slides: https://docs.google.com/presentation/d/1ME4-baGZ9V6B6atl8CO48cF3VJwt6owbhOs0zOb8TSQ/edit?usp=sharing

Vehicle theft remains a serious and growing problem in Egypt, with limited affordable solutions available to everyday car owners. Existing GPS trackers on the market require expensive cellular subscriptions and lack integration with the vehicle's own diagnostic system, meaning they can only report location — not whether the engine is actually running or the car is being driven.

This project proposes a smart vehicle tracker built around a Nucleo STM32L432KC microcontroller running FreeRTOS. The system plugs into the car's OBD-II diagnostic port via an ELM327 Bluetooth adapter (connected through an HC-05 Bluetooth module) to read real-time engine data such as vehicle speed and RPM. Simultaneously, a NEO-6M GPS module tracks the car's geographic location. If the vehicle moves without the owner's authorization, a SIM800C GSM module immediately sends an SMS alert to the owner's phone containing the car's live GPS coordinates as a Google Maps link. The system provides a complete anti-theft solution: it knows both where the car is and what it's doing — all without requiring WiFi or internet subscriptions.

MVP:

• OBD-II engine data reading (speed, RPM) via ELM327 Bluetooth → HC-05 → UART
• Continuous GPS position tracking with NMEA sentence parsing (NEO-6M)
• Anti-theft detection: alert triggered when vehicle speed > 0 while system is armed
• SMS alert to owner via SIM800C GSM module with Google Maps location link
• Arm/disarm system state via serial command or software flag
• FreeRTOS task architecture with queues and semaphores for inter-task communication
• UART serial logging of GPS coordinates, OBD-II data, and events

Stretch Goals:

• Periodic location updates via SMS at configurable intervals while car is moving
• Speed threshold alerts (notify owner if car exceeds a set speed)
• Trip logging with timestamps — start/end location and duration over UART
• Geofence boundary detection with configurable safe zone

Hardware Architecture connections:

The system is organized around three input modules and two output modules, all managed by the MCU running FreeRTOS.

Inputs: The ELM327 Bluetooth OBD-II adapter plugs into the car's diagnostic port and communicates wirelessly with an HC-05 Bluetooth module configured in master mode. The HC-05 outputs serial data over UART to the Nucleo, allowing the MCU to send OBD-II PID requests (as simple AT command strings like "010D\r" for speed) and receive parsed responses. The NEO-6M GPS module communicates over a second UART, continuously feeding NMEA sentences that the MCU parses to extract latitude and longitude. System arming is controlled via a software flag toggled through a serial command.

Processing: The MCU runs FreeRTOS with separate tasks for OBD-II communication, GPS parsing, alert logic, SMS transmission, and UART logging. The OBD-II task periodically requests vehicle speed and RPM from the ELM327. The GPS task parses $GPRMC sentences to extract coordinates. The Alert task monitors whether the system is armed and the vehicle is moving (speed > 0) — if both conditions are true, it triggers the SMS task. Tasks communicate through FreeRTOS queues (sensor data → alert logic) and semaphores (shared arm/disarm state).

Outputs: The SIM800C GSM module connects over a third UART and sends SMS alerts to the owner's phone number using standard AT commands. The SMS contains the vehicle's current GPS coordinates formatted as coordinates. A UART debug log outputs all GPS coordinates, OBD-II readings, and system events to a serial terminal for development and diagnostics.

The Vehicle Security System is built around a set of modules chosen to balance cost, availability, and the functional requirements of theft detection, location reporting, and owner notification.

Component	Photo	Role	Why This Part
Nucleo-L432KC	()	FreeRTOS controller, coordinates all peripherals	Cortex-M4, low power, 2 USARTs, on-board ST-LINK
SIM800C	()	Sends SMS theft alerts	Quad-band GSM, simple AT-command interface
NEO-6M GPS	()	Provides vehicle latitude/longitude	Reliable NMEA over UART, good cold-start, low cost
HC-05	()	Wireless link to the OBD-II adapter	Configurable as master, SPP, auto-pair with bound device
ELM327	()	Reads vehicle speed from OBD-II	Standard ELM327 command set, all OBD-II protocols
CD74HC4053E	()	Routes UART1 between HC-05 and SIM800C	Triple 2-channel analog mux, lets 2 devices share 1 UART
LiPo Battery	()	System power source	3.7 V 2000 mAh, rechargeable, single-cell

##Breadboard Wiring:

##Circuit diagram:

The table below estimates current draw per component. The SIM800C is the critical case — during GSM transmission it draws short current bursts far higher than its idle current, which is why it requires a dedicated supply.

The firmware uses an RTOS-based architecture built on FreeRTOS (via the CMSIS-RTOS v2 API). This was chosen over a bare-metal superloop because the system has three largely independent responsibilities that each block on I/O at different times — waiting for keyboard input, polling the OBD-II adapter, and sending an SMS. A superloop would force these into one sequential cycle where a slow operation (e.g., the multi-second SMS transmission) would stall everything else. With an RTOS, each responsibility runs as its own task and the scheduler handles switching between them.

The firmware is organized into three tasks and a set of synchronization primitives:

Synchronization primitives:

This task-plus-primitive design means theft detection and SMS sending are decoupled: AlertTask simply releases the semaphore and continues monitoring, while SmsTask independently handles the slower SMS sequence.

The system operates as a two-state machine. The owner toggles between states from the PC console.

stateDiagram-v2
    [*] --> SAFE
    SAFE --> ALERT : key 'a' pressed
    ALERT --> SAFE : key 's' pressed
    ALERT --> ALERT : speed <= threshold
    ALERT --> SAFE : theft detected, SMS sent

    note right of SAFE
        Owner in vehicle.
        No speed monitoring.
        LED blinks slowly.
    end note

    note right of ALERT
        Vehicle armed.
        Speed polled via OBD-II.
        LED blinks quickly.
    end note

flowchart TD
    A[Start AlertTask] --> B[Initialize ELM327<br/>ATZ, ATE0, ATSP6, etc.]
    B --> C{Mode == ALERT?}
    C -- No --> C
    C -- Yes --> D[Send 010D over OBD-II]
    D --> E{Valid speed<br/>received?}
    E -- No --> F[Increment fail counter]
    E -- Yes --> G{Speed > threshold<br/>AND not already fired?}
    G -- No --> C
    G -- Yes --> H[Print THEFT<br/>Capture GPS fix]
    H --> I[Release theft semaphore]
    I --> C
    F --> C

flowchart TD
    A[Start SmsTask] --> B[Wait on theft semaphore]
    B --> C[Read GPS coordinates]
    C --> D[Build SMS body string]
    D --> E[Acquire UART1 mutex]
    E --> F[Switch mux to SIM800C]
    F --> G[Send AT, check reply]
    G --> H{SIM800C<br/>responded?}
    H -- No --> K[Switch mux back, release mutex]
    H -- Yes --> I[Send ATE0, then SMS]
    I --> K
    K --> B

Note on ISRs: This firmware does not use custom interrupt service routines for the application logic. UART transfers use the HAL's blocking (polled) API within each task, and FreeRTOS relies on the SysTick timer interrupt for scheduling. The only ISR in the project is the standard timer-tick handler (HAL_TIM_PeriodElapsedCallback).

The NEO-6M outputs location in NMEA $GPRMC sentences, where coordinates are in DDMM.MMMMM format (degrees and minutes). Converting this to decimal degrees normally requires floating-point arithmetic. To keep the binary small enough for the toolchain's 32 KB limit, the firmware avoids floating-point entirely and works with integers scaled by 100,000.

The conversion (nmea_to_scaled_i) works as follows:

1. Split the NMEA field into a degree part and a minute part.
2. Compute minutes x 100000 as an integer.
3. Convert to scaled decimal degrees: degrees x 100000 + (minutes_scaled / 60).
4. Apply a negative sign for the southern or western hemisphere.

The result is stored as a 32-bit integer. When the SMS is built, a companion function (format_coord) splits this integer back into a whole part and a 5-digit fractional part to print a human-readable coordinate — again without using floating-point printf.

Vehicle speed is requested with OBD-II PID 010D. The ELM327 replies with a hex string of the form 41 0D XX, where XX is a single byte representing speed in km/h (0-255). The decoding algorithm (parse_speed_from_obd):

1. Strips all non-hexadecimal characters from the response buffer.
2. Locates the 410D response header.
3. Converts the two hex digits immediately after it into an integer value.

That value is the vehicle speed, compared directly against the theft threshold.

Theft detection is a simple threshold check with a latch. While the system is in ALERT mode, each speed reading is compared against SPEED_THEFT_THRESHOLD_KMH. If the speed exceeds the threshold and the alert has not already fired this arming cycle (g_alert_fired flag), a theft event is triggered exactly once. The latch prevents repeated SMS messages while the vehicle continues moving. The flag resets when the owner re-arms or disarms the system.

Because the Nucleo-L432KC has only two USARTs, USART2's receive line is shared between the PC console (pin PA15) and the GPS module (pin PA3) by reconfiguring the GPIO alternate function at runtime. The functions uart2_rx_to_pc() and uart2_rx_to_gps() reassign which physical pin is connected to the USART2 receiver, allowing one peripheral to serve two devices without a second physical multiplexer.

Toolchain constraint: The build targets the ARM Compiler's 32 KB code-size limit. This shaped several implementation choices — most notably the avoidance of floating-point printf, which would pull in large library routines and exceed the limit. Coordinate handling was implemented with scaled-integer arithmetic specifically to stay within this budget.

Each component was tested in isolation to make sure the code was working properly and the hardware connections were also working properly.

First, we tested the bluetooth module, we did so by sending AT commands through UART to the module to check that it is working and to start with the initialization of the binding process.

After, we tested the OBD-II module by connecting it to the bluetooth and fetching the RPM data of the car from it and displaying it on a terminal emulator. We did indeed get the RPM data of the car in real time which made us sure it was working and connected properly.

Next, we started working on the GPS module, we connected it over UART and started the set up process. After we finished the code for it we were not getting any results in the beginning which was weird because we checked the wiring and the components. So, after searching online we found that the antenna was weak and we needed to go in an outdoor location so that it works properly and then it worked and we got our location on the terminal emulator which set us up for our final task.

Finally, we started working on the SMS module. We bought a chip from Vodafone Egypt and we connected it to the device then we started setting it up, there were a few AT commands for setting up the sim card before we could use it to send messages. We displayed all of these commands on the terminal emulator and the device gives some responses about the signal connection, the service provider, and the connectivity. we displayed these messages and found that we were indeed connecting successfully. We then proceeded to send text messages from the device and receive them on our phone and so we were sure that this module was working.

After testing each component alone and making sure that it works we connected all of them together with the following flow. The system is initialized to alert mode, while in alert mode the microcontroller reads the speed from the OBD-II and if it increases above 0, the coordinates are fetched from the GPS module. After, using a multiplexor the UART is disconnected from the GPS and connected to the SMS module where the microcontroller sends the AT commands necessary to send an alert SMS message to the owner of the car. We tested the system by going into the car, connecting the OBD-II, and then putting the system in alert mode. we proceeded to wait for the SMS message and check if the coordinates match the place we are at and so we checked that the whole work flow was working properly.

The first major challenge we faced was that we needed 3 UART connections but the nucleo board offered only 2. Our solution to this was to use a multiplexor and change between the SMS and GPS modules as we needed to do so.

Also, the fist SMS module we got was not working and that was because of different power supply between it and the nucleo. After that problem we were searching for solutions and found a more advanced module online and so we decided to use that module.

Another problem was that the second module we used for the SMS did not send links whatsoever and we found out that this is also the case on mobile phones, so, decided to just send the coordinates.

A problem we faced with both our GPS and SMS modules was that they did not work inside rooms at all we needed to be in an outside location, this made testing and debugging even harder because we needed to go back and forth between our work station and going outside, however, the use case of our problem does not make this out to be a major issue as cars are all driven outside were these components will work.

A bug in the code was the AT commands not working properly because of terminating characters in the strings and different communication issues, but they were resolved in the end.

The following metrics were measured against the project's initial objectives. Where an objective could not be validated on hardware, this is stated explicitly rather than estimated.

Ismail — OBD-II subsystem and Bluetooth communication. Responsible for configuring the HC-05 in master mode and pairing it with the ELM327, writing the OBD-II PID request/response parser over UART, and implementing the OBD-II FreeRTOS task. Also did the Alert logic, system integration, and testing. Responsible for the Alert FreeRTOS task (monitoring armed state + vehicle speed to trigger SMS), and the arm/disarm mechanism.

Youssef — SMS alert system. Responsible for interfacing the SIM800C GSM module, implementing the SMS sending logic with AT commands. Implements SMS FreeRTOS tasks.

Amr — Responsible for interfacing the NEO-6M GPS module, writing the NMEA parser to extract coordinates. In addition, worked in the overall integration of the system. Also leads documentation (wiki page, presentation slides) and demo preparation.

Shared responsibilities: All three members contribute to debugging, FreeRTOS tuning (task priorities, stack sizes), and the final demo.

https://github.com/ismaileldahshan1/Smart_Vehicle_Tracker

1. STMicroelectronics. NUCLEO-L432KC — STM32 Nucleo-32 development board.

   https://www.st.com/en/evaluation-tools/nucleo-l432kc.html

2. STMicroelectronics. *STM32L432KC Datasheet — Ultra-low-power Arm Cortex-M4

   MCU.* https://www.st.com/en/microcontrollers-microprocessors/stm32l432kc.html

3. STMicroelectronics. RM0394 — STM32L4 Series Reference Manual.

   https://www.st.com/resource/en/reference_manual/rm0394-stm32l41xxx42xxx43xxx44xxx45xxx46xxx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

4. SIMCom. SIM800C Hardware Design / AT Command Manual.

   https://www.simcom.com/product/SIM800C.html

5. u-blox. NEO-6 Series — u-blox 6 GPS Modules Data Sheet.

   https://www.u-blox.com/en/product/neo-6-series

6. u-blox. u-blox 6 Receiver Description Including Protocol Specification.

   https://www.u-blox.com/en/docs/UBX-13003221

7. Texas Instruments. *CD74HC4053 — High-Speed CMOS Logic Analog

   Multiplexers/Demultiplexers Datasheet.*

   https://www.ti.com/product/CD74HC4053

8. HC-05 Bluetooth Module Datasheet and AT Command Set.

   https://components101.com/wireless/hc-05-bluetooth-module

9. ELM Electronics. ELM327 — OBD to RS232 Interpreter Datasheet.

   https://www.elmelectronics.com/products/dsheets/

10. NMEA 0183 Standard — Sentence formats for GPS receivers (GPRMC sentence

    specification).

11. ISO 15765-4 / SAE J1979. *OBD-II diagnostic communication and standard

    PIDs* (PID 010D — Vehicle Speed).

12. STMicroelectronics. *STM32CubeMX — STM32 configuration and code generation

    tool.* https://www.st.com/en/development-tools/stm32cubemx.html

13. STMicroelectronics. STM32CubeL4 — HAL and Low-Layer drivers.

    https://www.st.com/en/embedded-software/stm32cubel4.html

14. Arm Keil. MDK Microcontroller Development Kit (uVision IDE).

    https://www.keil.com/

15. FreeRTOS. FreeRTOS Real-Time Operating System — Documentation.

    https://www.freertos.org/

16. Arm. CMSIS-RTOS v2 API Documentation.

    https://arm-software.github.io/CMSIS_5/RTOS2/html/index.html

Embedded Systems Course, Spring 2026.