Smart Vehicle Tracker
| Name | GitHub |
|---|---|
| Yussuf Abdelkarim | Youssefibrahim03 |
| Ismail Dahshan | ismaileldahshan1 |
| Amr Eid | GH_UID2 |
Github Repo: https://github.com/ismaileldahshan1/Smart_Vehicle_Tracker
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 SIM800L 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 |
| Nucleo-L432KC Pin | Connects To | Function |
|---|---|---|
| PA9 (USART1_TX) | CD74HC4053E common input | UART1 TX, muxed to HC-05 or SIM800C |
| PA10 (USART1_RX) | CD74HC4053E common input | UART1 RX, muxed to HC-05 or SIM800C |
| PA2 (USART2_TX) | ST-LINK Virtual COM Port | PC console (TeraTerm) |
| PA15 (USART2_RX) | ST-LINK Virtual COM Port | PC console (TeraTerm) |
| PA3 (USART2_RX alt) | NEO-6M TX | GPS data input (dynamic routing) |
| PB0 | CD74HC4053E select line | Mux channel select (LOW = HC-05, HIGH = SIM800C) |
| PB3 | Status LED | System heartbeat / mode indicator |
| 3V3 | NEO-6M VCC, HC-05 VCC, CD74HC4053E VCC | 3.3 V supply rail |
| 5V | (see Power Budget) | Higher-voltage rail |
| GND | Common ground for all modules | Shared reference |
| 4053 Pin | Connects To | Notes |
|---|---|---|
| Pin 16 (VCC) | 3.3 V | Logic supply |
| Pin 8 (GND) | GND | Ground |
| Pin 7 (VEE) | GND | Negative supply tied to ground for digital signals |
| Pin 6 (INH) | GND | Inhibit held low to keep the mux enabled |
| Pin 9, 10, 11 (select A/B/C) | PB0 / GND | Channel select lines |
| Common / channel pins | PA9, PA10, HC-05 TXD/RXD, SIM800C TXD/RXD | Signal routing |
##Breadboard Wiring:
##Circuit diagram:
| # | Component | Part Number | Qty | Unit Cost (EGP) | Source | Datasheet |
|---|---|---|---|---|---|---|
| 1 | Microcontroller board | Nucleo-L432KC | 1 | Provided by university | University lab | ST Nucleo-L432KC |
| 2 | GSM module | SIM800C | 1 | Provided by university | University lab | SIM800C datasheet |
| 3 | GPS module | u-blox NEO-6M | 1 | 600 | Purchased | NEO-6M datasheet |
| 4 | Bluetooth module | HC-05 | 1 | Provided by university | University lab | HC-05 datasheet |
| 5 | OBD-II adapter | ELM327 Mini (Bluetooth) | 1 | Provided by university | University lab | ELM327 datasheet |
| 6 | Analog multiplexer | CD74HC4053E | 1 | 22 | Purchased | CD74HC4053 datasheet |
| 7 | LiPo battery | 3.7 V 2000 mAh (MLP674361) | 1 | Provided by university | University lab | — |
| Total out-of-pocket cost | 622 EGP |
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.
| Component | Voltage | Typical Current | Peak Current | Notes |
|---|---|---|---|---|
| Nucleo-L432KC | 3.3 V | ~10 mA | ~25 mA | MCU core + peripherals |
| NEO-6M GPS | 3.3 V | ~45 mA | ~60 mA | Higher during satellite acquisition |
| HC-05 Bluetooth | 3.3 V | ~30 mA | ~40 mA | Peak while pairing |
| CD74HC4053E mux | 3.3 V | <1 mA | ~1 mA | CMOS, negligible draw |
| Status LED | 3.3 V | ~5 mA | ~5 mA | Through a current-limiting resistor |
| SIM800C GSM | 4.0 V | ~50 mA idle | up to ~2 A | Bursts during network transmission |
Description of the firmware design (e.g., Bare-metal Superloop, Interrupt-driven, or RTOS).
Visual diagrams mapping out the core logic, state transitions, and interrupt service routines (ISRs).
Explanations of any complex logic used (e.g., PID control loops, digital filtering, sensor fusion).
Compilers, IDEs, and toolchains used (e.g., Keil, PlatformIO, STM32CubeIDE).
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.
A log of major bugs, hardware failures, or design flaws you encountered, and the engineering steps you took to solve them.
High-quality photos of the completed build.
A link to a short video showing the system working in real-time under various conditions.
Data showing how well the project met its initial objectives (e.g., "Response time was measured at 12ms, well within our 50ms goal").
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.
| Date | Milestone | Deliverable |
|---|---|---|
| Mon, Mar 30 | Project kick-off | Brainstorming ideas, team formation begins |
| Tue, Apr 14 | Milestone 1: Team formation | Team finalized (Ismail, Youssef, Amr) |
| Wed, Apr 15 | Milestone 2: Proposal presentation | In-class proposal slides, wiki Sections 1, 2.1, and 7 |
| Apr 16–19 | — | Order HC-05, NEO-6M, SIM800L. Set up FreeRTOS project on STM32. Assign subsystems |
| Mon, Apr 20 | Checkpoint A: Wiki/page setup | Full proposal on course wiki with block diagram, objectives, labor division, and timeline |
| Apr 21–28 | Development sprint 1 | HC-05 paired with ELM327, OBD-II PID requests returning speed/RPM on serial terminal. GPS NMEA parsing working, SIM800L sending test SMS. FreeRTOS tasks created and scheduled, UART debug log running |
| Wed, Apr 29 | Milestone 3: Progress demo | Live demo of at least one major subsystem (OBD-II reading speed or GPS + SMS working). In-class progress presentation |
| Apr 30–May 5 | Development sprint 2 | Alert logic integrated: armed + speed > 0 → SMS sent with GPS coordinates. All tasks communicating via queues and mutexes. Full system integration begins |
| Wed, May 6 | Checkpoint B: Integration update | Wiki update with integration status, testing evidence (screenshots, serial logs), and remaining issues |
| May 7–12 | Final sprint | In-car GPS testing. SMS alert timing verification. Edge case handling. Demo rehearsal. Wiki page completed with all sections. Code cleaned up |
| Wed, May 13 | Milestone 4: Final demo | Final in-class presentation, live demo, final code submission, completed wiki page |
Link to your GitHub/GitLab repo.
Links to datasheets, tutorials, academic papers, and course materials used during development.